2006-02-09 kernel 2.6.5 bug fix patch 33 ("April 2004")

If you download any software from this web site please be aware of the Warranty Disclaimer and Limitation of Liabilities.

linux-2.6.5-s390-33-april2004.tar.gz / MD5 ... accumulated patch, recommended (2006-02-09)

linux-2.6.5-s390-33-april2004-patches.tar.gz / MD5 ... per-problem-patches, recommended (2006-02-09)

These patches contain the following linux kernel bug fixes:

Description:
kernel: Magic sysrq-t addressing exception.
Symptom:
After submitting the magic sysrq key "t" the kernel hangs.
Problem:
The show_task function walks the kernel stack backchain of processes assuming that the processes are not running. Since this assumption is not correct walking the backchain can lead to an addressing exception and therefore to a kernel hang.
Solution:
Verify that all read accesses are within the bounds of the kernel stack before performing them.
Problem-ID:
20475
Description:
kernel: Spinlock performance degradation.
Symptom:
System performs badly under certain workloads, for example micro-benchmarks like Dbench.
Problem:
The spinlock re-try code contains a counter which is increased by each spinlock operation. This causes contention and therefore the observed performance degradation.
Solution:
Remove counter.
Problem-ID:
21239
Description:
lcs: LCS device drops too many packets on a flood ping.
Symptom:
Significant drop count increase when flood ping is running.
Ping program reports 90% packet loss.
Problem:
Number of LCS send buffers is too small.
Netif_stop_queue has not been issued in LCS send routine.
Solution:
Number of LCS send buffers increased to 32.
Call netif_stop_queue when sending a packet.
Problem-ID:
17612
Description:
qeth: NULL pointer de-reference with bonding and VLAN device.
Symptom:
Starting a VLAN device with ifup which is configured on top of a bonding device bond0 results in NULL pointer de-reference in qeth code.
Problem:
qeth_verify_vlan_dev checks if net_device is a real device or a VLAN device. If a VLAN device is found we are taking the card's address from the priv pointer. This is only correct for VLAN devices which are configured on top of OSA devices.
If VLAN device is configured on top of a bonding device the priv pointer contains the address of the bonding structure.
Solution:
Once the VLAN device is found in the VLAN group array of a qeth_card check if priv pointer is equal to card's address.
Problem-ID:
20061
Description:
qeth: Link carrier status wrong when device is offline.
Symptom:
Channel bonding device does not change to next slave in list when active slave has link problems or any other error occurs on appropriate qeth channel. This results in traffic inactivity for a certain amount of time (20 seconds) although second slave in list is fully operational.
Problem:
Setting a qeth device offline qeth does not set link carrier information properly, means usage of netif_carrier_off/on calls is not correct.
Thus bonding device does not take the second fully operational slave and still tries to use the first, not operational one to send and receive packets.
Solution:
Use netif_carrier_off when device becomes offline, use netif_carrier_on when device is set online.
Problem-ID:
20207
Description:
qeth: Kernel Oops due to NULL pointer de-reference.
Symptom:
Kernel oops when trying to bring up a qeth device online the very first time.
Problem:
When trying to set a qeth device online for the very first time it could happen that hardware reports device- or channel-errors before we have allocated and initialized a net_device. When this happens qeth is starting a recovery process and when calling qeth_set_offline we try to use card->dev which is a NULL pointer.
Solution:
Before using netif_carrier_off check first if card->dev is not NULL and if there is a need to call netif_carrier_off.
Problem-ID:
20908
Description:
qeth: Kernel panic when using EDDP in Layer 2 mode. (EDDP = Enhanced Device Driver Packing, "large send")
Symptom:
Kernel panics when using EDDP with qeth devices which are configured in Layer2 mode.
Problem:
Using EDDP in Layer 2 mode means that we have to copy the MAC header, too. Trying to do so, EDDP code tried to use skb->mac.raw for copying the MAC header to the EDDP structure. But skb->mac.raw does not point to MAC header of outgoing packets.
Solution:
Set skb->mac.raw pointer to MAC header and then use it for data copy instructions.
Problem-ID:
21241
Description:
qeth: Problem using echo to add vipa address.
Symptom:
Adding invalid IP addresses to vipa/ipa_takeover attributes works.
Problem:
Due to missing syntax checking invalid IPv4 addresses were not blocked but added to appropriate VIPA list for further usage. Valid IPv6 addresses were echo'ed to appropriate attribute but echo command returned with bad return code and address was not added to appropriate VIPA list.
Solution:
Check addresses first if they are correct and valid. If so use them.
Problem-ID:
21247
Description:
zfcp: Ensure that SCSI commands without failfast flag undergo normal SCSI stack error recovery.
Symptom:
No error recovery escalation performed for any SCSI commands that timed out.
Problem:
zfcp_scsi_eh_timed_out always returns EH_HANDLED. Thus SCSI error recovery is always bypassed when a SCSI command timed out.
Solution:
Return EH_NOT_HANDLED in zfcp_scsi_eh_timed_out if the SCSI command does not inherit the failfast flag. As a consequence SCSI commands with failfast flag bypass SCSI error recovery on timeout and commands without failfast flag are handled by SCSI stack error recovery.
Problem-ID:
19146
Description:
zfcp: Do not log fsf request and SCSI command during SCSI device reset.
Symptom:
Kernel panic on SCSI device reset.
Problem:
The fsf request belonging to the SCSI command which causes a SCSI device reset is completed and freed on one CPU.
Another CPU logs the device reset and tries to access the fsf request currently freed.
Solution:
Do not access and log data of the fsf request associated with the SCSI command for which a device reset is performed.
Problem-ID:
20314
Description:
zfcp: IPL not completed when FCP link unplugged.
Symptom:
IPL not completed when FCP link unplugged.
Problem:
Never ending adapter error recovery when link is unplugged.
Solution:
Remove endless loop during adapter reopen and simplify link down handling. (Don't poll for link up - just wait for link up notification.)
Problem-ID:
20114

Everybody should apply this patch.

To create the complete linux kernel sources, the following patches need to be applied in sequence:

linux-2.6.5.tar.gz (see www.kernel.org/pub/linux/kernel/v2.6)
+ linux-2.6.5-s390-base-april2004.diff (IBM)
+ linux-2.6.5-s390-01-april2004.diff (IBM)
+ xipfs612 (see linuxvm.org/patches/index.html)
+ xipfs622 (see linuxvm.org/patches/index.html)
+ linux-2.6.5-s390-02-april2004.diff (IBM)
+ linux-2.6.5-s390-03-april2004.diff (IBM)
+ single threaded workqueue patch (see marc.theaimsgroup.com/?l=bk-commits-head&m=108305028322900&q=raw)
+ linux-2.6.5-s390-04-april2004.diff (IBM)
+ linux-2.6.5-s390-05-april2004.diff (IBM)
+ linux-2.6.5-s390-06-april2004.diff (IBM)
+ linux-2.6.5-s390-07-april2004.diff (IBM)
+ linux-2.6.5-s390-08-april2004.diff (IBM)
+ linux-2.6.5-s390-09-april2004.diff (IBM)
+ linux-2.6.5-s390-10-april2004.diff (IBM)
+ linux-2.6.5-s390-11-april2004.diff (IBM)
+ linux-2.6.5-s390-12-april2004.diff (IBM)
+ linux-2.6.5-s390-13-april2004.diff (IBM)
+ linux-2.6.5-s390-14-april2004.diff (IBM)
+ linux-2.6.5-s390-15-april2004.diff (IBM)
+ linux-2.6.5-s390-16-april2004.diff (IBM)
+ linux-2.6.5-s390-17-april2004.diff (IBM)
+ linux-2.6.5-s390-18-april2004.diff (IBM)
+ linux-2.6.5-s390-19-april2004.diff (IBM)
+ linux-2.6.5-s390-20-april2004.diff (IBM)
+ linux-2.6.5-s390-21-april2004.diff (IBM)
+ linux-2.6.5-s390-22-april2004.diff (IBM)
+ linux-2.6.5-s390-23-april2004.diff (IBM)
+ linux-2.6.5-s390-24-april2004.diff (IBM)
+ linux-2.6.5-s390-25-april2004.diff (IBM)
+ linux-2.6.5-s390-26-april2004.diff (IBM)
+ linux-2.6.5-s390-27-april2004.diff (IBM)
+ linux-2.6.5-s390-28-april2004.diff (IBM)
+ linux-2.6.5-s390-29-april2004.diff (IBM)
+ linux-2.6.5-s390-30-april2004.diff (IBM)
+ linux-2.6.5-s390-31-april2004.diff (IBM)
+ linux-2.6.5-s390-32-april2004.diff (IBM)
+ linux-2.6.5-s390-33-april2004.diff (IBM)

Contact the IBM team

If you want to contact the Linux on System z IBM team refer to the Contact the Linux on System z IBM team page.