2008-02-01 kernel 2.6.16 bug fix patch 20 ("October 2005")

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

linux-2.6.16-s390-20-october2005.tar.gz / MD5 ... accumulated patch, recommended (2008-02-01)

linux-2.6.16-s390-20-october2005-patches.tar.gz / MD5 ... per-problem-patches, recommended (2008-02-01)

This patch contains the following linux kernel bug fixes:

Description:
cio: Add missing re-probe loop end statement.
Symptom:
Initial device probing causes high CPU load for almost a minute.
Problem:
Device probing needlessly loops over empty subchannel sets.
Solution:
Skip empty subchannel set while looping.
Problem-ID:
40738
Description:
cio: Perform single-path sense id.
Symptom:
Devices are not recognized.
Problem:
sense id with a path mask indicating multiple paths may initially fail up to 8 times (once per path), therefore exhausting the specified maximum re-try count of 3. As a result, the device recognition procedure fails for the respective device.
Solution:
Perform sense id on a single path only.
Problem-ID:
40296
Description:
dasd: Setting a dasd online fails if the initial probe failed.
Symptom:
Issuing for example "chccwdev -e 4711" will fail.
Problem:
The return value of the set_online function is used as return value for dasd_generic_probe.
Solution:
Return 0 for dasd_generic_probe even if set_online fails.
Problem-ID:
40875
Description:
lcs: Channel errors drive lcs_recovery which leads to kernel panic.
When the lcs IRQ routine detects channel failures it drives device recovery. After this event the device is no longer usable for shutdown requests, because the lcs_irq routine may get wrong channel status info.
Symptom:
Kernel panic after lcs recovery.
Problem:
lcs works on wrong buffer.
Solution:
lcs_irq routine marks the channel in "error" state. The channel state comes back to "running" after restarting the channel.
Problem-ID:
41636
Description:
qeth: HiperSockets layer-3 interface drops packets that are neither IPv4- nor IPv6-packets.
HiperSockets infrastructure (layer-3 mode) supports only IPv4 and IPv6 packets.
Symptom:
Sending other packet types disturbs TCP/IP on z/VM, which issues messages about invalid packets.
Problem:
qeth sends packets over HiperSockets that are neither IPv4 nor IPv6.
Solution:
qeth send routine will detect packet type on sending over a HiperSockets interface and drop non-IP packets. The error and drop count of the interface is incremented.
Problem-ID:
38980
Description:
qeth: Kernel panic during online setting of OSA devices.
Symptom:
BUG in qeth_set_multicast_list / qeth_set_ip_addr_list.
Problem:
If qeth_set_multicast_list() is performed on two CPUs in parallel, card->ip_list may end corrupted in rare cases.
Solution:
In function __qeth_delete_all_mc() remove card->ip_list entry before invoking qeth_deregister_addr_entry(). Thus a second invocation of qeth_set_multicast_list() can not try to remove the same entry twice.
Problem-ID:
40816
Description:
zfcp: Fix check for handles in abort handler.
Symptom:
When an abort command is running in parallel to a port or unit re-open, zfcp escalates the ERP without a reason.
Problem:
The response to the abort request provides two handles for a port or unit in the FSF status qualifier. The code that compares them was wrong.
Solution:
Fix the comparison of the port or unit handles.
Problem-ID:
41038
Description:
zfcp: Hold queue lock when checking handle for ELS command.
Symptom:
zfcp receives an error "port/unit handle invalid" and escalates the error recovery to "reopen adapter".
Problem:
When issuing an ELS command, zfcp first checks if the unit is unblocked, i.e. the handles are still valid. There is a possible race where this check says that the unit is OK, and then the status changes before the request is finally sent. If a unit/port close command has been sent in this window, the adapter will report "port/unit handle invalid" for the ELS command which will escalate the ERP.
Solution:
We need to hold the queue-lock when checking whether we still have a valid unit/port handle for the ELS command, i.e whether we can issue this request for this unit/port. If the error recovery is about to close this unit/port, then it competes for the queue-lock. If the close request issued by the error recovery wins, then it is guaranteed that this unit/port has been blocked for other requests.
Problem-ID:
41145
Description:
zfcp: Hold queue lock when checking handle for FCP command.
Symptom:
zfcp receives an error "port/unit handle invalid" and escalates the error recovery to "reopen adapter".
Problem:
When issuing an FCP command, zfcp first checks if the unit is unblocked, i.e. the handles are still valid. There is a possible race where this check says that the unit is OK, and then the status changes before the request is finally sent. If a unit/port close command has been sent in this window, the adapter will report "port/unit handle invalid" for the FCP command which will escalate the ERP.
Solution:
We need to hold the queue-lock when checking whether we still have a valid unit/port handle for the FCP command, i.e whether we can issue this request for this unit/port. If the error recovery is about to close this unit/port, then it competes for the queue-lock. If the close request issued by the error recovery wins, then it is guaranteed that this unit/port has been blocked for other requests.
Problem-ID:
41146
Description:
zfcp: Hold queue lock when checking handle for abort command.
Symptom:
zfcp receives an error "port/unit handle invalid" and escalates the error recovery to "reopen adapter".
Problem:
When issuing an abort command, zfcp first checks if the unit is unblocked, i.e. the handles are still valid. There is a possible race where this check says that the unit is OK, and then the status changes before the request is finally sent. If a unit/port close command has been sent in this window, the adapter will report "port/unit handle invalid" for the abort command which will escalate the ERP.
Solution:
We need to hold the queue-lock when checking whether we still have a valid unit/port handle for the abort command, i.e whether we can issue this request for this unit/port. If the error recovery is about to close this unit/port, then it competes for the queue-lock. If the close request issued by the error recovery wins, then it is guaranteed that this unit/port has been blocked for other requests.
Problem-ID:
41142
Description:
zfcp: Hold queue lock when checking handle for task management command.
Symptom:
zfcp receives an error "port/unit handle invalid" and escalates the error recovery to "reopen adapter".
Problem:
When issuing an task management command, zfcp first checks if the unit is unblocked, i.e. the handles are still valid. There is a possible race where this check says that the unit is OK, and then the status changes before the request is finally sent. If a unit/port close command has been sent in this window, the adapter will report "port/unit handle invalid" for the task management command which will escalate the ERP.
Solution:
We need to hold the queue-lock when checking whether we still have a valid unit/port handle for the task management command, i.e whether we can issue this request for this unit/port. If the error recovery is about to close this unit/port, then it competes for the queue-lock. If the close request issued by the error recovery wins, then it is guaranteed that this unit/port has been blocked for other requests.
Problem-ID:
41147
Description:
zfcp: Dismiss actions in ready queue.
Symptom:
Ready actions are kept in ready queue although superseding actions are scheduled.
Problem:
Actions in ready queue are not dismissed.
Solution:
Dismiss actions in ready queue as well.
Problem-ID:
40502
Description:
zfcp: Fix use after free bug.
Symptom:
Possible memory corruption.
Problem:
Possible use of an already freed fsf_req.
Solution:
Check if it is safe to access the fsf_req.
Problem-ID:
40762
Description:
zfcp: Imbalance in erp_ready_sem usage.
Symptom:
Some ERP actions fail for no obvious reason.
Problem:
Imbalance in the usage of the erp_ready_sem.
Solution:
Correct the imbalance.
Problem-ID:
40504

