Kernel 2.4 based: May 2002 stream

There are known bugs in kernel 2.4.19 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 IPv6-stack is still experimental.

• The tape driver implements assign on open. This means as long as the tape device is open it will be protected against other guests/LPARs. However, as soon as the tape device is closed it gets released and can be used by any guest/LPAR, again.
• The 3480/90 tape driver is unable to detect manual operations on the tape device, in particular manual tape unloads, and these operations will lead to errors in reading and writing. The driver provides ioctl functions to control the device and these must be used, either through the API or by using the Linux mt utility.

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.

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

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

chandev=add_parms,<lo_devno>,<high_devno>,portname:BLA

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

• Detachment in VM of a device still open or mounted in Linux may trigger a limitation in the Linux kernel 2.4 common code and cause the system to hang or crash.
• After detaching the DASD device, you must disable the device using:

  echo -n "set <devno> off" >> /proc/dasd/devices

  before attaching the device again, to avoid crashing the device driver.
• zIPL does not work with diag access to VM minidisks.
• fdasd expects more than one entry in the config file of the -c option.
• Note that running DASDFMT occupies 1 channel path which may affect your IO performance.
• Note that the dasdfmt utility can only format volumes containing a standard record zero on all tracks. If your disk does not fulfill this requirement (for example if you re-use an old volume, or access a brand new disk or one having an unknown history), you should additionally use a device support facility such as ICKDSF (in z/OS, OS/390, VM/ESA, VSE/ESA or stand-alone) before doing the dasdfmt for the low-level format.
• The DASD device driver does not support Parallel Access Volumes (PAV), neither static nor dynamic.
• The size of any swap device or file may not exceed 2GB. Similarly, the limit for the main memory that can be defined is slightly less than 2GB.

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

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

• You can only partition ECKD disks formatted with the new disk layout (dasdfmt option -d cdl ).
• No more than three partitions can be created on any one physical volume. This restriction is a result of the scheme of allocating Linux major and minor numbers to the partitions. (Increasing the number of partitions per DASD would drastically reduce the number of DASD that could be mounted in a system).
• You are advised to use fdasd to create or alter partitions as it checks for errors. If you use another partition editor it is your responsibility to ensure that partitions do not overlap. If they do, data corruption will occur.
• To avoid wasting disk space you should leave no gaps between adjacent partitions. Gaps are not reported as errors, but a gap can only be reclaimed by deleting and recreating one or other of the surrounding partitions and rebuilding the file system on it.
• A disk need not be partitioned completely. You may begin by creating only one or two partitions at the start of your disk and convert the remaining space to a partition later (perhaps when performance measurements have given you a better value for the blocksize).
• There is no facility for moving, enlarging or reducing partitions as fdasd has no control over the file system on the partition. You only can delete and recreate them. If you change your partition table you will lose the data in all altered partitions. It is up to you to preserve the data by copying it to another medium.

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

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

#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

#echo 'set 900 on'>/proc/dasd/devices

#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
#

