|
Bugzilla – Full Text Bug Listing |
| Summary: | isdn network devices are started before isdn is available | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Karsten Keil <karsten.keil> |
| Component: | Network | Assignee: | Christian Zoz <zoz> |
| Status: | VERIFIED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | werner, wolfgang |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Karsten Keil
2005-11-01 12:32:06 UTC
On my system isdn is S01 and network S05 even without network should-start isdn. So are you sure that this is really the problem? So far i see no problem in adding should-start isdn to network. Why do we have service isdn at all? Can't we do that via udev? Don't you get race conditions from using assynchronous (udev triggered) and synchronous (rcisdn) processes? Yes this is true also on the customers system it is S01 and S05, but if you enable RUN_PARALLEL=yes only /etc/init.d/.depend.start counts. And yes # Should-Start: isdn really solve it (verified by customer) In 10.0 udev triggerd isdn setup is only used for real hotplug devices (USB/PCMCIA) , which need hotplug or manual as STARTMODE for the configured interface. The big problem with udev is the support of multiple controllers, this cannot be solved with most of current I4L drivers, which need the parameters for all controllers on insmod time, so the easiest way to solve it (until drivers are able to add controllers separate) is to diasable autoloading and load the modules via rcisdn. Here are some more problems with udev (similar to persistant naming with ethernet, but you do not have an ethernet hw address). OK, i add isdn. As far as possible we try to initialize all devices via hotplug/detection events. Hotplug is sometimes misleading here; detection events is probably better. Did you try to use the manual driver binding via sysfs? Should this become a YOUpdate? Are here other things pending for sysconfig ?
I think we can wait, but should finally provide an update.
> Did you try to use the manual driver binding via sysfs?
No, do you have a description for it ? I searched kernel/Documentation for it, but didn't find something useful.
Ok, Maintenance-Tracker-2965 This will go to YOUpdate today. *** Bug 141077 has been marked as a duplicate of this bug. *** *** Bug 142523 has been marked as a duplicate of this bug. *** released |