Description of problem: S390 network devices of type LCS or CTC build on a base driver cu3088, which contains modaliases and is thus loaded without the specific device driver on top. Hence /lib/udev/rules.d/55-ccw.rules and /lib/udev/ccw_init cannot establish ccwgroup devices based on the SUBCHANNELS parameter in /etc/sysconfig/network-scripts/ifcfg-*. Version-Release number of selected component (if applicable): initscripts-8.95-1.s390x How reproducible: Build your own /etc/sysconfig/network-scripts/ifcfg-ctc0 for CTC or /etc/sysconfig/network-scripts/ifcfg-eth1 for LCS and the network device won't come up (using the network service). Additional info: I suggest introducing udev rules that load the corresponding network device drivers based on the control unit type and model. The udev rules have already been discussed on anaconda-devel for upstream: https://www.redhat.com/archives/anaconda-devel-list/2009-March/msg00125.html. Please note that the matching string for cutype need to be lower case in order to work. This is similar to bug 475721-"[rhel5.3] Alias ctc and iucv interfaces doesn't work , devices not able to group on-boot" on RHEL 5.
There exists support in modprobe for a 'ccw' map file. This would imply that there is a way to code this directly in the kernel. See also the 'ssb' bus and modalias support used on x86 machines for things like broadcom wireless.
We had this discussion already. Please see the link into the mailing list archive, I provided.
If the drivers have been fixed upstream (as you state), then we will just pull that in. What's the git commit, or when was it merged?
I'm sorry, I was wrong about the upstream state. There is an internal patch and we could not yet push it upstream since there are two network adapters, which can be both lcs or ctcm. These are 3088/08 and 3088/1f. Hence, we cannot bring the modaliases into either lcs or ctcm. I suppose it is furthermore not possible to have the same modalias in both lcs *and* ctcm, such that both modules get loaded and the corresponding one would detect the actual device type on probing. My udev rules are able to fix this problem.
(In reply to comment #4) > I suppose it is furthermore not > possible to have the same modalias in both lcs *and* ctcm, such that both > modules get loaded and the corresponding one would detect the actual device > type on probing. Why not? We do this with drivers on the PC side all the time.
------- Comment From kumarr.com 2009-10-19 18:40 EDT------- Mirroring
Created attachment 367328 [details] Remove cu3088-driver for lcs and ctcm ------- Comment on attachment From ursula.braun.com 2009-11-03 12:14 EDT------- The cu3088-driver used as common base for lcs- and ctcm-devices makes it difficult to assign the appropriate driver to an lcs-device or a ctcm-device. This patch proposal eliminates the cu3088-driver and thus the root device "cu3088". Path /sys/devices/cu3088 is replaced with the pathes /sys/devices/lcs and /sys/devices/ctcm. There exist 2 device types, which are associated with both drivers lcs and ctcm. To guarantee correct behavior for them the following statements could be added to /lib/udev/ccw_init before the group operation: # select correct driver for hybrid devices 3088/08 and 3088/1f DRIVER=$(readlink $DEVPATH/driver) DRIVER=${DRIVER##*/} CHANNEL2=${SUBCHANNELS##*,} if [ "$DRIVER" = "lcs" -a "${DEVICETYPE}" = "ctc" ]; then echo "$CHANNEL" > /sys/bus/ccw/drivers/lcs/unbind echo "$CHANNEL" > /sys/bus/ccw/drivers/ctcm/bind echo "$CHANNEL2" > /sys/bus/ccw/drivers/lcs/unbind echo "$CHANNEL2" > /sys/bus/ccw/drivers/ctcm/bind fi if [ "$DRIVER" = "ctcm" ]; then if [ "${DEVICETYPE}" = "Ethernet" -o "${DEVICETYPE}" = "Token Ring" ]; then echo "$CHANNEL" > /sys/bus/ccw/drivers/ctcm/unbind echo "$CHANNEL" > /sys/bus/ccw/drivers/lcs/bind echo "$CHANNEL2" > /sys/bus/ccw/drivers/ctcm/unbind echo "$CHANNEL2" > /sys/bus/ccw/drivers/lcs/bind fi fi
Has this patch been sent upstream at all?
------- Comment From ursula.braun.com 2009-11-04 02:43 EDT------- no, the patch has not yet been send upstream. Yesterday I have just added the patch to this bugzilla and made it available for our internal driver build. Now I prefer to wait a few days, if I receive any comments. If not, I will post it upstream soon.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
------- Comment From ursula.braun.com 2009-11-18 08:22 EDT------- Patch is submitted upstream for 2.6.33 and accepted by David Miller. It is contained in net-next: http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commitdiff;h=0ca8cc6fe7e1acd42a8a3741473ad7540f13893a
I think comment 10 and comment 11 provide what Bill asked for with needinfo so I add this comment to clear the flag.
------- Comment From ursula.braun.com 2009-12-09 06:23 EDT------- What's RedHat's position here? Is cu3088-removal regarded as problem solution? Has the patch been verified? Should we provide this patch as official RHEL6-patch?
I have not tested it, but it sounds better than the status quo. A patch against RHEL 6 would be nice.
------- Comment From ursula.braun.com 2010-01-20 13:18 EDT------- Patch is posted to RedHat in bugzilla 507211.
Created attachment 385874 [details] linux-2.6.32-s390-cu3088-remove.diff ------- Comment on attachment From brueckner.ibm.com 2010-01-21 02:52 EDT------- Bill, here's an patch update for recent RHEL6 trees. In order to include it for RHEL6, could change the product to RHEL6 or open a new BZ for the RHEL6 product. Thanks.
I'd just like to remind and point out that the kernel patch requires Ursula's additions from comment 7 to /lib/udev/ccw_init of initscripts. Otherwise network devices of some subtypes of ctc or lcs still won't come up correctly.
------- Comment From mgrf.com 2010-03-16 09:33 EDT------- Hello Red Hat, Please include the fix for this BZ for RHEL6 This BZ impacts the R6 accepted feature request - if not included for R6 47988 - RHBZ 463607 [LTC 6.0 FEAT] 201176:Merge CTCMPC into CTC device driver for upstream integration
------- Comment From mgrf.com 2010-03-17 06:44 EDT------- (In reply to comment #16) > Hello Red Hat, > Please include the fix for this BZ for RHEL6 > > This BZ impacts the R6 accepted feature request - if not included for R6 > 47988 - RHBZ 463607 [LTC 6.0 FEAT] 201176:Merge CTCMPC into CTC device > driver for upstream integration Please ignore my previous comment in this Fedora BZ. Because this is the related RHEL6 BZ LTC 60330 - RH557522- need udev rules to automatically load s390 network device drivers for LCS and CTC -> that is fixed and fix is included in RHEL6.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.