Known bugs

There are known bugs in kernel 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.


The IPv6-stack is still experimental.

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

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 add_parms,0x10,portname:FOOBAR
(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 VM/ESA or z/VM.


Partitioning DASD

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

Access boxed 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.


The zfcp driver provides some technical data about the fabric, the connections, the target devices, etc. and their capabilities and configurations. Due to the vast ammount of possible combinations it is not possible to provide all relevant information. It is the obligation of the fabric maintainer to gather all additional important information by other means, e.g. manufacturers' data, network management tools. This also encompasses high-integrity fabrics.


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.

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

s390-tools 1.1.x - general

s390-tools 1.1.x (and 1.1) are only tested with the kernel 2.4.17 "May 2002 stream".
Because of missing kernel-interfaces the following new s390-tools from 1.1/1.1.x will definitely neither work with the "kernel 2.4.7 stream" nor with the "kernel 2.4.17 stream": osasnmpd, qetharp, tape_display.
Note that bug-fixes and enhancements for s390-tools 1.1.x are provided in s390-tools 1.1.(x+1) and will not be provided as patches against 1.1.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).

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.

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!