Known bugs

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

Initial ramdisk

The new 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.


Debugging multi-threaded applications with gdb-5.1.1 does not work properly on s390 and s390x.

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.


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

PORTNAME problem

You may have seen this before, but then again you may not...

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).


On systems with an installed PCIXCC card, z90crypt from the "August 2001 stream" or the "May 2002 stream" treats this card as a PCICC card: Using the card will produce wrong results and should be avoided.

You therefore must not define any PCIXCC card to a Linux system with such z90crypt.


Partition types (only for kernel 2.4.7)

On kernel configuration in the submenu "Filesystems", for "Partition Types" only select "IBM disk label and partition support". Other partition types may break your kernel.

Partitioning DASD

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


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.

Note: 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.

PFAULT on 64-bit: VM-fix needed

Note that z/VM has a bug that prevents the use of PFAULT for 64-bit, which is fixed with APAR:

If you do not have the z/VM PTF applied, switch off pfault with the "nopfault" parameter.

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 driver, QDIO base support, HiperSockets

Note: If you are using the linux-2.4.7-s390-n-timer.diff and have the CONFIG_NO_HZ_TIMER option switched on, you will have to use the qeth-2.4.7-s390-m-timer.o module instead of qeth-2.4.7-s390-m.o (same for qdio).
If you are using the linux-2.4.17-s390-n-timer.diff and have the CONFIG_NO_HZ_TIMER option switched on, you will have to use the qeth-2.4.17-s390-m-timer.o module instead of qeth-2.4.17-s390-m.o (same for qdio).

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!