Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 154799 - rc.sysinit initializing hardware processing prevents ISDN from proper starting
Summary: rc.sysinit initializing hardware processing prevents ISDN from proper starting
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: hwdata
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks: 156322
TreeView+ depends on / blocked
 
Reported: 2005-04-14 09:53 UTC by Peter Bieringer
Modified: 2014-03-17 02:53 UTC (History)
4 users (show)

Fixed In Version: RHBA-2005-648
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-10-05 16:32:08 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:648 qe-ready SHIPPED_LIVE hwdata bug fix update 2005-10-05 04:00:00 UTC

Description Peter Bieringer 2005-04-14 09:53:13 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.7.6) Gecko/20050321 Firefox/1.0.2

Description of problem:
rc.sysinit initialize hardware using the magic "kmodule" (which, btw. has no manpage at all).

Looking for the real reason why a later "service isdn start" always fail after fresh reboot I nailed this down no.

It's a little bit related to the problem with kudzu that ISDN cards are detected as network cards, see here for more:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154793

So here a current kmodule output:

# kmodule
OTHER i8xx_tco
OTHER hw_random
NETWORK hisax
NETWORK e100
USB uhci-hcd

That's bad, because rc.sysinit doesn't take care that hisax module is from ISDN4Linux and it make no sense to load it at this state of booting.
Big reason: hisax module parameters are not usually specified in /etc/modprobe.conf, they are located in /etc/sysconfig/isdncard...which rc.sysinit doesn't now.
In addition /etc/rc.d/init.d/isdn does the proper module load later.


Version-Release number of selected component (if applicable):
initscripts-7.93.13.EL-1

How reproducible:
Always

Steps to Reproduce:
1. Install RHEL4 (same reason happen on FC2 and FC3)
2. Install ISDN card
3. Configure /etc/sysconfig/isdncard proper
4. Reboot
  

Actual Results:  Initializing of ISDN fails

Expected Results:  Initializing of ISDN works

Additional info:

I have created two workarounds (only one is required):

1) the "no change in rc.sysinit" workaround:

Always remove ISDN modules before loading them (isdn4k-utils packages needs to be changed)

--- /etc/rc.d/init.d/isdn.orig  2005-04-14 10:59:25.000000000 +0200
+++ /etc/rc.d/init.d/isdn       2005-04-14 11:38:52.927602904 +0200
@@ -215,6 +215,7 @@
     [ ! -f /var/lock/subsys/isdn ] || exit 0

     # load modules
+    remove_modules
     load_modules

     # load firmware and setup isdn device driver


2) the "rc.sysinit" workaround:

Here, if description of a NETWORK module starts with ISDN4Linux, it will be skipped.

--- /etc/rc.d/rc.sysinit.orig   2005-04-14 11:26:37.000000000 +0200
+++ /etc/rc.d/rc.sysinit        2005-04-14 11:35:14.000000000 +0200
@@ -155,7 +155,9 @@
                   echo "ide=\"$ide"\";;
                "SCSI") scsi="$scsi $mod"
                   echo "scsi=\"$scsi"\";;
-               "NETWORK") network="$network $mod"
+               "NETWORK")
+                  if modinfo -d $mod | grep -q "^ISDN4Linux:"; then continue; fi
+                  network="$network $mod"
                   echo "network=\"$network"\";;
                "AUDIO") audio="$audio $mod"
                   echo "audio=\"$audio"\";;


Here dmesg output 

2a) before rc.sysinit fix:

SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts
inserting floppy driver for 2.6.9-6.37.EL
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
e100: Intel(R) PRO/100 Network Driver, 3.3.6-k2-NAPI
e100: Copyright(c) 1999-2004 Intel Corporation
ACPI: PCI interrupt 0000:01:01.0[A] -> GSI 10 (level, low) -> IRQ 10
divert: allocating divert_blk for eth0
e100: eth0: e100_probe: addr 0xff8fe000, irq 10, MAC addr 00:03:47:77:3E:C8
CSLIP: code copyright 1989 Regents of the University of California
ISDN subsystem Rev: 1.1.2.3/1.1.2.3/1.1.2.2/1.1.2.3/1.1.2.2/1.1.2.2 loaded
HiSax: Linux Driver for passive ISDN cards
HiSax: Version 3.5 (module)
HiSax: Layer1 Revision 2.46.2.5
HiSax: Layer2 Revision 2.30.2.4
HiSax: TeiMgr Revision 2.20.2.3
HiSax: Layer3 Revision 2.22.2.3
HiSax: LinkLayer Revision 2.59.2.4
hw_random hardware driver 1.0.0 loaded
USB Universal Host Controller Interface driver v2.2
ACPI: PCI interrupt 0000:00:1f.2[D] -> GSI 10 (level, low) -> IRQ 10
uhci_hcd 0000:00:1f.2: UHCI Host Controller
PCI: Setting latency timer of device 0000:00:1f.2 to 64
uhci_hcd 0000:00:1f.2: irq 10, io base 0000ef80
SELinux: initialized (dev usbdevfs, type usbdevfs), uses genfs_contexts
uhci_hcd 0000:00:1f.2: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.

2b) after rc.sysinit fix:

inserting floppy driver for 2.6.9-6.37.EL
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
e100: Intel(R) PRO/100 Network Driver, 3.3.6-k2-NAPI
e100: Copyright(c) 1999-2004 Intel Corporation
ACPI: PCI interrupt 0000:01:01.0[A] -> GSI 10 (level, low) -> IRQ 10
divert: allocating divert_blk for eth0
e100: eth0: e100_probe: addr 0xff8fe000, irq 10, MAC addr 00:03:47:77:3E:C8
hw_random hardware driver 1.0.0 loaded
USB Universal Host Controller Interface driver v2.2
ACPI: PCI interrupt 0000:00:1f.2[D] -> GSI 10 (level, low) -> IRQ 10
uhci_hcd 0000:00:1f.2: UHCI Host Controller
PCI: Setting latency timer of device 0000:00:1f.2 to 64
uhci_hcd 0000:00:1f.2: irq 10, io base 0000ef80
SELinux: initialized (dev usbdevfs, type usbdevfs), uses genfs_contexts
uhci_hcd 0000:00:1f.2: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.

-> as you seem hisax module is no longer loaded during initialization


3) Wanted: the real magic fix which prevents kmodule and also kudzu from the impression, that ISDN cards are simple network cards.

Comment 1 Bill Nottingham 2005-04-14 16:28:13 UTC
Well, it would still get loaded later, as it would then fall in the 'other' section.

Realistically, the ISDN module parameters need to be in modprobe.conf.

Comment 2 Peter Bieringer 2005-04-14 21:46:57 UTC
line 1 of #1:

No, because if you use the rc.sysinit patch, "continue" causes to skip this
completly, the case section "*" would be never reached. (you will see this on
the shown results, also).

line 2 of #1:

This would break current isdn4k-utils configuration.

Comment 3 Bill Nottingham 2005-04-15 02:59:56 UTC
The comment was in reference to your #3 solution.

What parameters are needed that they can't be specified in modprobe.conf, or is
it just that they *aren't* specified there ATM?


Comment 4 Peter Bieringer 2005-04-15 06:00:25 UTC
Ah ok.

isdn4k-utils currently uses following:

# cat /etc/sysconfig/isdncard
MODULE="hisax"
RESOURCES="type=18 protocol=2"

/etc/rc.d/init.d/isdn:

function load_modules()
{
   ...
    modprobe $MODULE $RESOURCES > /dev/null 2>&1
    isdnctrl list all >/dev/null 2>&1
    if [ $? = 0 ] ; then
        action $"Loading ISDN modules" /bin/true
        touch /var/lock/subsys/isdn
    else
        action $"Loading ISDN modules" /bin/false
        modprobe -r $MODULE > /dev/null 2>&1
    fi
}

BTW: The "isdnctrl list all >/dev/null 2>&1" is the "showstopper", because if
hisax module is loaded without specifying the card (type=), it still loads, but
generic, means "isdnctrl list" cannot list any device and fails.


I do not know who introduces /etc/sysconfig/isdncard, but it's there now and
probably used by some setup scripts?

Comment 5 Bill Nottingham 2005-04-15 15:51:54 UTC
system-config-network writes /etc/sysconfig/isdncard.



Comment 6 Peter Bieringer 2005-04-15 16:18:09 UTC
Ok, so the cleanest way is patching (extending) rc.sysinit. This would prevent
from loading any ISDN module before /etc/rc.d/init.d/isdn calls "load_modules".

Comment 7 Bill Nottingham 2005-04-15 16:22:02 UTC
I don't like that solution, because there's no reason that one minor subsystem
should have a completely different device initialization routine than every
other module.

Comment 8 Peter Bieringer 2005-04-15 18:00:30 UTC
If you don't like it, than someone has to change isdn initscript and
system-config-network...sure more time needed for change, testing and QA.
Especially by parsing /etc/modprobe.conf for current config, and on change
removing old line, putting new line into...

Comment 9 Peter Bieringer 2005-06-14 20:20:34 UTC
Same happen on FC4

Comment 10 Ngo Than 2005-06-20 21:17:50 UTC
Harald, i think for fc5 you should get rid of /etc/sysconfig/isdncard
and add the isdn configuration into /etc/modprobe.conf.

for RHEL4, we should probably add the workaround from Peter.

Comment 11 Bill Nottingham 2005-06-20 22:04:54 UTC
For RHEL 4, I think the better solution is detailed in 159068 - add the modules
to the hotplug blacklist.

What modules besides hisax require this?

Comment 13 Ngo Than 2005-06-21 13:24:23 UTC
i agree with notting, we should add isdn module in the hotplug blacklist. It's a
good solution for RHEL4.

There're only 2 modules:
  hisax
  hisax_fcpcipnp

Comment 17 Bill Nottingham 2005-07-21 20:12:38 UTC
Fixed in 0.146.10.EL-1 and later.

Comment 20 Uwe Beck 2005-10-04 20:54:13 UTC
If hisax and hisax_fcpcipnp are in hotplug blacklist then this modules do not
load at boot and you can init capi without modprobe -r hisax.
This fix should be come with RHEL4 U2.


Comment 21 Red Hat Bugzilla 2005-10-05 16:32:08 UTC
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 the 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-2005-648.html



Note You need to log in before you can comment on or make changes to this bug.