Bug 154799
| Summary: | rc.sysinit initializing hardware processing prevents ISDN from proper starting | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Peter Bieringer <pb> |
| Component: | hwdata | Assignee: | Bill Nottingham <notting> |
| Status: | CLOSED ERRATA | QA Contact: | Brock Organ <borgan> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.0 | CC: | harald, rvokal, than, ubeck |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | RHBA-2005-648 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-10-05 16:32:08 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 156322 | ||
|
Description
Peter Bieringer
2005-04-14 09:53: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. 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. 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? 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?
system-config-network writes /etc/sysconfig/isdncard. 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". 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. 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... Same happen on FC4 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. 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? 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 Fixed in 0.146.10.EL-1 and later. 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. 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 |