-S/390 common I/O-Layer - command line parameters and /proc entries
-==================================================================
+S/390 common I/O-Layer - command line parameters, procfs and debugfs entries
+============================================================================
Command line parameters
-----------------------
* cio_msg = yes | no
Determines whether information on found devices and sensed device
- characteristics should be shown during startup, i. e. messages of the types
- "Detected device 0.0.4711 on subchannel 0.0.0042" and "SenseID: Device
- 0.0.4711 reports: ...".
+ characteristics should be shown during startup or when new devices are
+ found, i. e. messages of the types "Detected device 0.0.4711 on subchannel
+ 0.0.0042" and "SenseID: Device 0.0.4711 reports: ...".
Default is off.
An ignored device can be un-ignored later; see the "/proc entries"-section for
details.
- The devices must be given either as bus ids (0.0.abcd) or as hexadecimal
- device numbers (0xabcd or abcd, for 2.4 backward compatibility).
+ The devices must be given either as bus ids (0.x.abcd) or as hexadecimal
+ device numbers (0xabcd or abcd, for 2.4 backward compatibility). If you
+ give a device number 0xabcd, it will be interpreted as 0.0.abcd.
+
You can use the 'all' keyword to ignore all devices.
The '!' operator will cause the I/O-layer to _not_ ignore a device.
- The order on the command line is not important.
+ The command line is parsed from left to right.
For example,
cio_ignore=0.0.0023-0.0.0042,0.0.4711
When a device is un-ignored, device recognition and sensing is performed and
the device driver will be notified if possible, so the device will become
- available to the system.
+ available to the system. Note that un-ignoring is performed asynchronously.
You can also add ranges of devices to be ignored by piping to
/proc/cio_ignore; "add <device range>, <device range>, ..." will ignore the
specified devices.
- Note: Already known devices cannot be ignored.
+ Note: While already known devices can be added to the list of devices to be
+ ignored, there will be no effect on then. However, if such a device
+ disappears and then reappears, it will then be ignored.
- For example, if device 0.0.abcd is already known and all other devices
- 0.0.a000-0.0.afff are not known,
+ For example,
"echo add 0.0.a000-0.0.accc, 0.0.af00-0.0.afff > /proc/cio_ignore"
- will add 0.0.a000-0.0.abcc, 0.0.abce-0.0.accc and 0.0.af00-0.0.afff to the
- list of ignored devices and skip 0.0.abcd.
+ will add 0.0.a000-0.0.accc and 0.0.af00-0.0.afff to the list of ignored
+ devices.
+
+ The devices can be specified either by bus id (0.x.abcd) or, for 2.4 backward
+ compatibility, by the device number in hexadecimal (0xabcd or abcd). Device
+ numbers given as 0xabcd will be interpreted as 0.0.abcd.
- The devices can be specified either by bus id (0.0.abcd) or, for 2.4 backward
- compatibilty, by the device number in hexadecimal (0xabcd or abcd).
+* For some of the information present in the /proc filesystem in 2.4 (namely,
+ /proc/subchannels and /proc/chpids), see driver-model.txt.
+ Information formerly in /proc/irq_count is now in /proc/interrupts.
-* /proc/s390dbf/cio_*/ (S/390 debug feature)
+debugfs entries
+---------------
+
+* /sys/kernel/debug/s390dbf/cio_*/ (S/390 debug feature)
Some views generated by the debug feature to hold various debug outputs.
- - /proc/s390dbf/cio_crw/sprintf
+ - /sys/kernel/debug/s390dbf/cio_crw/sprintf
Messages from the processing of pending channel report words (machine check
- handling), which will also show when CONFIG_DEBUG_CRW is defined.
+ handling).
- - /proc/s390dbf/cio_msg/sprintf
- Various debug messages from the common I/O-layer; generally, messages which
- will also show when CONFIG_DEBUG_IO is defined.
+ - /sys/kernel/debug/s390dbf/cio_msg/sprintf
+ Various debug messages from the common I/O-layer, including messages
+ printed when cio_msg=yes.
- - /proc/s390dbf/cio_trace/hex_ascii
+ - /sys/kernel/debug/s390dbf/cio_trace/hex_ascii
Logs the calling of functions in the common I/O-layer and, if applicable,
- which subchannel they were called for.
+ which subchannel they were called for, as well as dumps of some data
+ structures (like irb in an error case).
The level of logging can be changed to be more or less verbose by piping to
- /proc/s390dbf/cio_*/level a number between 0 and 6; see the documentation on
- the S/390 debug feature (Documentation/s390/s390dbf.txt) for details.
-
-* For some of the information present in the /proc filesystem in 2.4 (namely,
- /proc/subchannels and /proc/chpids), see driver-model.txt.
- Information formerly in /proc/irq_count is now in /proc/interrupts.
+ /sys/kernel/debug/s390dbf/cio_*/level a number between 0 and 6; see the
+ documentation on the S/390 debug feature (Documentation/s390/s390dbf.txt)
+ for details.