Everybody should apply this patch.

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

linux-2.6.16.tar.gz (from http://www.kernel.org/pub/linux/kernel/v2.6)
+ linux-2.6.16-s390-base-october2005.diff (IBM)
+ linux-2.6.16-s390-01-october2005.diff (IBM)
+ linux-2.6.16-s390-02-october2005.diff (IBM)
+ linux-2.6.16-s390-03-october2005.diff (IBM)
+ linux-2.6.16-s390-04-october2005.diff (IBM)
+ linux-2.6.16-s390-05-october2005.diff (IBM)
+ linux-2.6.16-s390-06-october2005.diff (IBM)
+ linux-2.6.16-s390-07-october2005.diff (IBM)
+ linux-2.6.16-s390-08-october2005.diff (IBM)
+ linux-2.6.16-s390-09-october2005.diff (IBM)
+ linux-2.6.16-s390-10-october2005.diff (IBM)
+ linux-2.6.16-s390-11-october2005.diff (IBM)
+ linux-2.6.16-s390-12-october2005.diff (IBM)
+ linux-2.6.16-s390-13-october2005.diff (IBM)
+ linux-2.6.16-s390-14-october2005.diff (IBM)
+ linux-2.6.16-s390-15-october2005.diff (IBM)
+ linux-2.6.16-s390-16-october2005.diff (IBM)
+ linux-2.6.16-s390-17-october2005.diff (IBM)
+ linux-2.6.16-s390-18-october2005.diff (IBM)
+ linux-2.6.16-s390-19-october2005.diff (IBM)
+ linux-2.6.16-s390-20-october2005.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.