2006-04-28 kernel 2.6.5 bug fix patch 35 ("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-35-april2004.tar.gz / MD5 ... accumulated patch, recommended (2006-04-28)

linux-2.6.5-s390-35-april2004-patches.tar.gz / MD5 ... per-problem-patches, recommended (2006-04-28)

These patches contain the following linux kernel bug fixes:

Description:
cio: Enable interrupts on error path.
Symptom:
Interrupts could stay disabled if error occured in _chp_add().
Problem:
Use of spin_unlock() instead of spin_unlock_irq().
Solution:
Use spin_unlock_irq().
Problem-ID:
23146
Description:
cio: I/O failing after CHPID is offline despite remaining CHPIDs.
Symptom:
I/O on a DASD is failing with no retry left after turning one channel path to the device off and on multiple times (via HMC), even though other channel paths still remain operational.
Problem:
Sporadic unsuccessful termination of pending I/O when CHPID is set offline.
Solution:
Fix race condition in termination logic.
Problem-ID:
23146
Description:
kernel: Signal handling bug.
Symptom:
Process crashes on signal delivery.
Problem:
If a signal handler has been established with the SA_ONSTACK option but no alternate stack is provided with sigaltstack(), the kernel still tries to install the alternate stack. Also when setting an alternate stack with sigaltstack() and the SS_DISABLE flag, the kernel tries to install the alternate stack on signal delivery.
Solution:
Use the correct condition sas_ss_flags() to check if the alternate stack has to be used.
Problem-ID:
23355
Description:
kernel: Bug in setup_rt_frame().
Symptom:
Process terminates unexpectedly.
Problem:
setup_rt_frame() writes the wrong system call number on the stackframe. When the signal handler returns via this system call the kernel terminates the process.
Solution:
Use correct system call number.
Problem-ID:
23074
Note:
This patch fixes a bug which was introduced with patch linux-2.6.5-s390-34 (Problem-ID 23074)
Description:
net: initcall order.
Symptom:
Kernel hangs or is unstable if network code is compiled in.
Problem:
If the network code is compiled into the kernel the initcalls of all network drivers are done before inet_init(). This is the wrong order since the drivers rely on data structures that get initialized from inet_init().
Solution:
Raise priority of inet_init() initcall from device_initcall() to fs_initcall().
Problem-ID:
22969
Description:
qdio: I/O stall with zfcp in low-memory situation.
Symptom:
SCSI I/O stall in low-memory situation.
Problem:
qdio allocates memory with GFP_KERNEL during qdio_establish and qdio_shutdown. zfcp must call these functions when performing error recovery for an adapter. This can lead to a situation where qdio waits for memory and zfcp (SCSI) waits for end of its error recovery. In case zfcp (SCSI) is needed to swap pages this can lead to an I/O stall.
Solution:
Avoid memory allocation with GFP_KERNEL in qdio_establish and qdio_shutdown and introduce memory pool to allow these qdio operations in low memory situations.
Problem-ID:
22223
Description:
qeth: Race condition possible during device recovery.
Symptom:
Kernel panic while device is recovering.
Problem:
While device is recovering network stack could send packets and is even able to call qeth's hard_start_xmit routine. Using netif_stop_queue outside dev->hard_start_xmit is dangerous, because it could happen that the network stack holds the xmit_lock while still sending a packet.
While setting qeth device online netif_wake_queue is called although the device is not in UP state.
Solution:
Only call netif_wake_queue when device is up. Rather use netif_tx_disable than netif_stop_queue outside from qeth_hard_start_xmit routine.
Problem-ID:
23195
Description:
qeth: System crash during data transmission.
Symptom:
Addressing exception when sending data with qeth driver.
Problem:
qeth_hard_start_xmit() prepares the skb for the OSA-card and turns it over to the OSA-card. Afterwards it updates some statistical data. To do this it makes use of skb-values. But the skb might already be freed by the qeth_qdio_output_handler.
Solution:
Save skb-values still used after skb_delivery to the OSA-card before handing the skb over to the OSA-card.
Problem-ID:
23458

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)
+ linux-2.6.5-s390-34-april2004.diff (IBM)
+ linux-2.6.5-s390-35-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.