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 "April 2004 stream" has all features of the
"June 2003 stream".
There are known bugs in kernel 2.6.5 which can also
show up on S/390 and zSeries hardware.
31-bit Linux, only: The size of any swap device or file may not exceed 4GB.
The limit for the main memory that can be defined is slightly less than 2GB.
When using re-IPL for Linux on zSeries z/VM guests, please ensure
that you have installed the PTFs for APAR VM63742:
z/VM 4.4: UM31426
z/VM 5.1: UM31428
Otherwise re-boot under z/VM will not work anymore.
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.
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:
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).
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.
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".
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.
