 |
Kernel 2.6 based: April 2004 stream
|
 |
|
|
|
|
jump to xref
jump to Download Area
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-48-april2004.tar.gz
/ MD5 ... accumulated patch, recommended (2008-05-07)
linux-2.6.5-s390-48-april2004-patches.tar.gz
/ MD5 ... per-problem-patches, recommended (2008-05-07)
These patches contain the following linux kernel bug fixes:
| Description: |
dasd: Fix ifcc handling. |
| Symptom: |
The dasd default ERP runs out of re-tries. |
| Problem: |
There is no correct handling of Interface Control Checks (ifcc). |
| Solution: |
Implemented the correct handling of ifcc's. First retry the request up to 255 times and when all re-tries fail, try an alternate path if available. |
| Problem-ID: |
42187 |
| Description: |
lcs: CCL-sequence numbers required for protocol 802.2 only. |
| Symptom: |
Slow CCL response time. |
| Problem: |
non-ETH_P_802_2 packets are not delivered to NDH for Communication Controller for Linux on System z (CCL). But CCL detects missing sequence numbers, which cause a serious performance problem with CCL. |
| Solution: |
Assign sequence numbers to 802.2 packets only. |
| Problem-ID: |
43012 |
| Description: |
qdio: Undetected inbound traffic with many online FCP devices. |
| Symptom: |
zfcp host/bus re-set because of problems with unit (LPAR). |
| Problem: |
Usually every FCP device has its own indicator field which the adapter uses to signal outstanding work. Once a certain limit of devices is reached, a common indicator field is used. In certain scenarios qdio re-sets this common indicator field, but handles only part of the FCP-devices sharing the common indicator field. Thus inbound traffic on the non-processed shared FCP-devices is not recognized immediately. |
| Solution: |
Make sure common indicator field is re-set only, if all FCP-devices sharing the indicator are processed. |
| Problem-ID: |
44083 |
| Description: |
qdio: Change in timeout handling during qdio establish. |
| Symptom: |
System hang when establishing qdio queues. |
| Problem: |
If qdio establish runs in parallel with a channel error, ccw_device_start_timeout may not trigger the qdio_timeout_handler. In this case none of the states ESTABLISHED nor ERROR is reached and the following wait_event hangs forever. |
| Solution: |
Do not make use of the timeout option with ccw_device_start, but add a timeout to the following wait_event. |
| Problem-ID: |
43126 |
| Description: |
qdio / zfcp: slow database write I/O to FCP/SCSI disk. |
| Symptom: |
Database write I/O to FCP/SCSI disk getting caught steadily. Running on LPAR, database load times increase by more than factor 10 compared to ECKD disks. |
| Problem: |
qdio tries to avoid adapter interrupts by exploiting a certain kind of polling state. When leaving this state, qdio may overlook an arrived buffer in a certain scenario. This scenario occurs only for zfcp-usage, not for qeth-usage. |
| Solution: |
Make sure qdio takes notice of additionally arriving buffers in any cases. |
| Problem-ID: |
42681 |
| Description: |
qeth: CCL-sequence numbers required for protocol 802.2 only. |
| Symptom: |
Slow CCL response time. |
| Problem: |
non-ETH_P_802_2 packets are not delivered to NDH for Communication Controller for Linux on System z (CCL). But CCL detects missing sequence numbers, which cause a serious performance problem with CCL. |
| Solution: |
Assign sequence numbers to 802.2 packets only. |
| Problem-ID: |
42811 |
| Description: |
qeth: Avoid inconsistent lock state for inet6_dev->lock. |
| Symptom: |
qeth recovery hang was observed, but other problems may have been possible. |
| Problem: |
ipv6_regen_rndid in net/ipv6/addrconf.c makes use of "write_lock_bh" for its inet6_dev->lock. It may run in softirq-context. qeth makes use of "read_lock" for the same inet_dev->lock. This can cause a deadlock. |
| Solution: |
Use read_lock_bh to get inet6_dev->lock. |
| Problem-ID: |
44102 |
| Description: |
qeth: Recovery problems with failing STARTLAN. |
| Symptom: |
Linux does not fully recover an OSA-device interface. |
| Problem: |
- A STARTLAN command from the adapter may arrive while a qeth recovery is currently running with a failed qeth STARTLAN. Usually qeth schedules a recovery when receiving a STARTLAN command from the adapter. But another recovery scheduled while a recovery is already running never starts. Thus the qeth-administered lan_online flag remains zero in this scenario, even though the adapter-STARTLAN has happened.
- If setting of an ip-address fails with LAN_OFFLINE, qeth does not save the ip-address in its internal list of set ip-addresses. qeth recovers after a following STARTLAN event, but cannot set the unsaved ip-address.
|
| Solution: |
- Set lan_online flag for a received STARTLAN from the adapter in case scheduled recovery does not start and get rid of the superfluous extra STARTLAN for IPv6.
- Save the ip-address in the qeth-maintained list of ip-addresses after a LAN_OFFLINE failure for SETIP.
- Further error checkings for ip-address handling (especially important in IP-address takeover scenarios, to enable re-takeover of a taken over IP address).
|
| Problem-ID: |
43124 |
| Description: |
qeth: eddp skb buff problem running EDDP guestlan. |
| Symptom: |
Kernel panic. |
| Problem: |
Wrong skb buffer size calculation. |
| Solution: |
Corrected buffer size calculation. |
| Problem-ID: |
43200 |
| Description: |
sclp: Console lock-up during SE warmstart. |
| Symptom: |
HMC operating system console no longer processes input. |
| Problem: |
State change event caused by warm-start invalidates event mask. |
| Solution: |
Fix mask naming inconsistency in state change handler. |
| Problem-ID: |
42413 |
| Description: |
zfcp: Fix handling for boxed port after physical close. |
| Symptom: |
zfcp escalates ERP to re-open the adapter after a remote port disappeared. |
| Problem: |
When two or more Linux systems share one adapter and see the same remote port, both get informed about the broken remote port and both will issue a "close physical port" at the same time during the "port reopen" procedure. As a result one Linux will receive a good status for the "close physical port" request and the other one boxed. The problem is that the boxed response here is actually a "good" status and the procedure can continue without escalation to adapter re-open. |
| Solution: |
Treat the "boxed" response for "close physical port" the same as the "good" response. |
| Problem-ID: |
42000 |
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)
+ linux-2.6.5-s390-36-april2004.diff (IBM)
+ linux-2.6.5-s390-37-april2004.diff (IBM)
+ linux-2.6.5-s390-38-april2004.diff (IBM)
+ linux-2.6.5-s390-39-april2004.diff (IBM)
+ linux-2.6.5-s390-40-april2004.diff (IBM)
+ linux-2.6.5-s390-41-april2004.diff (IBM)
+ linux-2.6.5-s390-42-april2004.diff (IBM)
+ linux-2.6.5-s390-43-april2004.diff (IBM)
+ linux-2.6.5-s390-44-april2004.diff (IBM)
+ linux-2.6.5-s390-45-april2004.diff (IBM)
+ linux-2.6.5-s390-46-april2004.diff (IBM)
+ linux-2.6.5-s390-47-april2004.diff (IBM)
+ linux-2.6.5-s390-48-april2004.diff (IBM)
|
|
|
|
|
