Kernel 2.6 based: April 2004 stream

The following applies to latest "April 2004 stream". Note that Linux distributions containing code based on this stream (like Novell SUSE SLES9 and Red Hat RHEL4) have their own documentation on restrictions. For Linux distributions you may find the webpage on IBM tested Linux environments useful.

• The Linux on System z "October 2005 stream" has all the features of previous Linux on zSeries streams, plus additional features.
• There are known bugs in kernel 2.6.16 which can also show up on S/390, zSeries, and System z9 hardware.
• When using re-IPL for Linux guests on z/VM 5.1, please ensure that you have installed the PTF UM31428 for APAR VM63742.
  Otherwise re-boot under z/VM will not work anymore.
• Starting with the "October 2005 stream" IBM supports only 64-bit distributions; 31-bit applications are supported on the 31-bit emulation layer.
• Network devices being deprecated with the "October 2005 stream" - no longer recommended/supported:
  • CLAW
  • CTC, virtual and real
  • IUCV network device -- Note that the IUCV-infrastructure is not being deprecated

Back to top

SCLP VT220 driver

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

Tape driver

• The tape driver assigns the device to the system while the device is online. If the tape device is not online it may be assigned to another system with which the tape is shared.
• 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.

Cryptographic Device Driver

• 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.
• VM hides PCICCs, PCIXCCs, and CEX2Cs from its guests if a PCICA or a CEX2A is also available.

Back to top

OSA Express driver, QDIO base support, HiperSockets

• Multicasting has to be switched on in the kernel configuration.
• The OSA Express Driver needs QDIO base support.
• Broadcast is not supported for OSA-Express with a LIC level less than 3.0A
• Broadcast in conjunction with HiperSockets is not supported on z800 and z900
• Broadcast for a z/VM guest LAN requires z/VM 4.4 service level 0401 or higher
• 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 maximum frame (buffer) size supported by the hardware. 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 for inbound data buffers per device in Linux is (number of buffers) * (Linux memory usage per buffer) The number of buffers allocated by Linux can be specified for each device via the sysfs attribute 'buffer_count'; the number of buffers must be between 8 and 128; the default is 16. Linux memory usage per buffer is equivalent to the respective frame sizes.
• Layer 2 support requires IBM zSeries 990 or 890, or IBM System z9. When running a Linux guest under VM, you need z/VM 5.1 with Layer 2 support in PTF for APAR VM63538 or later z/VM.

Networking - Layer 3 mode only

The following applies only when running in Layer 3 mode (i.e. not in Layer 2 mode):

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

Networking - Layer 2 mode only

The following applies only when running in Layer 2 mode:

• When exploiting Layer 2 support with a Linux system that is not connected to a z/VM VSwitch, the user must manually configure a unique MAC address (which must be different from the default MAC address of the port) for the Linux interface.
• See also below "Networking - Layer 2 / Layer 3 traffic".

Networking - Layer 2 / Layer 3 traffic

The following restriction on Layer 2 and Layer 3 traffic applies only when running in Layer 2 mode on IBM zSeries 990 or 890 or earlier IBM System z9:

• Two hosts that need to communicate with each other and that share the same CHPID (port sharing) can only communicate when using the same transport mode - either Layer 2 with Layer 2 or Layer 3 with Layer 3. Layer 2 and Layer 3 traffic can be transmitted over the same OSA CHPID, but not between two hosts sharing the same CHPID.

The above restriction does not apply when running on recent IBM System z9 - see:

• "Remove L2/L3 LPAR-to-LPAR Restriction" on Networking Enhancements for IBM System z
• section "OSA Layer 2/Layer 3 transport enhancement" in:
  • IBM U.S. Software Hardware Announcement Letter 106-287 "IBM System z9 Business Class - z9 top technology innovation for small and medium enterprises"
  • IBM U.S. Software Hardware Announcement Letter 106-293 "IBM System z9 Enterprise Class: A security-rich, resilient and scalable mainframe for managing on demand infrastructures"

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

Back to top

DASD

• Detachment in VM of a device still open or mounted in Linux may trigger a limitation in the Linux kernel 2.6 common code and cause the system to hang or crash.
• 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 one channel path which may affect your IO performance.
• The DASD device driver does not support Parallel Access Volumes (PAV), neither static nor dynamic.

zfcp

• Please see //www.ibm.com/systems/z/connectivity/fcp.html for a description of zSeries FCP channel limitations.
• 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.
• 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 'lscss' in s390-tools ) 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 include/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.).
• In case of a path failure (e.g. switch port offline, cable pull, microcode-update on direct attached storage devices) that lasts longer than 30 seconds, it is possible that a SCSI device attached via the failed path is offlined in the Linux SCSI stack.
  Currently the SCSI device is not set online automatically if the path recovers. This can be done manually by writing "running" into the state-attribute of the SCSI device. For the "April 2004 stream" you have to write "1" into the online-attribute of the SCSI device. (Only user "root" can write to the state-attribute resp. online-attribute of a SCSI device.)
  Example: Check "state" attribute of SCSI device "0:0:0:0" and set state to "running".
  

  #>cat /sys/bus/scsi/devices/0\:0\:0\:0/state offline #>echo running > /sys/bus/scsi/devices/0\:0\:0\:0/state #>cat /sys/bus/scsi/devices/0\:0\:0\:0/state running

SCSI IPL

• The following restriction does no longer apply for System z9 but still applies for zSeries 800, 900, 890, 990:
  • When running Linux on zSeries in LPAR mode, re-booting from a SCSI device does not work.
• The following restrictions do no longer apply with MCL J12221.003 (zSeries 990 and 890) and MCL J12811.003 (zSeries 800, 900):
  • 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.

Back to top

s390-tools 1.5.x - general

• s390-tools 1.5.x are only tested with the kernel of the "April 2004 stream".
• Note that bug-fixes and enhancements for s390-tools 1.5.x are provided in s390-tools 1.5.(x+1) and will not be provided as patches against 1.5.x.

Back to top