141 lines · plain
1======================2S/390 common I/O-Layer3======================4 5command line parameters, procfs and debugfs entries6===================================================7 8Command line parameters9-----------------------10 11* ccw_timeout_log12 13 Enable logging of debug information in case of ccw device timeouts.14 15* cio_ignore = device[,device[,..]]16 17 device := {all | [!]ipldev | [!]condev | [!]<devno> | [!]<devno>-<devno>}18 19 The given devices will be ignored by the common I/O-layer; no detection20 and device sensing will be done on any of those devices. The subchannel to21 which the device in question is attached will be treated as if no device was22 attached.23 24 An ignored device can be un-ignored later; see the "/proc entries"-section for25 details.26 27 The devices must be given either as bus ids (0.x.abcd) or as hexadecimal28 device numbers (0xabcd or abcd, for 2.4 backward compatibility). If you29 give a device number 0xabcd, it will be interpreted as 0.0.abcd.30 31 You can use the 'all' keyword to ignore all devices. The 'ipldev' and 'condev'32 keywords can be used to refer to the CCW based boot device and CCW console33 device respectively (these are probably useful only when combined with the '!'34 operator). The '!' operator will cause the I/O-layer to _not_ ignore a device.35 The command line36 is parsed from left to right.37 38 For example::39 40 cio_ignore=0.0.0023-0.0.0042,0.0.471141 42 will ignore all devices ranging from 0.0.0023 to 0.0.0042 and the device43 0.0.4711, if detected.44 45 As another example::46 47 cio_ignore=all,!0.0.4711,!0.0.fd00-0.0.fd0248 49 will ignore all devices but 0.0.4711, 0.0.fd00, 0.0.fd01, 0.0.fd02.50 51 By default, no devices are ignored.52 53 54/proc entries55-------------56 57* /proc/cio_ignore58 59 Lists the ranges of devices (by bus id) which are ignored by common I/O.60 61 You can un-ignore certain or all devices by piping to /proc/cio_ignore.62 "free all" will un-ignore all ignored devices,63 "free <device range>, <device range>, ..." will un-ignore the specified64 devices.65 66 For example, if devices 0.0.0023 to 0.0.0042 and 0.0.4711 are ignored,67 68 - echo free 0.0.0030-0.0.0032 > /proc/cio_ignore69 will un-ignore devices 0.0.0030 to 0.0.0032 and will leave devices 0.0.002370 to 0.0.002f, 0.0.0033 to 0.0.0042 and 0.0.4711 ignored;71 - echo free 0.0.0041 > /proc/cio_ignore will furthermore un-ignore device72 0.0.0041;73 - echo free all > /proc/cio_ignore will un-ignore all remaining ignored74 devices.75 76 When a device is un-ignored, device recognition and sensing is performed and77 the device driver will be notified if possible, so the device will become78 available to the system. Note that un-ignoring is performed asynchronously.79 80 You can also add ranges of devices to be ignored by piping to81 /proc/cio_ignore; "add <device range>, <device range>, ..." will ignore the82 specified devices.83 84 Note: While already known devices can be added to the list of devices to be85 ignored, there will be no effect on then. However, if such a device86 disappears and then reappears, it will then be ignored. To make87 known devices go away, you need the "purge" command (see below).88 89 For example::90 91 "echo add 0.0.a000-0.0.accc, 0.0.af00-0.0.afff > /proc/cio_ignore"92 93 will add 0.0.a000-0.0.accc and 0.0.af00-0.0.afff to the list of ignored94 devices.95 96 You can remove already known but now ignored devices via::97 98 "echo purge > /proc/cio_ignore"99 100 All devices ignored but still registered and not online (= not in use)101 will be deregistered and thus removed from the system.102 103 The devices can be specified either by bus id (0.x.abcd) or, for 2.4 backward104 compatibility, by the device number in hexadecimal (0xabcd or abcd). Device105 numbers given as 0xabcd will be interpreted as 0.0.abcd.106 107* /proc/cio_settle108 109 A write request to this file is blocked until all queued cio actions are110 handled. This will allow userspace to wait for pending work affecting111 device availability after changing cio_ignore or the hardware configuration.112 113* For some of the information present in the /proc filesystem in 2.4 (namely,114 /proc/subchannels and /proc/chpids), see driver-model.txt.115 Information formerly in /proc/irq_count is now in /proc/interrupts.116 117 118debugfs entries119---------------120 121* /sys/kernel/debug/s390dbf/cio_*/ (S/390 debug feature)122 123 Some views generated by the debug feature to hold various debug outputs.124 125 - /sys/kernel/debug/s390dbf/cio_crw/sprintf126 Messages from the processing of pending channel report words (machine check127 handling).128 129 - /sys/kernel/debug/s390dbf/cio_msg/sprintf130 Various debug messages from the common I/O-layer.131 132 - /sys/kernel/debug/s390dbf/cio_trace/hex_ascii133 Logs the calling of functions in the common I/O-layer and, if applicable,134 which subchannel they were called for, as well as dumps of some data135 structures (like irb in an error case).136 137 The level of logging can be changed to be more or less verbose by piping to138 /sys/kernel/debug/s390dbf/cio_*/level a number between 0 and 6; see the139 documentation on the S/390 debug feature (Documentation/arch/s390/s390dbf.rst)140 for details.141