Kernel 2.4 based: June 2003 stream

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

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.

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.

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.

• If the tape device isn't manually assigned via the /proc interface, the driver only assigns the tape device to the system while the device is in use (open). So while the device isn't in use it might be used by any other system that shares the tape device.
• 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.

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 http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH10250)

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

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 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, z/VM, 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.
• 31-bit Linux, only: 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
#

• Please see http://www.ibm.com/systems/z/connectivity/fcp.html for a description of zSeries FCP channel limitations.
• 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.
• If access to a device is lost although it is currently mounted, a limitation of the Linux 2.6 code may be triggered which causes the kernel to hang or to crash. It is recommended to use a multi-pathing setup.
• 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.
• 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.).
• To be able to send the SCSI command REPORT LUNS, an internal representation is needed for FC LUN X'0' for the target port. If an FC LUN X'0' is not configured within zfcp for a target port for which the HBA API function HBA_SendReportLUNs() is called, an internal representation for FC LUN X'0' for this target port is created within zfcp. After that no mapping with FC LUN X'0' can be added for the same target port to module zfcp.
• The zfcp HBA API support is only available on IBM eServer zSeries 990 and 890 mainframes with a microcode level (MCL) that includes the enhancements of October 31, 2003. Please ensure to use the latest available microcode level.

Emulated 3172-001 lcs devices on MP3000 do not autodetect correctly, it is advised that you force these devices using
lcs0,<read_devno>,<write_devno>,0,<port_no>
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.

• When running Linux on zSeries in LPAR mode, re-booting from a SCSI device does not work.

• When running a 64-bit Linux on zSeries in LPAR mode with more than 2GB LPAR memory, a SCSI dump may contain an invalid PSW.
• ESA/390 mode dumps may be invalid because of wrong prefix register values. To read such a dump with the dump analysis tool lcrash the '-f ' option can be used.

• HiperSockets Network Concentrator simplifies network addressing between HiperSockets and OSA-Express allowing seamless integration of HiperSockets-connected operating systems into external networks.
• HiperSockets Network Concentrator requires:
  • z990 MCLs "EC E27057 MCL007" or "EC J12552 MCL010" (or higher)
  • qeth from "June 2003 stream" kernel 2.4.21 patch dated 2003-10-31 (or later) and s390-tools 1.2.3 dated 2003-11-28 (or later)
  • z/VM support is provided with: APAR VM63397 -- PTFs: UM31013 (z/VM V4.3), UM31014 (z/VM V4.4)

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

• 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.
• To use 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), both the linux-2.4.21-s390-06-june2003.tar.gz kernel patch and s390-tools version 1.2.2 are needed.

• If you have a PCICC only, or are attempting to use a CRT key on a system with PCIXCC only, you need to ensure that your data is PKCS-1.2 padded. If you have a PCICA, or are only using Mod-Expo keys with a PCIXCC card you do not need to ensure PKCS-1.2 padding. See z90crypt.h for a more thorough discussion of the requirements.
• PCICC is not supported on the IBM eServer zSeries 990 (z990) hardware.
• VM hides PCICCs and PCIXCCs from its guests if a PCICA is also available.
• PCIXCC is detected, but ignored when running under z90crypt versions earlier than 1.2.1.
• PCIXCC is only available for z990 as "PCIX Cryptographic Coprocessor (PCIXCC) feature (#0868)".
• PCIXCC cards are currently not supported for VM guests.

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

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.

• As of linux-2.4.21-s390-06-june2003.tar.gz, using broadcast in VM Guest LAN requires APAR VM63397.
• Multicasting has to be switched on in the kernel configuration.
• The OSA Express Driver needs QDIO base support.
• On OSA-Express querying the ARP cache (qetharp -q) only returns a maximum of 62 entries, even though more entries might exist in a device's ARP cache.
• HiperSockets do not provide broadcast functionality except on z990.
  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 24 KB, and 64 KB for frame sizes 40 and 64 KB. 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) 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.

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