1 |
1275 |
phoenix |
S/390 common I/O-Layer - command line parameters and /proc entries
|
2 |
|
|
==================================================================
|
3 |
|
|
|
4 |
|
|
Command line parameters
|
5 |
|
|
-----------------------
|
6 |
|
|
|
7 |
|
|
* cio_msg = yes | no
|
8 |
|
|
|
9 |
|
|
Determines whether information on found devices and sensed device
|
10 |
|
|
characteristics should be shown during startup, i. e. messages of the types
|
11 |
|
|
"Detected device 4711 on subchannel 42" and "SenseID: Device 4711 reports: ...".
|
12 |
|
|
|
13 |
|
|
Default is off.
|
14 |
|
|
|
15 |
|
|
|
16 |
|
|
* cio_notoper_msg = yes | no
|
17 |
|
|
|
18 |
|
|
Determines whether messages of the type "Device 4711 became 'not operational'"
|
19 |
|
|
should be shown during startup; after startup, they will always be shown.
|
20 |
|
|
|
21 |
|
|
Default is on.
|
22 |
|
|
|
23 |
|
|
|
24 |
|
|
* cio_ignore = | ,
|
25 |
|
|
| , ...
|
26 |
|
|
|
27 |
|
|
The given device numbers will be ignored by the common I/O-layer; no detection
|
28 |
|
|
and device sensing will be done on any of those devices. The subchannel to
|
29 |
|
|
which the device in question is attached will be treated as if no device was
|
30 |
|
|
attached.
|
31 |
|
|
|
32 |
|
|
An ignored device can be un-ignored later; see the "/proc entries"-section for
|
33 |
|
|
details.
|
34 |
|
|
|
35 |
|
|
The device numbers must be given hexadecimal.
|
36 |
|
|
|
37 |
|
|
For example,
|
38 |
|
|
cio_ignore=0x23-0x42,0x4711
|
39 |
|
|
will ignore all devices with device numbers ranging from 23 to 42 and the
|
40 |
|
|
device with device number 4711, if detected.
|
41 |
|
|
|
42 |
|
|
By default, no devices are ignored.
|
43 |
|
|
|
44 |
|
|
|
45 |
|
|
* cio_proc_devinfo = yes | no
|
46 |
|
|
|
47 |
|
|
Determines whether the entries under /proc/deviceinfo/ (see below) should be
|
48 |
|
|
created. Since there are problems with systems with many devices attached, I
|
49 |
|
|
made it configurable.
|
50 |
|
|
|
51 |
|
|
Until the problems are dealt with, default is off.
|
52 |
|
|
|
53 |
|
|
|
54 |
|
|
/proc entries
|
55 |
|
|
-------------
|
56 |
|
|
|
57 |
|
|
* /proc/subchannels
|
58 |
|
|
|
59 |
|
|
This entry shows information on a per-subchannel basis.
|
60 |
|
|
|
61 |
|
|
The data is ordered in the following way:
|
62 |
|
|
|
63 |
|
|
- device number
|
64 |
|
|
- subchannel number
|
65 |
|
|
- device type/model (if applicable; if not, this is empty) and control unit
|
66 |
|
|
type/model
|
67 |
|
|
- whether the device is in use (i. e. a device driver has requested ownership
|
68 |
|
|
and registered an interrupt handler)
|
69 |
|
|
- path installed mask (PIM), as reflected by last store subchannel
|
70 |
|
|
- path available mask (PAM), as reflected by last store subchannel
|
71 |
|
|
- path operational mask (POM), as reflected by last store subchannel
|
72 |
|
|
- the channel path IDs (CHPIDs)
|
73 |
|
|
|
74 |
|
|
All fields are separated by spaces, the chpids are in blocks of four chpids.
|
75 |
|
|
|
76 |
|
|
* /proc/deviceinfo/
|
77 |
|
|
|
78 |
|
|
Shows in subdirectories for each device some characteristics:
|
79 |
|
|
- /proc/deviceinfo//chpids:
|
80 |
|
|
the channel path IDs
|
81 |
|
|
- /proc/deviceinfo//in_use:
|
82 |
|
|
whether the device is in use
|
83 |
|
|
- /proc/deviceinfo//sensedata:
|
84 |
|
|
the device type/model and if applicable control unit type/model of the
|
85 |
|
|
device
|
86 |
|
|
|
87 |
|
|
NOTE: Since the number of inodes which can be dynamically allocated by procfs
|
88 |
|
|
is limited, device entries will only be created up to a magic number of
|
89 |
|
|
devices. The kernel will utter a warning that not all entries can be
|
90 |
|
|
created. In this case, you shouldn't use "cio_proc_devinfo=yes" (see
|
91 |
|
|
above).
|
92 |
|
|
|
93 |
|
|
* /proc/cio_ignore
|
94 |
|
|
|
95 |
|
|
Lists the ranges of device numbers which are ignored by common I/O.
|
96 |
|
|
|
97 |
|
|
You can un-ignore certain or all devices by piping to /proc/cio_ignore.
|
98 |
|
|
"free all" will un-ignore all ignored devices,
|
99 |
|
|
"free , , ..." will un-ignore the specified devices.
|
100 |
|
|
|
101 |
|
|
For example, if devices 23 to 42 and 4711 are ignored,
|
102 |
|
|
- echo free 0x30-0x32 > /proc/cio_ignore
|
103 |
|
|
will un-ignore devices 30 to 32 and will leave devices 23 to 2F, 33 to 42
|
104 |
|
|
and 4711 ignored;
|
105 |
|
|
- echo free 0x41 > /proc/cio_ignore will furthermore un-ignore device 41;
|
106 |
|
|
- echo free all > /proc/cio_ignore will un-ignore all remaining ignored
|
107 |
|
|
devices.
|
108 |
|
|
|
109 |
|
|
When a device is un-ignored, device recognition and sensing is performed and
|
110 |
|
|
the device driver will be notified if possible, so the device will become
|
111 |
|
|
available to the system.
|
112 |
|
|
|
113 |
|
|
You can also add ranges of devices to be ignored by piping to
|
114 |
|
|
/proc/cio_ignore; "add , , ..." will ignore the
|
115 |
|
|
specified devices.
|
116 |
|
|
|
117 |
|
|
Note: Already known devices cannot be ignored; this also applies to devices
|
118 |
|
|
which are gone after a machine check.
|
119 |
|
|
|
120 |
|
|
For example, if device abcd is already known and all other devices a000-afff
|
121 |
|
|
are not known, "echo add 0xa000-0xaccc, 0xaf00-0xafff > /proc/cio_ignore"
|
122 |
|
|
will add af00-afff to the list of ignored devices and skip a000-accc.
|
123 |
|
|
|
124 |
|
|
|
125 |
|
|
* /proc/s390dbf/cio_*/ (S/390 debug feature)
|
126 |
|
|
|
127 |
|
|
Some views generated by the debug feature to hold various debug outputs.
|
128 |
|
|
|
129 |
|
|
- /proc/s390dbf/cio_crw/sprintf
|
130 |
|
|
Messages from the processing of pending channel report words (machine check
|
131 |
|
|
handling), which will also show when CONFIG_DEBUG_CRW is defined.
|
132 |
|
|
|
133 |
|
|
- /proc/s390dbf/cio_msg/sprintf
|
134 |
|
|
Various debug messages from the common I/O-layer; generally, messages which
|
135 |
|
|
will also show when CONFIG_DEBUG_IO is defined.
|
136 |
|
|
|
137 |
|
|
- /proc/s390dbf/cio_trace/hex_ascii
|
138 |
|
|
Logs the calling of functions in the common I/O-layer and, if applicable,
|
139 |
|
|
which subchannel they were called for.
|
140 |
|
|
|
141 |
|
|
The level of logging can be changed to be more or less verbose by piping to
|
142 |
|
|
/proc/s390dbf/cio_*/level a number between 0 and 6; see the documentation on
|
143 |
|
|
the S/390 debug feature (Documentation/s390/s390dbf.txt) for details.
|
144 |
|
|
|
145 |
|
|
* /proc/irq_count
|
146 |
|
|
|
147 |
|
|
This entry counts how many times s390_process_IRQ has been called for each
|
148 |
|
|
CPU. This info is in /proc/interrupts on other architectures.
|
149 |
|
|
|
150 |
|
|
* /proc/chpids
|
151 |
|
|
|
152 |
|
|
This entry will only show up if you specified CONFIG_CHSC=y during kernel
|
153 |
|
|
config.
|
154 |
|
|
|
155 |
|
|
This entry serves a dual purpose:
|
156 |
|
|
|
157 |
|
|
- show which chpids are currently known to Linux and their status (online,
|
158 |
|
|
logically offline),
|
159 |
|
|
|
160 |
|
|
- toggling known chpids logically online/offline.
|
161 |
|
|
|
162 |
|
|
To toggle a known chpid logically offline, do an
|
163 |
|
|
echo off > /proc/chpids
|
164 |
|
|
is interpreted as hex, even if you omit the '0x'.
|
165 |
|
|
The chpid will be treated by Linux as if it were not online, which can mean
|
166 |
|
|
some devices will become unavailable.
|
167 |
|
|
|
168 |
|
|
You can toggle a logically offline chpid online again by
|
169 |
|
|
echo on > /proc/chpids
|
170 |
|
|
If devices became unavailable by toggling the chpid logically offline, they
|
171 |
|
|
will become available again after you toggle the chpid online again.
|