Kernel patches

2003-10-31 kernel 2.4.21 bug fix patch 06 ("June 2003")

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:
  1. first osasnmpd is running
  2. start second osasnmpd (or any other program using the same proc interface)
  3. 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.

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.