The "August 2001 stream" is superseded by the "May 2002 stream".
There are known bugs in kernel 2.4.7 and 2.4.17 which can also show up on S/390 and zSeries hardware.
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.
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 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.
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.
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.
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.
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
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.
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.
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.
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)
This problem can be avoided with by installing MCL007:
Hardware Microcode Driver D3CG IQDIO Microcode EC Number - E26949 MCL007
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).
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).