 |
Kernel 2.4 based: June 2003 stream
|
 |
|
|
|
|
jump to next patch
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.4.21-s390-09-june2003.tar.gz
/ MD5 ... accumulated patch, recommended (2004-01-30)
linux-2.4.21-s390-09-june2003-patches.tar.gz
/ MD5 ... per-problem-patches, recommended (2004-01-30)
These patches contain the following linux kernel bug fixes:
| Description: |
dasd: BUG when pulling/plug in fibers associated with ESS. |
| Symptom: |
BUG in dasd ERP leads to kernel panic. |
| Problem: |
The (paranoia) macro in dasd_3990_erp_alternate_path assumes
that the status of the request is ERROR, but it might also be
FILLED (if the situation happens the first time). |
| Solution: |
Only reduce status to QUEUED (do not enhance) |
| Problem-ID: |
5702 |
| Description: |
iucv: Disable message interrupts during connection setup |
| Symptom: |
-- |
| Problem: |
-- |
| Solution: |
Honor incoming connection severed during connection setup |
| Problem-ID: |
5912 |
| Note: |
This patch introduces a problem that is resolved with the fix for Problem-ID 6631 in linux-2.4.21-s390-11-june2003.diff (2004-03-24). |
| Description: |
SCLP: tty driver hangs on write after IOCTL TIOCSCLPSNL. |
| Symptom: |
After configuring the SCLP tty driver to output data after each
single write instead of waiting for a new line character,
subsequent tty write operations will cause the driver to stop
responding. |
| Problem: |
There is a deadlock situation in the tty write function which
occurs when the final_nl setting has been changed using the
TIOCSCLPSNL IOCTL function. |
| Solution: |
Remove the deadlock situation by releasing the sclp_tty_lock
before emitting the current buffer. |
| Problem-ID: |
5805 |
| Description: |
SCLP: linemode tty driver causes kernel BUG(). |
| Symptom: |
Kernel halts with "Scheduling in interrupt" message during tty
output. |
| Problem: |
When the tty buffer is full, the tty write function will wait
for an empty buffer using wait_event(). In case the write function
is called from the flush function which in turn can be called in an
interrupt context, a kernel BUG is caused. |
| Solution: |
Adjust the wait function to use sclp_sync_wait when in
interrupt. |
| Problem-ID: |
5806 |
| Description: |
SCLP: linemode tty driver hangs during output. |
| Symptom: |
The SCLP linemode tty driver stops responding when writing and
reading at the same time. A message "insufficient SCCB length" may
be printed. |
| Problem: |
User input causes an external interrupt which does not signal
the completion of a previous buffer, while the interrupt handler
assumes that the SCLP has finished processing of the last
buffer. |
| Solution: |
Fix the interrupt handler to check whether processing of an
SCCB has finished. |
| Problem-ID: |
5807 |
| Description: |
SCLP: kernel crashes when too many empty buffers are
generated. |
| Symptom: |
The SCLP linemode console and tty driver crash with a
"Specification Exception" when too many empty buffers are
generated, e.g. when writing large strings of null-bytes. |
| Problem: |
Handling of empty buffers causes a recursive call chain which
can exceed stack space and cause erratic kernel behavior. |
| Solution: |
Do not emit empty buffers. |
| Problem-ID: |
5808 |
| Description: |
SCLP: linemode tty/console driver causes kernel crash. |
| Symptom: |
When printing large amounts of data to the SCLP linemode tty or
console driver, a kernel crash or other erratic behavior may
occur. |
| Problem: |
There is an off by one error in the generic SCLP write routine
which returns one byte more than actually written in some cases. As
the return value is used in some write loops with unsigned loop
variables, subtracting one byte more can cause an integer overflow,
resulting in erratic behavior. |
| Solution: |
Fix the off by one error. |
| Problem-ID: |
5809 |
| Description: |
qeth/lcs: multicast joins and drops not noticed by drivers |
| Symptom: |
multicast traffic is not received |
| Problem: |
driver didn't notice stack using multicast addresses |
| Solution: |
use notifier_call_chain to notify drivers |
| Problem-ID: |
5921 |
| Description: |
qeth: IPv6 and VLAN traffic problems |
| Symptom: |
v6 VLAN packets don't get through |
| Problem: |
flags have been set incorrectly |
| Solution: |
set flags appropriately |
| Problem-ID: |
5923 |
| Description: |
qeth: interrupt reduction for OSAs |
| Symptom: |
n/a |
| Problem: |
more interrupts than needed have been presented |
| Solution: |
set interrupt request flags smarter |
| Problem-ID: |
5924 |
| Description: |
qeth: fix delete ARP and add/delete ARP response times |
| Symptom: |
I/O error message on qetharp -a or -d |
| Problem: |
didn't process reply correctly |
| Solution: |
fix ioctl IPA reponse behaviour |
| Problem-ID: |
5925 |
| Description: |
qdio: lock leak in qdio |
| Symptom: |
crashes |
| Problem: |
inconsistency in locking |
| Solution: |
proper lock handling |
| Problem-ID: |
5926 |
| Description: |
qdio: problems with more than 64 adapter interrupt capable
devices |
| Symptom: |
devices not initialized when using more than 64 adapter
interrupt capable devices |
| Problem: |
interrupt indicator bit sharing incorrect |
| Solution: |
improved shared indicator processing |
| Problem-ID: |
5927 |
| Description: |
zfcp: unneccessary error recovery for unrecoverable
targets |
| Symptom: |
The error recovery was forced into escalation after a target
(adapter, port, unit) became unrecoverable during error recovery.
This might have caused I/O disruption for working targets, which
were impacted by recovery escalation. |
| Problem: |
While the error recovery strategy has always been able to mark
targets unrecoverable on exceeding the number of allowed recovery
retries and thereupon has stopped recovery for these targets, it
failed to recognise conditions when a target had been marked
unrecoverable for other reasons, i.e. not within the error recovery
context. |
| Solution: |
Prior to the determination of follow-up actions in zfcp error
handler, the 'unrecoverable' flag of targets always needs to be
inspected. Escalation for unrecoverable targets has to be avoided,
regardless of the origin of the 'unrecoverable' status. |
| Problem-ID: |
5915 |
Everybody should apply this patch.
To create the complete linux kernel sources, the following
patches need to be applied in sequence:
linux-2.4.21.tar.gz (see www.kernel.org)
+ linux-2.4.21-s390-june2003.diff (IBM)
+ linux-2.4.21-s390-01-june2003.diff (IBM)
+ linux-2.4.21-s390-02-june2003.diff (IBM)
+ linux-2.4.21-s390-03-june2003.diff (IBM)
+ linux-2.4.21-s390-04-june2003.diff (IBM)
+ linux-2.4.21-s390-05-june2003.diff (IBM)
+ linux-2.4.21-s390-06-june2003.diff (IBM)
+ linux-2.4.21-s390-07-june2003.diff (IBM)
+ linux-2.4.21-s390-08-june2003.diff (IBM)
+ linux-2.4.21-s390-09-june2003.diff (IBM)
Note: If On-demand timer is required, apply as last patch:
+ linux-2.4.21-s390-timer-02-june2003.diff (IBM)
Note: To use OSA-Express Direct SNMP, also install s390-tools
1.2.2 or later.
Note: Using broadcast in VM Guest LAN requires APAR VM63397.
Note: If you apply this patch and are using iucv you may run into
Problem-ID 6631, the fix for which is included in
linux-2.4.21-s390-11-june2003.diff (2004-03-24).
|
|
|
|
|
