Bug 131741 - isdn network devices are started before isdn is available
Summary: isdn network devices are started before isdn is available
Status: VERIFIED FIXED
: 142523 (view as bug list)
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: Network (show other bugs)
Version: Final
Hardware: Other Other
: P5 - None : Normal
Target Milestone: ---
Assignee: Christian Zoz
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-01 12:32 UTC by Karsten Keil
Modified: 2006-02-14 09:03 UTC (History)
2 users (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Karsten Keil 2005-11-01 12:32:06 UTC 
If /etc/sysconfig/boot:RUN_PARALLEL=yes is set, the network is started before the ISDN drivers are available, which caused error messages and a not working ISDN connection.

The problem IMHO can be fixed by a
# Should-Start: isdn

line in /etc/init.d/network
Comment 1 Christian Zoz 2005-11-04 13:48:03 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?
Comment 2 Karsten Keil 2005-11-04 14:44:34 UTC 
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).
Comment 3 Christian Zoz 2005-11-04 14:52:53 UTC 
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?
Comment 4 Christian Zoz 2005-11-04 14:59:36 UTC 
Should this become a YOUpdate?
Comment 5 Karsten Keil 2005-11-04 15:09:36 UTC 
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.
Comment 6 Andreas Jaeger 2005-11-17 17:17:32 UTC 
Ok, Maintenance-Tracker-2965
Comment 7 Christian Zoz 2005-11-18 13:03:20 UTC 
This will go to YOUpdate today.
Comment 8 Karsten Keil 2006-01-02 18:25:18 UTC 
*** Bug 141077 has been marked as a duplicate of this bug. ***
Comment 9 Christian Zoz 2006-01-12 11:13:40 UTC 
*** Bug 142523 has been marked as a duplicate of this bug. ***
Comment 10 Anja Stock 2006-02-14 09:03:49 UTC 
released