Redhat Team,
This bug report should have gone to Issue tracker instead of Redhat Bugzilla. Sorry for the mistake.  Please let us know if  this can be linked to an Issue tracker  (RIT) record  and any additional action required from our side for the same.
Thanks, Supriya

-> initscripts, not NetworkManager.

What happens if you load them by hand with rc.modules?

checked iucv-interfaces on my RHEL5-system.
iucv-interfaces do not come up when booting, but they come up smoothly with "ifup iucv0" with this ifcfg-iucv0:
[root@xxx ~]# cat /etc/sysconfig/network-scripts/ifcfg-iucv0
DEVICE=iucv0
USERCTL=no
ONBOOT=yes
BOOTPROTO=none
BROADCAST=
NETWORK=
NETMASK=255.255.255.255
IPADDR=10.90.90.16
GATEWAY=10.90.90.17
PEERID=h0545017
NETTYPE=iucv
TYPE=IUCV
GATEWAYDEV=eth0

Key GATEWAY is somehow misleading for a point-to-point iucv connection.

Putting back in NEEDINFO.

ifup-ctc and ifup-iucv instruct the user to append alias definitions

to /etc/modprobe.conf. However, they are ineffective and CTC or IUCV

network devices won't come up.

head initscripts-8.45.19.EL/sysconfig/network-scripts/ifup-ctc initscripts-8.45.19.EL/sysconfig/network-scripts/ifup-iucv

==> initscripts-8.45.19.EL/sysconfig/network-scripts/ifup-ctc <==

#!/bin/bash

#

# /etc/sysconfig/network-scripts/ifup-ctc

#

# the ctc network driver is a point-to-point driver on S/390 machines

#

# To get the ctc module to load automatically at boot, you will need to

# add the following line to /etc/modprobe.conf:

#

# alias ctc0 ctc

==> initscripts-8.45.19.EL/sysconfig/network-scripts/ifup-iucv <==

#!/bin/sh

#

# /etc/sysconfig/network-scripts/ifup-iucv

#

# the iucv network driver is a point-to-point driver on S/390 machines

#

# To get the iucv module to load automatically at boot, you will need to

# add the following line to /etc/modprobe.conf:

#

# alias iucv0 netiucv

Trying to access ${DEVICE} with ifconfig won't work unless the

necessary CCW channels have been grouped and set online in order to

allocate a network device to operate on. However, this will only

happen on loading the CTC driver module which will in turn generate

udev events triggering /lib/udev/ccw_init doing the grouping and

setting online. There is nothing in ifup-ctc which would automatically

load the driver (even indirectly by means of kerneld). => Break the

deadlock by explicitly handling alias in /etc/modprobe.conf as is done

in ifup-eth.

