As far as I can tell, there are at least three different problems mashed together in this thread.
The first one is that the upstream M-audio firmware loader tries use the old /proc/bus/usb interface. There is already a patch at http://sourceforge.net/tracker/index.php?func=detail&aid=1622573&group_id=87777&atid=584353. It can also be fixed by linking /dev/bus/usb to /proc/bus/usb but I do not think this is a good idea. The solution I'd prefer would be integrating a patched version of madfuload to alsa-firmware-loaders or making a separate package for the patched drivers. The second problem is that there is some timing issue that prevents the firmware loader from opening the device file at the moment udev starts the loader. After a short wait the device is openable. I have not yet had time to check if this is still an issue in Hardy. The people complaining at http://ubuntuforums.org/showthread.php?t=260379 may have the same problem. I checked the source of udev. From there it seems quite clear that the device files are created well before the program specified by the RUN part of udev rule is started. Could it be that creating the device is not atomic and therefore control returns to udev before the device is fully usable? The third one may have something to do with different device IDs but I am not really sure what Nobre is saying. It might have to do something with the fact that M-Audio devices change their device ID after the firmware has been loaded. For example, my Transit is shown as 0763:2806 when it is first plugged in. This device can not do anything but receive firmware. After the firmware has been loaded, the Transit disconnects and reconnects as 0763:2006 which is an USB audio device and does not need any special drivers any more. So, you need to load firmware only for 2806 (or 2808 for the Ozone). More about the timing issue: Attached is a small program which attempts to open the newly added device, waits for a short time and attempts the opening again. I call it from following udev rule: ACTION=="add", SUBSYSTEM=="usb", ENV{PRODUCT}=="763/2806/*", ENV{DEVTYPE}=="usb_device", RUN+="/home/ojs/bug/udev/justopen $env{DEVNAME}" On my system, the Transit gives following output: Apr 25 23:12:17 eris justopen.c: Opening /dev/4-1 failed: No such file or directory Apr 25 23:12:17 eris justopen.c: Statting /dev/4-1 OK Apr 25 23:12:17 eris justopen.c: Delay! Apr 25 23:12:17 eris justopen.c: Opening /dev/4-1 OK Apr 25 23:12:17 eris justopen.c: Statting /dev/4-1 OK I tried the same program with a Bluetooth adapter. The output is interesting: Apr 25 23:17:06 eris justopen.c: Opening /dev/3-2 failed: No such file or directory Apr 25 23:17:06 eris justopen.c: Statting /dev/3-2 OK Apr 25 23:17:06 eris hcid[5477]: HCI dev 0 registered Apr 25 23:17:06 eris justopen.c: Delay! Apr 25 23:17:06 eris justopen.c: Opening /dev/3-2 OK Apr 25 23:17:06 eris justopen.c: Statting /dev/3-2 OK Looks like the HCI device is registered just after the device has become usable. ** Attachment added: "justopen.c" http://launchpadlibrarian.net/13908235/justopen.c -- UDEV problem with madfu-firmware for M-Audio Transit USB audio interface under Feisty https://bugs.launchpad.net/bugs/102631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
