The following applies to latest 'Development stream', currently based on kernel 4.8.
Networking - OSA - Layer 2 / configured as slaves for bonding mode active-backup
In 2014 recent hardware driver bundles contain an OSA firmware update which may result in loss of network connectivity, if the OSA-Express cards are used as slaves for a bonding interface configured in active-backup mode AND parameter fail_over_mac is either not specified or defined as 0.
The new zEnterprise BC12 and EC12 systems released September 2013 are exposed to this problem when they are brought up to System Driver 15F - everything from Bundle 2C and above.
Affected are all possible OSA types OSA-Express5S / OSA-Express4S / OSA-Express3 on BC12 and EC12.
In September 2014 an OSA firmware fix MCL H49530.005 has been released to customer in System Driver D15F Bundle 23a. Resulting OSD Code levels C.90 (for OSA-Express4S and OSA-Express5S) and (0.B5 for OSA-Express3) and above return to the old OSA behavior as default. Without this fix, a Linux workaround is required: Configure bonding active-backup mode together with parameter fail_over_mac=1 (active), which requires distinct MAC-addresses for the enslaved OSAs.
That means, specifyand use different MAC-addresses for the OSA interfaces to be enslaved.
OSA, HiperSockets, QETH
Networking - OSA - Layer 3 mode only
The following applies only when running in Layer 3 mode (i.e. not in Layer 2 mode):
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 early IBM System z9:
The above restriction does not apply when running on recent z9 or newer System z.
Networking - HiperSockets - No Layer 2 / Layer 3 traffic
Large MTU sizes may fail due to "order-N allocation failed" problem
- Please see http://www.ibm.com/systems/z/connectivity/products/fc.html for FCP channel limitations, and the book Device Drivers, Features, and Commands.
- If access to a device is lost although it is currently mounted, a limitation of the kernel 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 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)
- FCP-attached IBM tape devices using the IBMtape device driver must be attached through a switch.
- Support for "FCP hardware data router":
- Support for "Support for end-to-end data consistency checking (T10-DIF)":