Known bugs

There are known bugs in kernel 2.4.21 which can also show up on S/390 and zSeries hardware.

Initial ramdisk

The devfs name /dev/rd/0 of the ramdisk cannot be used on the root= kernel parameter. The old style name /dev/ram0 has to be used instead.

Common I/O layer

If you explicitly specify cio_proc_devinfo=yes, not all devices will show up in /proc/deviceinfo/ if there are more than ca. 500 devices attached.

SCLP VT220 driver

To use the full-screen text terminal on the HMC which is controlled by the SCLP VT220 driver, an HMC Version 1.8.0 or above is required.

Tape driver


The sequence of the parameters as well as the separator used in the module- and kernel parameter line has changed. Please refer to the "Device Drivers and Installation Commands" manual in the Documentation section.


The IPv6-stack is still experimental.

PORTNAME problem

The following problem does not occur on any OSA-levels on z990 nor does it occur on z800/z900 OSA-levels starting with 3.33 (Driver 3G, EC stream J11204, MCL032; see also //

If you do not have the above OSA-levels installed, please note:

Starting with microcode level 0146, OSA-Express QDIO requires a portname to be set in the device driver. This portname is specified using
(more details in the chandev man page).

Put another way: If you fail to bring up your OSD card and dmesg shows an error message like

received IDX_TERMINATE with cause code 0x22 -- try another portname

you have to specify a portname.
To do so, append to your parmfile


(where BLA is your portname and <lo_devno> and <high_devno> pertain to the device numbers of your card).


This device driver is only available to LINUX systems running as guests under z/VM.


Access boxed DASD

This feature will not work for VM reserved minidisks unless you have PTFs for APAR VM63119 applied.

Partitioning DASD

There are some limitations to the current implementation and some precautions you should take in using it. These are:


The following is technically not a restriction of dasdfmt , since formatting interruptions are detected and the device is reset to the "active, not formatted" state. Nevertheless, it could happen that a disk goes into the "accepted" state, and the following procedure can be used to remedy this situation

During the formatting process the DASD is placed in a temporary 'accepted' state. If it is left in this state (for example if DASDFMT is interrupted) the DASD cannot be accessed. You can check the state of a DASD by entering:

#cat /proc/dasd/devices

If you see "accepted" in the output the corresponding DASD is disabled and not available for use. You can re-enable the DASD with the command:

#echo 'set <devno> on '>/proc/dasd/devices

where <devno> is the device number of the DASD you want to enable. Example:

#cat /proc/dasd/devices 0700(ECKD)at (94:0)is dasda:active at blocksize:4096,601020 blocks,2347MB 0800(ECKD)at (94:4)is dasdb:active at blocksize:4096,601020 blocks,2347MB 0900(ECKD)at (94:8)is dasdc:accepted

Disk 900 is in the accepted state and cannot be formatted with the dasdfmt command.

#echo 'set 900 on'>/proc/dasd/devices enables the disk and changes its state to "active, not formatted".

#cat /proc/dasd/devices 0700(ECKD)at (94:0)is dasda:active at blocksize:4096,601020 blocks,2347MB 0800(ECKD)at (94:4)is dasdb:active at blocksize:4096,601020 blocks,2347MB 0900(ECKD)at (94:8)is dasdc:active n/f #

You now will be able to format the DASD.



Emulated 3172-001 lcs devices on MP3000 do not autodetect correctly, it is advised that you force these devices using

using the channel device layer.

Real 3172-001's may need a delay between detection and starting up the device. Otherwise, the device will not start up properly owing to a possible microcode problem.

Best workaround:
Load the lcs module a few seconds before the interface will be configured up, for example: remove the entry for the lcs module in /etc/modules.conf
append "insmod lcs" to the end of /etc/rc.sysinit

Alternate workaround:
Perform an ifconfig tr0 down and ifconfig tr0 up a few seconds after the lcs module was loaded.

To use OSA devices when running Linux for zSeries on a basic mode machine (no LPARs) you may need to specify an ipldelay=xyz boot parameter. We recommend a value between 2m and 5m for xyz for the OSA card to initialize fully after IPL.


With current microcode the following restrictions apply:

The following restrictions do no longer apply with MCL J12221.003 (zSeries 990 and 890) and MCL J12811.003 (zSeries 800, 900):

HiperSockets Network Concentrator

Channel Device Configuration

The kernel can be configured both with and without the channel device layer. However, the qeth module only works in kernels built with the channel device layer switched on. CTC and LCS also work in kernels built without the channel device layer. For details on the configuration, please see the "Device Drivers and Installation" manual in the Documentation section.

Broadcast-ping problem (not relevant for z990)

If you do Broadcast-pings over HiperSockets, you may run into problems with the HiperSockets interface and see errors like

qdio : received check condition on activate queues on irq 0x152 (cs=x20, ds=x0)

in /var/log/messages.

This problem can be avoided with by installing MCL007:

Hardware Microcode Driver D3CG IQDIO Microcode EC Number - E26949 MCL007

OSA-Express Direct SNMP

Cryptographic Device Driver

For further details, refer to the chapter 7 on "Generic cryptographic device driver" in the Linux for zSeries and S/390 Device Drivers and Installation Commands manual.

s390-tools 1.2.x - general

s390-tools 1.2.x are only tested with the kernels of "May 2002 stream" and "June 2003 stream".
Because of missing kernel-interfaces the following s390-tools from 1.2.x will definitely not work with the "August 2001 stream": start_hsnc/ip-watcher, osasnmpd, qetharp and qethconf.

Note that bug-fixes and enhancements for s390-tools 1.2.x are provided in s390-tools 1.2.(x+1) and will not be provided as patches against 1.2.x.

EXT3-Filesystem with external journal

Do not use the ext3 filesystem with an external journal (on another partition or volume) having another size than the default size. This configuration is currently failing on S/390 and zSeries as well as on xSeries (Intel) due to a problem in the open source journaling file system code.

OSA Express driver, QDIO base support, HiperSockets

Large MTU sizes may fail due to "order-N allocation failed" problem

When using MTU sizes >8K on a network interface, the Linux TCP/IP stack may run into problems on heavily loaded systems because allocating memory for packets may fail due to memory fragmentation. As a symptom of this problem you will see messages of the form "order-N allocation failed" in the system log; in addition, network connections will drop packets, in extreme cases to the extent that the network is no longer usable.

As a workaround, use MTU sizes at most of 8K (minus header size), even if the network hardware allows larger sizes (e.g. HiperSockets, gigabit ethernet).

Contact the IBM team

If you want to contact the Linux on z Systems IBM team refer to the Contact the Linux on z Systems IBM team page.

Start building for free

IBM Bluemix(TM). IBM Bluemix: Develop in the cloud at the click of a button!