 |

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-06-june2003.tar.gz
/ MD5 ... accumulated patch, recommended (2003-10-31)
linux-2.4.21-s390-06-june2003-patches.tar.gz
/ MD5 ... per-problem-patches, recommended (2003-10-31)
These patches contain the following linux kernel bug fixes:
| Description: |
Crashes, triggered by iucv and ctc when calling
dst_link_failure() |
| Symptom: |
Miscellaneous crashes, triggered by calling
dst_link_failure() |
| Problem: |
Calling dst_link_failure() triggers a bug in common code. |
| Solution: |
Removed call of dst_link_failure() in both netiucv.c and
ctcmain.c |
| Problem-ID: |
5098 |
| Description: |
DHCP does not work with HiperSockets guest LAN |
| Symptom: |
dhcpcd tries to get an IP address for a HiperSocket guest LAN
device from a dhcp server residing in the same guest LAN |
| Problem: |
qeth doesn't queue broadcast packets in the last queue when
they are not passed through the network stack, means: raw packets.
The code for checking this is missing and those packets are queued
in the default queue so that HiperSockets microcode doesn't send
them out. |
| Solution: |
check if raw packets are broad/multicast and queue them in the
correct queue. |
| Problem-ID: |
4873 |
| Description: |
Fixed S390 Debug Feature usage. |
| Symptom: |
Segmentation fault when DBF file is read. |
| Problem: |
The sprintf event/exception functions write a pointer to the
format string (%s) into the log. This means that the string must be
valid at the time the DBF-log is read. |
| Solution: |
Don't write 'volatile' strings to DBF. |
| Problem-ID: |
4822 |
| Description: |
Incorrect calculation of max_blocks in DIAG discipline |
| Symptom: |
BUG in dasd_alloc_request |
| Problem: |
Maximum size request can not be handled by dasd device
driver. |
| Solution: |
Make sure the request size fits (correct calculation). |
| Problem-ID: |
4922 |
| Note: |
applicable for 31-bit Linux, only |
| Description: |
Race Conditions in qeth when more than one osasnmpd is
running |
| Symptom: |
- first osasnmpd is running
- start second osasnmpd (or any other program using the same proc
interface)
- on qeth interface changes (new/shutdown qeth device)
a) not every waiting osasnmpd will be signaled
b) terminating all osasnmpd except one leads to an osasnmpd working
unproperly because of race conditions in qeth.
|
| Problem: |
osasnmpd opens an procfile ioctl which does nothing else than
blocking the osasnmpd and return when something has happened with
any qeth devices. If qeth device changes occur too fast, it is not
guaranteed that every osasnmpd blocked by the ioctl will have the
latest device list. |
| Solution: |
Removed the blocking ioctl mechanism and changed interfaces.
osasnmpd has to register at qeth and will be signaled when
something occurs. osasnmpd has now a signal handler so that there
is no need anymore for threads and fork call in osasnmpd. |
| Problem-ID: |
4078 |
| Note: |
This qeth-fix requires a corresponding fix which is included in
s390-tools 1.2.2, if you are using OSA-Express Direct SNMP. |
| Description: |
VIPA and Proxy ARP problems on qeth |
| Symptom: |
add_rxip4, add_vipa4 etc. do not work |
| Problem: |
control flags not set correctly, netmask bad for VSWITCH |
| Solution: |
fixed flags, use 0 as default netmask |
| Problem-ID: |
5178 |
| Description: |
HiperSockets Network Concentrator
New HiperSockets Network Concentrator for the Linux environment can
simplify network addressing between HiperSockets and
OSA-Express.
Please see Restrictions
- HiperSockets Network Concentrator |
| Symptom: |
n/a |
| Problem: |
n/a |
| Solution: |
n/a |
| Problem-ID: |
n/a |
| Description: |
avoid hang during initialization on I/O errors |
| Symptom: |
system hangs when initializing |
| Problem: |
on I/O errors, a lock was not released |
| Solution: |
release the lock |
| Problem-ID: |
4971 |
| Description: |
console: kernel compilation fails in
drivers/s390/char/ctrlchar.c |
| Symptom: |
Compiling the kernel when option CONFIG_MAGIC_SYSRQ is not set
fails with an error in ctrlchar.c |
| Problem: |
The file linux/sysrq.h which is included from ctrlchar.c
requires that linux/errno.h is included in case CONFIG_MAGIC_SYSRQ
is not set. |
| Solution: |
Add include directive for linux/errno.h to ctrlchar.c prior to
including linux/sysrq.h |
| Problem-ID: |
4797 |
| Description: |
crashes triggered by s390 network drivers calling
dst_link_failure |
| Symptom: |
crashes, bugs in icmp.c |
| Problem: |
network driver called dst_link_failure |
| Solution: |
remove dst_link_failure call |
| Problem-ID: |
5108 |
| Description: |
fake_ll source MAC problem |
| Symptom: |
when fake_ll is used on older OSA code, the source MAC is
incorrect |
| Problem: |
Ethernet header cleared at wrong offset |
| Solution: |
clear Ethernet header at source MAC offset |
| Problem-ID: |
4982 |
| Description: |
tape: Fix implementation of NOP mtio operation. |
| Symptom: |
The NOP call fails for 34xx devices if no tape medium is
present. On 3590 devices it succeeds but accidentally changes the
medium state to LOADED, regardless of the real medium state. |
| Problem: |
As stated in mtio.h the NOP call should do nothing but update
the device status that can be read by MTIOCGET. |
| Solution: |
Ignore the no medium unit check for NOP in tape_34xx but update
the generic status flags (DR_OPEN). Do not change the generic
status after a NOP command in tape_3590. |
| Problem-ID: |
4427 |
| Description: |
tape: Initially boxed tapes might become invisible. |
| Symptom: |
Tapes that where assigned during module load might not show up
in the /proc/tapedevices output and can't be accessed. |
| Problem: |
Common I/O layer somehow detects the assignment and refuses to
return an interrupt. |
| Solution: |
Ignore -EUSERS during setup but mark the device as boxed and
still in INIT. Later calls to tape_open() will retry to get an
interrupt and return an error if the device still can't be
accessed. |
| Problem-ID: |
4421 |
| Description: |
z90crypt incorrectly detects PCIXCC as PCICC |
| Symptom: |
Incorrect data presented in /proc entry, and work is sent to a
PCIXCC as if it were a PCICC |
| Problem: |
Incorrectly setting a device to ONLINE when it is of unknown
type. |
| Solution: |
Only set a device to ONLINE when its type is known |
| Problem-ID: |
5106 |
| Description: |
zfcp: SCSI I/O stall due to missed local-link-up event |
| Symptom: |
SCSI I/O for a devno was not continued after the local link
came operational again. But, manual intervention (reset erp) could
be used to resurrect that devno. |
| Problem: |
If the link-up event was reported by a type2 instead of an
unsolicited status, the device driver did not reset corresponding
flags and thus failed to recover that devno. |
| Solution: |
Reset 'failed' and 'link-down' flag in case of type2. |
| Problem-ID: |
5151 |
| Description: |
zfcp: arbitrary (and bewildering) order of entries in
/proc/scsi/zfcp/map |
| Symptom: |
/proc/scsi/zfcp/map did not reflect the order of the addition
of zfcp map entries. That is why, it could not be used to store an
existing device configuration reliably as it might cause devices to
be reflected by different device nodes when being used as mapping
next time the zfcp driver is loaded. |
| Problem: |
The order of entries in /proc/scsi/zfcp/map was determined by a
depth-first search algorithm applied to the zfcp internal tree
representing configured devices, which does not necessarily reflect
the genesis of the FCP device configuration. |
| Solution: |
An additional list has been introduced which reflects the order
of map entry additions and which is used for the compilation of
/proc/scsi/zfcp/map |
| Problem-ID: |
5140 |
| Description: |
zfcp: incomplete fix for dynamic SCSI adapter addition in
scsi_mod |
| Symptom: |
ls -al /proc/scsi causes segmentation fault and oops after
unloading unused zfcp (zfcp without any map entry supplied) |
| Problem: |
first: scsi_host_template was not added to list if no scsi_host
had been detected and registered in the first instance, second:
miscalculation of scsi_hosts registered for each
scsi_host_template |
| Solution: |
first: scsi_host_template needs to be added to list regardless
of the fact that no scsi_host might have been registered (scsi_host
might become available later and scsi_host_template still needs to
be there), second: move accounting of registered scsi_hosts into
scsi_register() / scsi_unregister() where a new scsi_hosts is added
or removed respectively |
| Problem-ID: |
5135 |
| Description: |
zfcp: infinite error recovery escalation for certain port
failure |
| Symptom: |
While trying to open a target port which either rejects PLOGI
or PRLI, the error recovery went about doing 'Open LUN' - whereas,
the LUN could not be opened due to an invalid port handle (0x0), as
reported by an error message. Consequently, recovery was escalated.
This forced the associated devno into an infinite recovery
loop. |
| Problem: |
Erroneous checking of port state due to misleading semantics of
atomic_test_mask, which returned true, if at least one bit of mask
was set |
| Solution: |
Corrected semantics of atomic_test_mask and adapted all uses of
it. atomic_test_mask now returns true only if all bits in mask are
set. |
| Problem-ID: |
5144 |
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)
Note: If On-demand timer is required, apply as last patch:
+ linux-2.4.21-s390-timer-01-june2003.diff (IBM)
Note: If you apply the above patches, you need as a minimum
the 2003-10-31 version of the tape_3590 OCO module
"tape3590-2.4.21-s390(x)-01-june2003.tar.gz".
Note: To use OSA-Express Direct SNMP, also install s390-tools
1.2.2.
Note: Using broadcast in VM Guest LAN requires APAR
VM63397.
|
|
 |
|
 |