Development stream - Restrictions

• SAN Discovery Tool (based on HBA API) is not supported on the "Development stream" (The Linux on System z team is working on providing equivalent functionality)

• There are known bugs in kernel 2.6.25 which can also show up on System z 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.
• IBM supports only 64-bit distributions based on this stream; 31-bit applications are supported on the 31-bit emulation layer.
• IBM does not recommend the following network devices for distributions based on this stream:
• CLAW
• CTCM protocols 0, 1, and 2 (former CTC)
• NETIUCV network device -- Note that the IUCV-infrastructure will be supported for distributions based on this stream.

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

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
• 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 (for OSA and z/VM VSWITCH) requires IBM zSeries 990 or 890, or IBM System z9 or z10. 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.
• Layer 2 for HiperSockets requires IBM System z10 - and z/VM 5.2 (or later z/VM) when running Linux as a VM guest.
• Two ports per CHPID (Four ports per OSA-card) is available only for OSA-Express3 GbE SX and LX on IBM System z10, running Linux on System z in an LPAR or as a VM guest (PTF for z/VM APAR VM64277 required).

Networking - OSA - 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 - OSA - 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 connected to a real OSA-card, the user should 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 - OSA - 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 early 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.

Networking - HiperSockets - No Layer 2 / Layer 3 traffic

• Two hosts can communicate with each other via HiperSockets only if:
• both are using HiperSockets Layer 2 or
• both are using HiperSockets Layer 3.

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

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 I/O performance.
• IBM does not recommend native FBA DASD devices for distributions based on this stream except for the following scenarios:
• access to virtual FBA devices (using FBA channel programs or DIAG access method)
• FBA emulated SCSI devices (z/VM minidisk support).
• HyperPAV requires DS8000 with HyperPAV LIC installed and z/VM 5.3, when running Linux on System z as a VM guest; base-PAV requires that the PAV feature is enabled on the storage server. If the prerequisites for HyperPAV and base-PAV are not there, the DASD driver works without using PAV.
• In a scenario where PAV is used (base-PAV or HyperPAV) and all channel paths to a DASD disk are lost (e.g. due to cable pull), some or all PAV alias devices may not automatically recover even after the channel paths have become available again.

zfcp

• z/VM PTFs for the following APARs are required when using the Linux FCP-support:
• on z/VM 5.2: VM63838 and VM64306
• on z/VM 5.3: VM64306
• Please see http://www.ibm.com/systems/z/connectivity/products/fc.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.).
• For the dump on panic feature for SCSI disks in a z9 LPAR, MCL G40954.002 in Driver D67L Bundle 18 is required. (z10 has no specific prerequisite)

SCSI IPL

• The PTF for APAR VM63838 is required prior to using Linux SCSI IPL support on z/VM 5.2. (z/VM 5.3 needs no PTF)
• The following restriction does not apply for System z9 or z10, but still applies for zSeries 800, 900, 890, 990:
• When running Linux on System z 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 System z 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.

Collaborative Memory Management Stage II

• requires Linux on System z running as a guest on z/VM 5.3 - which introduced Collaborative Memory Management Assist (CMMA) - with the PTFs for APARs VM64265 and VM64297, on an IBM System z9 or z10

Kernel NSS Support

• If a Linux guest machine is IPLed from a Kernel NSS with more than one CPU, this support requires:
  • z/VM 5.1 with PTF for APAR VM64103,
  • z/VM 5.2 with PTF for APAR VM64103, or
  • z/VM 5.3 without PTF.
• Linux guest machines using this support are restricted to run with one CPU if they run on prior releases to z/VM 5.1.