• Ensure that your SAN equipment (e.g., fibre channel switches, FC<->SCSI bridges, FC devices, SCSI devices) is up to date with current vendor-specific firmware/microcode levels. If available, install the recommended firmware levels for a zSeries environment. Outdated firmware levels can cause disruption of SAN traffic.
• FCP channels currently do not support sharing of devices when accessed via the same FCP CHPID (channel path identifier), i.e., by using different virtual FCP adapters (from different Linux systems) sharing the same FCP CHPID. Please explicitly verify that no two systems try to access the same device via the same FCP CHPID, otherwise you run a risk of FC TRAFFIC DISRUPTION AND DATA CORRUPTION. To access a shared device, please use a unique FCP CHPID for each Linux system.
• 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 number 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, such as manufacturers' data and network management tools. This also encompasses high-integrity fabrics.
• The zfcp module only supports FC switched fabric and does not support FC point-to-point attachments or direct FC-arbitrated loop attachment.
• Address mappings issued to zfcp currently cannot be removed "on the fly". The recommended way to change existing address mappings is to reload the zfcp module. This implies disruption and restart of SCSI operation of a particular Linux instance.
• Error recovery by the Linux SCSI stack on a (virtual) FCP adapter may impact ongoing SCSI traffic to other devices attached to the same adapter. Therefore, it is recommended to use a unique (virtual) FCP adapter (unique zSeries device number, see /proc/subchannels ) to isolate a device from other SAN traffic. In particular, this applies to tape devices.
• The data transfer mechanism provided by the zSeries FCP adapter restricts the maximum data transfer size of single SCSI commands. This maximum amount of data is 538 page-aligned pages with 4096 bytes each. This amount decreases accordingly for non-aligned data buffers. This is not an issue for SCSI block devices (SCSI disks driven by sd or SCSI CD-ROM/DVD devices driven by sr ) in the current Linux implementation. It might be an issue for SCSI character devices (SCSI tape devices driven by st or other SCSI devices, like CD writers or scanners, driven by sg, depending on the particular SCSI stack utilization of these device drivers. The SCSI tape device driver (st) allows users to configure the actual data transfer size per SCSI command. The default value (30 KB) is sufficient and recommended from the zfcp perspective. The actual data transfer size of SCSI commands routed via the generic SCSI device driver (sg) may differ for several SCSI applications.
• zSeries FCP for Linux under VM requires a zSeries FCP enabled z/VM 4.3 (or above).
• In case of non-recoverable errors (e.g., temporary adapter failure, low-level data loss on the fiber), zfcp uses the host return codes ("host_byte") provided by the Linux SCSI stack (see drivers/scsi/scsi.h ) to indicate these error conditions to upper layer drivers. In particular, low-level errors can be disruptive to the SCSI traffic of devices which do not allow retries (e.g., tape read/write commands). It is recommended to the upper layer driver to try to recover these conditions, or just to return I/O error to the application. In case of a high frequency of host return codes, please check your SAN equipment (firmware etc.).

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

• Using OSA-Express Direct SNMP on all z990 OSA-levels, as well as z800/z900 OSA-levels starting with 3.33 (Driver 3G, EC stream J11204, MCL032; see also http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH10250) requires the "June 2003 stream"; both, linux-2.4.21-s390-06-june2003.tar.gz kernel patch and s390-tools version 1.2.2 are needed.
• ucd-snmp 4.2.x does not run properly on Linux for zSeries(64-bit). An additional patch is needed to enable snmpd on Linux for zSeries(64-bit). You will find the required patch at "http://sourceforge.net/projects/net-snmp" in the patch section. Check for title summary "enable ucd-snmp 4.2.x for 64-bit (s390x)". Apply the patch against the ucd-snmp source tarball (e.g. ucd-snmp-4.2.5.tar.gz). You can download the ucd-snmp source tarball from the download section at "http://net-snmp.sourceforge.net/" . Then compile and install the package as usual.
• at least OSA-E microcode level 3.0A is required.
• Only OSD CHPIDs are supported.
• Current MIBs do not contain any writable objects.
• SNMP traps are not yet supported.

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.

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.

• Multicasting has to be switched on in the kernel.
• The OSA Express Driver needs QDIO base support.
• Starting with microcode level 0146, OSA-Express QDIO require 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).
• HiperSockets do not provide broadcast functionality.
  Not all levels of OSA-Express microcode support broadcast functionality; broadcast is available starting with level 3.0A. OSA-2 supports broadcasts.
• For further information see documentation.
• The MTU range is 576 - 61440. However, depending on the medium and networking hardware settings, it may be restricted to 1492, 1500, 8992 or 9000. For HiperSockets the MTU range extends to 57344. This may be restricted by the framesize announced by the microcode.
• The maximum MTU size is limited by the value of the memory_usage_in_k parameter, which, together with the maximum frame (buffer) size, determines the number of buffers. The frame size for OSA-Express is fixed at 64 KB. For HiperSockets, the maximum frame size is defined during HiperSockets CHPID definition in the IOCDS. If the hardware configuration specifies the maximum frame size as 40 KB, the MTU can be configured up to 32 KB (frame size minus 8 KB) using ifconfig. Possible frame sizes are 16, 24, 40, and 64 KB. The total memory usage is

  (number of buffers) * (Linux memory usage per buffer)
  

  The Linux memory usage per buffer is 16 KB for frame size 16 KB, 32 KB for frame size 24KB, and 64KB for frame sizes 40 and 64KB. Linux will calculate the number of buffers from the total memory usage given in the chandev statement (where the number of buffers is <=128 and >=16. If a parameter is too high, Linux will allocate 128 buffers of 64 KB each.
• There is a restriction in Linux that the packet size of a multicast packet cannot be greater than the MTU size of the interface used.
• There may be circumstances that prevent ifconfig(or other commands) from setting an IP address on an OSA-Express network feature. The most common one is that another system in the network has set that IP address already. As a result, the IP address will be indicated by ifconfig as being set on the interface, but the address is not actually set on the feature. Since the design of the network stack in Linux does not allow feedback about IP address changes, there is no means of notifying the user of the problem other than to log a message. This message (usually containing text such as "could not set IP address" or "duplicate IP address") will appear in the kernel messages (displayable using "dmesg"). For most distribution settings, this will also trigger a message in /var/log/messages. If you are not sure whether the IP address was set properly or experience a networking problem, you should always check these logs to see if an error was encountered when setting the address.
  This requirement applies to both IPv4 and IPv6 addresses, and to IP takeover, VIPA, HiperSockets, and Proxy ARP.
• MAC addresses of VM Guest LAN devices will not be displayed correctly, until PTF UM30652 (only applies to z/VM 4.3.0) and the qeth module as of 2002-12-19 is installed.

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.

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. fore must not define any PCIXCC card to a Linux system with such z90crypt.

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

• UM30216 for z/VM 3.1
• UM30219 for z/VM 4.1
• UM30220 for z/VM 4.2