I ran into a very frustrating problem yesterday, hopefully someone in wlug knows the answer.. Verne has 4 sound devices; onboard sound, two PCI cards, and a USB transmitter. When I first set up breezy I had them loading as /dev/dsp onboard /dev/dsp1 first PCI /dev/dsp2 second PCI When he first got the USB transmitter it kept coming up as /dev/dsp1 and I managed to fix that by listing snd-intel8x0 and snd-ens1371 in /etc/modules, forcing the module for the onboard sound and two PCI cards to load earlier. Yesterday I upgraded to dapper and now all the sound devices come up in completely unpredictable order, not even the same on two consecutive boots. Even though the correct modules are still listed in /etc/modules. Is there a proper way to force devices to get detected in the order I want?
Yesterday I upgraded to dapper and now all the sound devices come up in completely unpredictable order, not even the same on two consecutive boots. Even though the correct modules are still listed in /etc/modules.
Is there a proper way to force devices to get detected in the order I want?
You can use a udev rule to force device name allocation, although I can't even hazard a guess as to what that would look like in this case. It's been a while since I played with udev. I think matt or craig added a rule for eth* device allocation to a wiki page a while back though
On 7/31/06, Daniel Lawson <daniel(a)meta.net.nz> wrote:
Yesterday I upgraded to dapper and now all the sound devices come up in completely unpredictable order, not even the same on two consecutive boots. Even though the correct modules are still listed in /etc/modules.
Is there a proper way to force devices to get detected in the order I want?
You can use a udev rule to force device name allocation, although I can't even hazard a guess as to what that would look like in this case. It's been a while since I played with udev. I think matt or craig added a rule for eth* device allocation to a wiki page a while back though
You can find this at http://wlug.org.nz/UDev which has links to a number of websites. One little tip - what I would do is name the devices (using udev) something like /dev/soundev1, /dev/soundev2 or similar rather than variations on dsp as it seems like you can't lock down a pre-existing name. For example my ethernet cards are lan0, lan1 which are locked down and eth0/1 randomly change. -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand
You can find this at http://wlug.org.nz/UDev which has links to a number of websites.
Thanks, I seem to have it figured out now and added my experience to the wiki. Hopefully I can get Verne's system sorted out tomorrow.
One little tip - what I would do is name the devices (using udev) something like /dev/soundev1, /dev/soundev2 or similar rather than variations on dsp as it seems like you can't lock down a pre-existing name. You can, you just have to be sure you handle all possible devices uniquely so the kernel never gets a chance to put something else there first. Renaming the devices is probably safer but Verne's scrips all refer to /dev/dspX and he doesn't want to have to change them!
For example my ethernet cards are lan0, lan1 which are locked down and eth0/1 randomly change.
That's what most of the documentation suggests.. but I think swapping them would have worked in your case too.
On 7/31/06, zcat <zcat(a)wired.net.nz> wrote:
You can find this at http://wlug.org.nz/UDev which has links to a number of websites.
Thanks, I seem to have it figured out now and added my experience to the wiki. Hopefully I can get Verne's system sorted out tomorrow.
One little tip - what I would do is name the devices (using udev) something like /dev/soundev1, /dev/soundev2 or similar rather than variations on dsp as it seems like you can't lock down a pre-existing name. You can, you just have to be sure you handle all possible devices uniquely so the kernel never gets a chance to put something else there first. Renaming the devices is probably safer but Verne's scrips all refer to /dev/dspX and he doesn't want to have to change them!
For example my ethernet cards are lan0, lan1 which are locked down and eth0/1 randomly change.
That's what most of the documentation suggests.. but I think swapping them would have worked in your case too.
I suspect why yours worked is that you renamed from dsp* to dsp so if there was a conflict it went away by doing that. I tried doing similar but I was naming eth0 rather than eth. I should try experimenting some more... I do think udev could be improved though. How hard would it be for udev to do "I will give existing devices their name they have used previously and then set up names for new devices" Ian -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand
On Tuesday 01 August 2006 06:42, Ian McDonald wrote:
I do think udev could be improved though. How hard would it be for udev to do "I will give existing devices their name they have used previously and then set up names for new devices"
Ian
As I understand it, this is less than trivial. For example, say you have two usb sticks. if you swap them to different ports can you really expect udev to still be able to identify them uniqely? Many devices have no way of doing this that is consistent. If you attempt to create a method to implement this, it very quickly becomes a messy black art type situation, where guesswork is as useful as good programming. -- A friend in need is a pest indeed.
As I understand it, this is less than trivial. For example, say you have two usb sticks. if you swap them to different ports can you really expect udev to still be able to identify them uniqely? Many devices have no way of doing this that is consistent. If you attempt to create a method to implement this, it very quickly becomes a messy black art type situation, where guesswork is as useful as good programming.
Understand what you are saying there. The problem Bruce and I and others are having is that cards inside a PC that doesn't move keep on changing device names... Linux (udev really) needs to get it's s*** together here! It's no fun when your server stops working because two ethernet cards decided to swap device names. -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand
As I understand it, this is less than trivial. For example, say you have two usb sticks. if you swap them to different ports can you really expect udev to still be able to identify them uniqely? Many devices have no way of doing this that is consistent. If you attempt to create a method to implement this, it very quickly becomes a messy black art type situation, where guesswork is as useful as good programming.
In the case of USB sticks, it's trivial for a couple of reasons: First of all, all USB devices have a unique serial number. This means you can canonically identify a particular USB stick, regardless of filesystem, and create a udev rule to mount it or name it something. Secondly, the filesystem within the device will have a GUID, which can be used to identify that particular filesystem. If you format the filesystem the GUID will change, but assuming that doesn't happen, you can still write a udev rule to specify where to mount the device. Unfortunately you picked a bad example :)
Daniel Lawson wrote:
As I understand it, this is less than trivial. For example, say you have two usb sticks. if you swap them to different ports can you really expect udev to still be able to identify them uniqely? Many devices have no way of doing this that is consistent. If you attempt to create a method to implement this, it very quickly becomes a messy black art type situation, where guesswork is as useful as good programming.
In the case of USB sticks, it's trivial for a couple of reasons:
First of all, all USB devices have a unique serial number. This means you can canonically identify a particular USB stick, regardless of filesystem, and create a udev rule to mount it or name it something.
Secondly, the filesystem within the device will have a GUID, which can be used to identify that particular filesystem. If you format the filesystem the GUID will change, but assuming that doesn't happen, you can still write a udev rule to specify where to mount the device.
Unfortunately you picked a bad example :)
I just finished setting up all Verne's sound devices, so I have a little more perspective to add. I don't think ubuntu should have started using udev at all in dapper until they had a little more 'management' behind it. Here's what I envision; during the install ubuntu should identify each PCI device and write udev rules similar to what I've just had to write to keep them in fixed order. This quite easily solves the problem with soundcards and network cards. Same for USB filesystems, based on filesystem ID as Daniel suggests. New devices get subsequent numbers and when a device goes away, perhaps the user should have the option to to free up that device entry or keep it.. Other USB devices might be a bit harder, but if it's the same thing plugged into the same socket most users are going to expect it to appear as the same device on two consecutive reboots! I can see a LOT of frustration arising from this change. A GUI admin tool that lets you easily swap things around would also be nice.
Ian McDonald wrote:
Understand what you are saying there. The problem Bruce and I and others are having is that cards inside a PC that doesn't move keep on changing device names...
Fair enough. Can you think of a method to handle asyncronous device detection in a syncronous fashion?
Easy - look in a database to see if it has previously been assigned.
Ok so I get this better now. Essentially every system as it is installed should generate a custom database of devices and names, so that when new ones are installed they are given new unique dev names. I guess unidentifiable devices could be handled as a special case and default to the old behavior with a reserved subset of dev names. Taking this furthur, it would be unlikely for a system to generate an overly large udev ruleset, even over time, unless it was a bit unusual? As udev is pretty much userspace, this should be easier to implement than supplying general case solutions. One problem I can see is that applications would have to use these unique entries, potentially different on each system? -- BOFH excuse #324: Your packets were eaten by the terminator
One problem I can see is that applications would have to use these unique entries, potentially different on each system?
How is this different from the current situation, other than the onboard sound will stay at /dev/dsp and the USB 'skype-phone' will stay at /dev/dsp1 instead of randomly swapping as they do now?
On Tuesday 01 August 2006 17:21, zcat wrote:
One problem I can see is that applications would have to use these unique entries, potentially different on each system?
How is this different from the current situation, other than the onboard sound will stay at /dev/dsp and the USB 'skype-phone' will stay at /dev/dsp1 instead of randomly swapping as they do now?
Not very I guess. Most importantly, what that means is there is still an element of customization required by the user, rather than just working out of the box. OTH application wizards could quickly set this up much more easily than manually writing udev rules. Point taken... -- Please dont CC me from mailing lists.
Glenn Enright wrote:
On Tuesday 01 August 2006 17:21, zcat wrote:
One problem I can see is that applications would have to use these unique entries, potentially different on each system?
How is this different from the current situation, other than the onboard sound will stay at /dev/dsp and the USB 'skype-phone' will stay at /dev/dsp1 instead of randomly swapping as they do now?
Not very I guess. Most importantly, what that means is there is still an element of customization required by the user, rather than just working out of the box. OTH application wizards could quickly set this up much more easily than manually writing udev rules. Point taken...
Less customisation. Right now, your fresh install is broken out of the box. You set up ubuntu and sound works. Plug in a usb phone and configure skype to use /dev/dsp1. Cool. The next time you boot the computer, all your system sounds are coming through the phone and skype is using the system speakers. Most users want devices to NOT MOVE ABOUT. What I'm suggesting is that once a device has been allocated, it stays there, with _perhaps_ an easily discovered option for freeing up or moving devices, although most users won't use it. So now; you set up ubuntu and sound works. (and transparently, the installer has set up a rule so it will always be /dev/dsp.) You plug in the phone and set skype to use /dev/dsp1. (and the installer has made a rule so that phone will always be /dev/dsp1) your webcam microphone will come up as /dev/dsp2 .. and it will stay there even if you accidentally boot the machine with the usb phone unplugged... Normal users with only one or two (or even ten) devices, who want things to 'just work' get that, and things will stay working in the same place every time they boot the machine. Users that need to move devices around or play with new hardware every week can still do that too, with minimal extra effort. Users that enjoy their devices jumping about randomly are going to have to get used to them staying put, or something..
Less customisation. Right now, your fresh install is broken out of the box. You set up ubuntu and sound works. Plug in a usb phone and configure skype to use /dev/dsp1. Cool. The next time you boot the computer, all your system sounds are coming through the phone and skype is using the system speakers. Most users want devices to NOT MOVE ABOUT.
Does this actually happen? What I've seen is Linux assigns things based on something like PCI order, which is likely not to change unless you move cards around. With USB things, its possible that plugging them in in a different order could swap the /dev/dsp numbers, but with a single PCI sound card and a USB one, I wouldn't expect it to swap. I only get network interfaces changing on me between kernel/udev updates, if at all - never on just a reboot. Craig
I only get network interfaces changing on me between kernel/udev updates, if at all - never on just a reboot.
It is entirely possible to get them changing on a reboot without a kernel/udev update. Until I figured it out I was rebooting about 3 or 4 times until the devices came up in the order I wanted.... -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand
Ian McDonald wrote:
I only get network interfaces changing on me between kernel/udev updates, if at all - never on just a reboot.
It is entirely possible to get them changing on a reboot without a kernel/udev update. Until I figured it out I was rebooting about 3 or 4 times until the devices came up in the order I wanted....
I suggest you have broken hardware if your ethernet cards are changing order. I've never seen this happen, other than on one machine which had a decidedly flaky motherboard. Can you provide some more information, such as motherboard, card types, etc?
On 8/2/06, Daniel Lawson <daniel(a)meta.net.nz> wrote:
Ian McDonald wrote:
I only get network interfaces changing on me between kernel/udev updates, if at all - never on just a reboot.
It is entirely possible to get them changing on a reboot without a kernel/udev update. Until I figured it out I was rebooting about 3 or 4 times until the devices came up in the order I wanted....
I suggest you have broken hardware if your ethernet cards are changing order. I've never seen this happen, other than on one machine which had a decidedly flaky motherboard.
Can you provide some more information, such as motherboard, card types, etc?
It's not broken motherboard - it's borked udev design as I understand what the kernel and udev is doing. udev is nondeterministic and runs parts in parallel so you get race like timing issues. This is why the thread started and why udev needs fixing to store device names between reboots - and as Bruce says so nicely - those who like their devices changing will have to do something else. -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand
udev is nondeterministic and runs parts in parallel so you get race like timing issues. This is why the thread started and why udev needs fixing to store device names between reboots - and as Bruce says so nicely - those who like their devices changing will have to do something else.
Do you think it need to store device names, or just decide on a deterministic sequence to start things?
On 8/2/06, Daniel Lawson <daniel(a)meta.net.nz> wrote:
udev is nondeterministic and runs parts in parallel so you get race like timing issues. This is why the thread started and why udev needs fixing to store device names between reboots - and as Bruce says so nicely - those who like their devices changing will have to do something else.
Do you think it need to store device names, or just decide on a deterministic sequence to start things?
I think it needs to store device names because deterministic breaks potentially if you add a new device which is detected earlier in the boot sequence and renames old device. My opinion is that it should probe for existing devices and if they exist give them the same name as previous boot and then look for new devices. I'm sure that this will shake down over time as more users use newer kernels and udev there will be more complaints... -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand
I think it needs to store device names because deterministic breaks potentially if you add a new device which is detected earlier in the boot sequence and renames old device.
My opinion is that it should probe for existing devices and if they exist give them the same name as previous boot and then look for new devices.
That seems like a reasonable strategy, although it's not quite perfect for devices that are likely to get added/removed a lot. But they are likely to be USB devices and users can add static mappings themselves in most cases. Which kernel/udev versions were you using that exhibited this behaviour? Also, what sort of machines are you using them in? Granted, nondeterministic behaviour can't be guaranteed to work everwhere, but I have a large number of systems with multiple network cards and so on that doesn't show this behaviour at all. Most of them are running fairly recent kernels (2.6.15+?) and udev, and I've not come across this. Basically, if there's a particular kernel/udev version combination I should avoid putting on my multi-nic firewalls, that would be good to know.
I've sort of sat back on this, as Its not something affecting me a lot, Bit it looks like an issue I have seen a variant of, that might be relevant here Back in the CL 2.5 days we had a detection script that caused similar problems with ALSA. we managed to stop it by turning off the "Plug and Play OS" mode of the BIOS. When the Motherboard assigns fixed devices, the OS seemed to loose the detection issues. In the plug and play mode the race condition seemed to be able to occur. (and the cards were a BT787 video capture card and a sound card), with both swapping the role of sound card. Has anyone changed the bios setting and seen if this make a difference ? If so ignore me, otherwise it might be a workaround. On 2/08/2006, at 12:29 PM, Daniel Lawson wrote:
I think it needs to store device names because deterministic breaks potentially if you add a new device which is detected earlier in the boot sequence and renames old device.
My opinion is that it should probe for existing devices and if they exist give them the same name as previous boot and then look for new devices.
Which kernel/udev versions were you using that exhibited this behaviour? Also, what sort of machines are you using them in? Granted, nondeterministic behaviour can't be guaranteed to work everwhere, but I have a large number of systems with multiple network cards and so on that doesn't show this behaviour at all. Most of them are running fairly recent kernels (2.6.15+?) and udev, and I've not come across this.
It was a home built machine, kernel was 2.6.15 or 16 and udev was around version 40 from memory. I have the rule fixed in so don't know if still an issue or not. -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand
It was a home built machine, kernel was 2.6.15 or 16 and udev was around version 40 from memory. I have the rule fixed in so don't know if still an issue or not.
Hmm. Seems that I'm running udev version 79 under dapper, and udev version 93 on a sarge machine with backports. That's quite a bit different. Maybe this bug is already fixed?
On 8/2/06, Daniel Lawson <daniel(a)meta.net.nz> wrote:
It was a home built machine, kernel was 2.6.15 or 16 and udev was around version 40 from memory. I have the rule fixed in so don't know if still an issue or not.
Hmm. Seems that I'm running udev version 79 under dapper, and udev version 93 on a sarge machine with backports. That's quite a bit different. Maybe this bug is already fixed?
I saw discussion on netdev today that this has been fixed for networking a while. I don't know about other device types. Ian -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand
Daniel Lawson wrote:
I saw discussion on netdev today that this has been fixed for networking a while. I don't know about other device types.
That's great to know. Nondeterministic interface naming would be a big problem with linux routers :(
It's been dealt with alright. I have two very similar Xircom network cards for my laptop. The first is always detected as eth0 and the other as eth1 even though the two have never been plugged in at the same time. I also found out (although I'm not 100% sure how this works when you have several devices using the same module, I'm guessing index=2,3 might work) that you can set the index numbers in /etc/modprobe.conf, which is a much cleaner solution than messing with udev rules. options snd-ens1370 index=0 options snd-sonicvibes index=1 I'll wiki this when I've had more time and hardware to test it with.
I also found out (although I'm not 100% sure how this works when you have several devices using the same module, I'm guessing index=2,3 might work) that you can set the index numbers in /etc/modprobe.conf, which is a much cleaner solution than messing with udev rules.
options snd-ens1370 index=0 options snd-sonicvibes index=1
I'll wiki this when I've had more time and hardware to test it with.
Have a look at http://www.wlug.org.nz/AlsaNotes under Not all sound devices work. Basically the index is a bitmask of acceptable positions. If you specify 0, 1, 2, 4, 8 etc it will lock it down. If you specify 15 it means it can pick. Often the problem is if you have a sound card already taking the first slot and then you say index=0 it can't do anything and gives up... -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand
Does this actually happen? What I've seen is Linux assigns things based on something like PCI order, which is likely not to change unless you move cards around
I managed to find a number of threads discussing system sound and USB handset being detected in the wrong order. It might not be particularly common but it certainly is happening. With Verne's machine onboard sound, USB transmitter and PCI cards managed to appear in three different arrangements on three consecutive reboots. Like Ian says, it's a race condition.
On Wed, Aug 02, 2006 at 09:35:49AM +1200, Craig Box wrote:
Less customisation. Right now, your fresh install is broken out of the box. You set up ubuntu and sound works. Plug in a usb phone and configure skype to use /dev/dsp1. Cool. The next time you boot the computer, all your system sounds are coming through the phone and skype is using the system speakers. Most users want devices to NOT MOVE ABOUT.
Does this actually happen? What I've seen is Linux assigns things based on something like PCI order, which is likely not to change unless you move cards around.
With USB things, its possible that plugging them in in a different order could swap the /dev/dsp numbers, but with a single PCI sound card and a USB one, I wouldn't expect it to swap.
I've encountered this with video devices - from what I could tell, usb hardware was detected before pci hardware, so if the usb webcam was plugged in on boot, then it got video1 and the pci card got video2. I don't recall the order ever being non-deterministic though :) John
Ok so I get this better now. Essentially every system as it is installed should generate a custom database of devices and names, so that when new ones are installed they are given new unique dev names. I guess unidentifiable devices could be handled as a special case and default to the old behavior with a reserved subset of dev names.
Taking this furthur, it would be unlikely for a system to generate an overly large udev ruleset, even over time, unless it was a bit unusual? As udev is pretty much userspace, this should be easier to implement than supplying general case solutions.
I'm a bit worried that I might have a network card die, replace it, and then find that it isn't eth0 any more - for reasons I can't possibly fathom at the time, it's eth1. udev and static assignments is pretty advanced stuff and should be abstracted away from people in general. Craig
You can, you just have to be sure you handle all possible devices uniquely so the kernel never gets a chance to put something else there first. Renaming the devices is probably safer but Verne's scrips all refer to /dev/dspX and he doesn't want to have to change them!
For example my ethernet cards are lan0, lan1 which are locked down and eth0/1 randomly change.
That's what most of the documentation suggests.. but I think swapping them would have worked in your case too.
Ubuntu seems to cope with swapping eth0/eth1 etc. I'm not sure how, but according to a Debian rant (along the lines of "why was this crappy Ubuntu patch accepted into Debian"), it does a swap on the names - ie eth0 -> eth0-temp, eth1 -> eth0, eth0-temp -> eth1. Just like you learned in programming-school. This should mean you can define the order to whatever you want, and it will cope. I have heard about massive failures though, so be careful. Craig
Ubuntu seems to cope with swapping eth0/eth1 etc. I'm not sure how, but according to a Debian rant (along the lines of "why was this crappy Ubuntu patch accepted into Debian"), it does a swap on the names - ie eth0 -> eth0-temp, eth1 -> eth0, eth0-temp -> eth1. Just like you learned in programming-school.
This should mean you can define the order to whatever you want, and it will cope. I have heard about massive failures though, so be careful.
I was wondering if that would work as that was the only way I could think of but hadn't tested that idea yet. I should look into that because some parts of the system e.g. NetworkManager persist in using eth* and won't use my lan* devices.... -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand
participants (7)
-
Craig Box -
Daniel Lawson -
Gavin Denby -
Glenn Enright -
Ian McDonald -
John R. McPherson -
zcat