[ Theoretically this is also true for LCS network devices. However, this

is taken care of by loading the lcs driver along with the underlying

base driver cu3088, which gets loaded automatically by means of

udev and modaliases for any LCS or CTC device.

https://bugzilla.linux.ibm.com/show_bug.cgi?id=28504#c22

https://bugzilla.redhat.com/show_bug.cgi?id=236097 ]

Created attachment 329450 [details]
Break deadlock by explicitly handling alias for CTC and IUCV in /etc/modprobe.conf as is done in ifup-eth.



(text from previous comment continued here...)

There is nothing in ifup-iucv which would automatically load the
driver (even indirectly by means of kerneld) before trying to access a
sysfs attribute, which is only there if the driver has already been
loaded. => Break the deadlock by explicitly handling alias in
/etc/modprobe.conf as is done in ifup-eth.

The two fixes have been successfully tested on RHEL 5.2.

ACK for 5.4. For future releases, these devices need to load automatically.

Please test the erratum candidate:
http://people.redhat.com/harald/downloads/initscripts/initscripts-8.45.26.1.el5/

------- Comment From sglass.com 2009-05-05 13:19 EDT-------
Since this is in RH cvs tree, moving to Accepted state

------- Comment From MAIER.com 2009-06-21 12:23 EDT-------
Red Hat,

thanks a lot for integrating the fixes. With RHEL 5.4 alpha from RHEL5.4-Server-20090611.0-s390x-DVD.iso, I could verify the correct behavior for s390 network devices of type NETIUCV. However, I was wrong about the fix for CTC and am very sorry about that. Using the is_available function in ifup-ctc does not help, since it is too late at this point for loading the driver. /etc/udev/rules.d/55-ccw.rules triggers on an ADD udev event of a set of CCW devices (including CTC network devices) and calls /lib/udev/ccw_init which in turn uses the parameters SUBCHANNELS and OPTIONS of /etc/sysconfig/network-scripts/ifcfg-* to establish the necessary virtual ccwgroup devices in sysfs in order to produce in-kernel network devices, e.g. eth0, hsi0, or ctc0. Grouping only works, if the corresponding network device driver has already been loaded.

Therefore, I suggest the following udev rule, which makes the loading of network device drivers for LCS and CTC automatically before(!) 55-ccw.rules kicks in.

/etc/udev/rules.d/54-cu3088-fix.rules

# LCS
ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/01", RUN+="/sbin/modprobe --quiet lcs"
ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/60", RUN+="/sbin/modprobe --quiet lcs"
# could be either CTC or LCS
ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/08", RUN+="/sbin/modprobe --quiet ctc"
ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/08", RUN+="/sbin/modprobe --quiet lcs"
# CTC
ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/1e", RUN+="/sbin/modprobe --quiet ctc"
ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/1f", RUN+="/sbin/modprobe --quiet ctc"

Verified to work with RHEL 5.4 alpha.

[This has already been discussed for upstream: https://www.redhat.com/archives/anaconda-devel-list/2009-March/msg00125.html]

(For LCS, this even makes the hack of the following bug obsolete: LTC Bug 28504 - RIT 116546- LCS Device will not grouped and interface bring up with ifup scripts. I.e. the following lines from /etc/modprobe.d/modprobe.conf.dist, which load the LCS driver module unconditionally together with the underlying cu3088 base driver even if the device is a CTC and not an LCS device, can be removed (I verified this by removing them):
# Module dependencies are actually reversed in the case of cu3088/lcs.
# Force load lcs on load of cu3088.
install cu3088 /sbin/modprobe --ignore-install cu3088; /sbin/modprobe lcs
).

------- Comment From sskumar1.com 2009-06-24 01:45 EDT-------
Verified in RHEL5.4 alpha IUCV is working fine. But i am still seeing same problem with ctc device onboot.

Bringing up loopback interface:  ??  OK
Bringing up interface ctc0:  SIOCSIFAD
ctc0: unknown interface: No such devic
SIOCSIFDSTADDR: No such device
ctc0: unknown interface: No such devic
SIOCSIFNETMASK: No such device
SIOCGIFADDR: No such device
SIOCSIFBROADCAST: No such device
ERROR: ctc0 did not come up!
SIOCADDRT: No such device

------- Comment From MAIER.com 2009-06-30 10:47 EDT-------
(In reply to comment #24)
> Therefore, I suggest the following udev rule, which makes the loading of
> network device drivers for LCS and CTC automatically before(!) 55-ccw.rules
> kicks in.
>
> /etc/udev/rules.d/54-cu3088-fix.rules

Sorry, I just learned that not only 3088/08 but also 3088/1f can be lcs or ctc, so the rules should look like the following:

# LCS
ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/01", RUN+="/sbin/modprobe --quiet lcs"
ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/60", RUN+="/sbin/modprobe --quiet lcs"
# could be either CTC or LCS
ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/08", RUN+="/sbin/modprobe --quiet ctc"
ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/08", RUN+="/sbin/modprobe --quiet lcs"
ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/1f", RUN+="/sbin/modprobe --quiet ctc"
ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/1f", RUN+="/sbin/modprobe --quiet lcs"
# CTC
ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/1e", RUN+="/sbin/modprobe --quiet ctc"

~~ Attention - RHEL 5.4 Beta Released! ~~

RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner!

If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity.

Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value.

Questions can be posted to this bug or your customer or partner representative.

------- Comment From MAIER.com 2009-07-03 15:11 EDT-------
My last analysis comment from RHEL 5.4 alpha is still valid for RHEL 5.4 beta1.
Netiucv works fine now, ctc won't come up on boot.

Red Hat, please add 54-cu3088-fix.rules to initscripts to fix this for ctc.

Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
This allows for the grouping of CTC and netiucv devices

------- Comment From mgrf.com 2009-07-14 09:32 EDT-------
(In reply to comment #29)
> My last analysis comment from RHEL 5.4 alpha is still valid for RHEL 5.4 beta1.
> Netiucv works fine now, ctc won't come up on boot.
> Red Hat, please add 54-cu3088-fix.rules to initscripts to fix this for ctc.

Hello Red Hat:
as per previous comment re-open this BZ
Still require fix for  " ctc "

The fix for this issue should be included in Snapshot 2.

------- Comment From MAIER.com 2009-07-18 13:05 EDT-------
Verified successfully with RHEL 5.4 snap2.
Thank you very much, Red Hat.
Closing.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1344.html