madfuload doesn't work

Bug #330573 reported by agorka
62
This bug affects 8 people
Affects Status Importance Assigned to Milestone
madfuload (Debian)
Fix Released
Unknown
madfuload (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: madfuload

M-Audio Transit USB doesn't work out of the box in Jaunty.
Feb 17 15:42:17 wind madfuload: cannot open /proc/bus/usb/002/002: No such file or directory

I am able to make the Transit soundcard to work by writing
sudo madfuload -3 -f /usr/share/usb/maudio/006100.bin -D /dev/bus/usb/002/002
Can this change (from /proc/bus/usb to /dev/bus/usb) included to the package of madfuload? I'm experiencing this bug for a half of year and still nothing changed, it still tries to open /proc/bus/usb.

Revision history for this message
Chris (cpeter1) wrote :

madfuload did not work out of the box with me neither (Kubuntu Jaunty alpha5 amd64):

For my Transit USB I replaced the following line in /lib/udev/rules.d/42-madfuload.rules:
# Transit
ACTION=="add", SUBSYSTEM=="usb", DEVPATH=="/*.0", ENV{PRODUCT}=="763/2806/*", RUN+="/usr/local/sbin/madfuload -l -3 -f /usr/share/usb/maudio/ma006100.bin"
with
# Transit
ACTION=="add", SUBSYSTEM=="usb", ENV{PRODUCT}=="763/2806/*", RUN+="/usr/sbin/madfuload -l -3 -f /usr/share/usb/maudio/ma006100.bin -D $env{DEVNAME}"

Then, the Transit USB was detected correctly. This solution is thanks to Strider -> Bug #102631.

Revision history for this message
Neil Wilson (neil-aldur) wrote :

I can confirm this fault.

Changed in madfuload (Ubuntu):
assignee: nobody → Neil Wilson (neil-aldur)
status: New → Confirmed
Revision history for this message
Neil Wilson (neil-aldur) wrote :

The problem here is whether udev will select the usb_interface or usb_device when trying to load the firmware. The simple patch attached ensures that udev will only select the usb_device where $name is set correctly.

Revision history for this message
Neil Wilson (neil-aldur) wrote :
Download full text (6.4 KiB)

Unfortunately this isn't the end of the matter. Udev doesn't appear to wait for the device to be created before it forks the RUN command and so you get random 'no such file or directory' errors.

Does somebody who understands udev better than me know if there is a way to get udev to serialise properly? I'd rather not do it the hard way unless I have to.

Debug trace below:

May 16 19:53:37 neil-laptop kernel: [ 1938.016172] usb 2-1: new full speed USB device using uhci_hcd and address 9
May 16 19:53:37 neil-laptop udevd[859]: seq 2497 queued, 'add' 'usb'
May 16 19:53:37 neil-laptop udevd[859]: seq 2497 forked, pid [7630], 'add' 'usb', 0 seconds old
May 16 19:53:37 neil-laptop udevd-event[7630]: device 0x7f0e8f5e00a0 has devpath '/devices/pci0000:00/0000:00:1d.0/usb2/2-1'
May 16 19:53:37 neil-laptop udevd-event[7630]: device 0x7f0e8f5e0310 has devpath '/devices/pci0000:00/0000:00:1d.0/usb2'
May 16 19:53:37 neil-laptop udevd-event[7630]: device 0x7f0e8f5e0ae0 has devpath '/devices/pci0000:00/0000:00:1d.0'
May 16 19:53:37 neil-laptop udevd-event[7630]: device 0x7f0e8f5e0d90 has devpath '/devices/pci0000:00'
May 16 19:53:37 neil-laptop udevd-event[7630]: RUN '/usr/sbin/madfuload -l -3 -f /usr/share/usb/maudio/ma006100.bin -D $root/$name' /lib/udev/rules.d/42-madfuload.rules:13
May 16 19:53:37 neil-laptop udevd-event[7630]: LINK 'char/189:136' /lib/udev/rules.d/50-udev-default.rules:5
May 16 19:53:37 neil-laptop udevd-event[7630]: MODE 0664 /lib/udev/rules.d/50-udev-default.rules:53
May 16 19:53:37 neil-laptop udevd-event[7630]: NAME 'bus/usb/002/009' /lib/udev/rules.d/50-udev-default.rules:53
May 16 19:53:37 neil-laptop udevd-event[7630]: RUN 'socket:@/org/freedesktop/hal/udev_event' /lib/udev/rules.d/90-hal.rules:2
May 16 19:53:37 neil-laptop udevd-event[7630]: create db link (bus/usb/002/009 char/189:136)
May 16 19:53:37 neil-laptop udevd-event[7630]: creating device node '/dev/bus/usb/002/009', devnum=189:136, mode=0664, uid=0, gid=0
May 16 19:53:37 neil-laptop udevd-event[7630]: mknod(/dev/bus/usb/002/009, 020664, (189,136))
May 16 19:53:37 neil-laptop udevd-event[7630]: chmod(/dev/bus/usb/002/009, 020664)
May 16 19:53:37 neil-laptop udevd-event[7630]: chown(/dev/bus/usb/002/009, 0, 0)
May 16 19:53:37 neil-laptop udevd-event[7630]: '/dev/char/189:136' with target '/dev/bus/usb/002/009' has the highest priority 0, create it
May 16 19:53:37 neil-laptop udevd[859]: seq 2498 queued, 'add' 'usb'
May 16 19:53:37 neil-laptop udevd-event[7630]: creating symlink '/dev/char/189:136' to '../bus/usb/002/009'
May 16 19:53:37 neil-laptop udevd-event[7630]: '/usr/sbin/madfuload -l -3 -f /usr/share/usb/maudio/ma006100.bin -D /dev/bus/usb/002/009'
May 16 19:53:37 neil-laptop kernel: [ 1938.168717] usb 2-1: configuration #1 chosen from 1 choice
May 16 19:53:37 neil-laptop madfuload: cannot open /dev/bus/usb/002/009: No such file or directory
May 16 19:53:37 neil-laptop udevd[859]: seq 2499 queued, 'add' 'usb_endpoint'
May 16 19:53:37 neil-laptop udevd-event[7630]: '/usr/sbin/madfuload' returned with status 1
May 16 19:53:37 neil-laptop udevd-event[7630]: passed 324 bytes to monitor 0x7f0e8f5e00a0
May 16 19:53:37 neil-laptop udevd-event[7...

Read more...

Revision history for this message
Neil Wilson (neil-aldur) wrote :

Just to eliminate the madfuload program, I did a test with good old 'stat' and 'head'. You can 'stat' the device, but you can't 'head' it.

STAT trace

May 17 07:51:01 neil-laptop udevd-event[7886]: '/usr/bin/stat /dev/bus/usb/002/004'
May 17 07:51:01 neil-laptop kernel: [ 1290.888798] usb 2-1: configuration #1 chosen from 1 choice
May 17 07:51:01 neil-laptop udevd-event[7886]: '/usr/bin/stat' (stdout) ' File: `/dev/bus/usb/002/004''
May 17 07:51:01 neil-laptop udevd-event[7886]: '/usr/bin/stat' (stdout) ' Size: 0 ^IBlocks: 0 IO Block: 4096 character special file'
May 17 07:51:01 neil-laptop udevd-event[7886]: '/usr/bin/stat' (stdout) 'Device: fh/15d^IInode: 24726 Links: 1 Device type: bd,83'
May 17 07:51:01 neil-laptop udevd-event[7886]: '/usr/bin/stat' (stdout) 'Access: (0664/crw-rw-r--) Uid: ( 0/ root) Gid: ( 0/ root)'
May 17 07:51:01 neil-laptop udevd-event[7886]: '/usr/bin/stat' (stdout) 'Access: 2009-05-17 07:51:01.882187755 +0100'
May 17 07:51:01 neil-laptop udevd-event[7886]: '/usr/bin/stat' (stdout) 'Modify: 2009-05-17 07:51:01.882187755 +0100'
May 17 07:51:01 neil-laptop udevd-event[7886]: '/usr/bin/stat' (stdout) 'Change: 2009-05-17 07:51:01.882187755 +0100'
May 17 07:51:01 neil-laptop udevd-event[7886]: '/usr/bin/stat' returned with status 0
May 17 07:51:01 neil-laptop udevd-event[7886]: passed 324 bytes to monitor 0x7f197ea79540
May 17 07:51:01 neil-laptop udevd-event[7886]: passed -1 bytes to monitor 0x7f197ea4c670
May 17 07:51:01 neil-laptop udevd-event[7886]: seq 1576 exit with 0

HEAD trace

May 17 08:56:02 neil-laptop udevd-event[9925]: '/usr/bin/head /dev/bus/usb/002/006'
May 17 08:56:02 neil-laptop udevd-event[9925]: '/usr/bin/head' (stderr) '/usr/bin/head: cannot open `/dev/bus/usb/002/006' for reading: No such file or directory'
May 17 08:56:02 neil-laptop kernel: [ 5191.186309] usb 2-1: configuration #1 chosen from 1 choice
May 17 08:56:02 neil-laptop udevd-event[9925]: '/usr/bin/head' returned with status 1
May 17 08:56:02 neil-laptop udevd-event[9925]: passed 324 bytes to monitor 0x7f197ea5d460
May 17 08:56:02 neil-laptop udevd-event[9925]: passed -1 bytes to monitor 0x7f197ea4c670
May 17 08:56:02 neil-laptop udevd-event[9925]: seq 1588 exit with 0

Revision history for this message
oudalrich (uhkeller) wrote :

On my system, udev does not even try to run madfuload when I plug in my Transit, at least madfuload does not show up in udev's debug output to /var/log/syslog. I have tried various changes to the udev rules (from comments 1 and 3, among others), but no rule seems to match the device, though the device ID is correct. Here's the line I currently use (in /lib/udev/rules.d/42-madfuload.rules):

ACTION=="add", SUBSYSTEM=="usb", ENV{PRODUCT}=="763/2806/*", RUN+="/usr/sbin/madfuload -l -3 -f /usr/share/usb/maudio/ma006100.bin -D $env{DEVNAME}"

I have restarted udev, and sometimes rebooted, each time after changing the rules. Lsusb output:

uli@EMACS-Keller:~$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 003: ID 0763:2806 Midiman M-Audio Transit DFU
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Debug output from udev in attachment.

I'm on Jaunty 32-bit. Running madfuload manually works, even though it generates an error:
cannot reset device: (19) No such device

Revision history for this message
larson.eric.d@gmail.com (larsoner) wrote :

I can confirm that none of the above solutions work for me. Also, when I run madfuload on the correct device/usb port, it exits with a seg fault, but the sound card works anyway. I'm on Jaunty 64-bit.

Revision history for this message
Chris (cpeter1) wrote :

the seg fault on 64-bit can be eliminated by changing the header definitions in madfuload.c file. -> see bug #301771. Neil Wilson has provided a patch there.

Revision history for this message
Neil Wilson (neil-aldur) wrote : Re: [Bug 330573] Re: madfuload doesn't work on Jaunty

Try getting a bit more detail in the log by using

sudo udevadm control --log-priority=<value>

where <value> = err, info or debug

That should give you an idea as to why udev isn't using calling the rule.

2009/6/20 oudalrich <email address hidden>:
> On my system, udev does not even try to run madfuload when I plug in my
> Transit, at least madfuload does not show up in udev's debug output to
> /var/log/syslog. I have tried various changes to the udev rules (from
> comments 1 and 3, among others), but no rule seems to match the device,
> though the device ID is correct. Here's the line I currently use (in
> /lib/udev/rules.d/42-madfuload.rules):
>
> ACTION=="add", SUBSYSTEM=="usb", ENV{PRODUCT}=="763/2806/*",
> RUN+="/usr/sbin/madfuload -l -3 -f /usr/share/usb/maudio/ma006100.bin -D
> $env{DEVNAME}"
>
> I have restarted udev, and sometimes rebooted, each time after changing
> the rules. Lsusb output:
>
> uli@EMACS-Keller:~$ lsusb
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 002 Device 003: ID 0763:2806 Midiman M-Audio Transit DFU
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>
> Debug output from udev in attachment.
>
> I'm on Jaunty 32-bit. Running madfuload manually works, even though it generates an error:
> cannot reset device: (19) No such device
>
> ** Attachment added: "Udev debug output when plugging in my Transit"
>   http://launchpadlibrarian.net/28138111/syslog
>
> --
> madfuload doesn't work on Jaunty
> https://bugs.launchpad.net/bugs/330573
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Neil Wilson

Revision history for this message
oudalrich (uhkeller) wrote : Re: madfuload doesn't work on Jaunty

Thanks Neil for your reply, but I had already set the log priority to "debug" in udev.conf before I generated the log attached to #6.

I don't know anything about how udev works, but looking through the log, these lines look wrong to me:

Jun 20 11:46:25 EMACS-Keller udevd-event[4367]: '/sbin/modprobe' (stderr) 'WARNING: All config files need .conf: /etc/modprobe.d/thinkpad_acpi.modprobe, it will be ignored in a future release.'
Jun 20 11:46:25 EMACS-Keller udevd-event[4369]: no node name set, will use kernel name 'usbdev2.2_ep00'
Jun 20 11:46:25 EMACS-Keller udevd-event[4367]: '/sbin/modprobe' (stderr) 'FATAL: Module usb:v0763p2806d0100dcFEdsc01dp00icFEisc01ip00 not found.'
Jun 20 11:46:25 EMACS-Keller udevd-event[4367]: '/sbin/modprobe' returned with status 1

Revision history for this message
Neil Wilson (neil-aldur) wrote :

OK, I've done a bit more work on this today with various combinations of udev selectors and I think I might have cracked it.

Can you put

ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}="usb_device", ATTRS{idVendor}=="0763", ATTRS{idProduct}=="2806", RUN+="/usr/sbin/madfuload -l -3 -f /usr/share/usb/maudio/ma006100.bin -D $ENV{DEVNAME}"

in place of the original Transit line in /lib/udev/rules.d/42-madfuload.rules

I've tested this on a laptop and a netbook in both 32 and 64 bit and it seems to work around the race condition - allowing the firmware to load.

Let me know if that helps.

Revision history for this message
Neil Wilson (neil-aldur) wrote :

That cut at an awkward point and there is an = missing.

ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="0763",
ATTRS{idProduct}=="2806", RUN+="/usr/sbin/madfuload -l -3 -f /usr/share/usb/maudio/ma006100.bin -D $ENV{DEVNAME}"

full file attached

Revision history for this message
oudalrich (uhkeller) wrote :

#12 didn't change anything for me, but I seem to have a different problem anyway (madfuload rule not called, not race condition). Should I maybe open another bug report? For what it's worth, new syslog in the attachment.

Revision history for this message
Neil Wilson (neil-aldur) wrote :

Probably worth keeping it here. Try running a series of tests

udevadm test $(udevadm info --name="/bus/usb/002/006" --query=path)
udevadm info --name="/bus/usb/002/006" --query=all
udevadm info --name="/bus/usb/002/006" --attribute-walk

(Change the entry in the --name parameter to match the name allocated to the device in the syslog.)

All that should give us an idea why you're not running the firmware load.

Revision history for this message
oudalrich (uhkeller) wrote :

The very first line returned by the first test led to the solution: I had an old 42-madfuload.rules in /etc/udev/rules.d that overrode the new one in /lib/udev/rules.d. Deleted it, now it works! Sorry for wasting your time by being so stupid.

There is a slight problem remaining, however. The Transit works only once, if I want to use it again after unplugging it I have to reboot:

1. Boot system
2. Plug in Transit: works
3. Unplug Transit
4. Plug in Transit (no matter which USB port): does not work
5. Reboot system
6. Plug in Transit: works

Revision history for this message
sonium (sonium) wrote :

#12 worked perfectly for me on 9.04-i386, I propose this for upstream.

Revision history for this message
oudalrich (uhkeller) wrote :

Sonium, have you tried unplugging and re-plugging the device? And which M-Audio device do you have, a Transit?

Revision history for this message
Neil Wilson (neil-aldur) wrote : Re: [Bug 330573] Re: madfuload doesn't work on Jaunty

I'm not seeing the plug and replug problem with my Transit on any of
my machines. I do have to restart the output program (Banshee in my
case), but PulseAudio seems to sort out the change of USB device
number without too much problem.

What I did find was that one of my USB buses still has the timing
problem, so it looks like I am going to have to fix madfuload the hard
way :-(

2009/6/25 oudalrich <email address hidden>:
> Sonium, have you tried unplugging and re-plugging the device? And which
> M-Audio device do you have, a Transit?
>
> --
> madfuload doesn't work on Jaunty
> https://bugs.launchpad.net/bugs/330573
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Neil Wilson

Revision history for this message
oudalrich (uhkeller) wrote : Re: madfuload doesn't work on Jaunty

The plug and replug problem has gone away... I don't know why, but I hope it stays that way. Thanks for your work Neil!

Revision history for this message
larson.eric.d@gmail.com (larsoner) wrote :

Thanks so much! My transit now works perfectly, including plugging/unplugging. I had to make the changes noted in #12 and (as noted by oudalrich) delete the /etc/udev/rules.d/42-madfuload.rules file I had.

Revision history for this message
yvan vander sanden (yvan-youngmusic) wrote :

I have an maudio ozone (not the academic version) and it always used to work, in former ubuntu versions. Now i am running the 9.04-64bit edition. I got the segfault error at first. After that, I downloaded the source package, made changes like sugested in #12, and ran configure, make, make install. After that I changed the rules for the ozone to

ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="0763", ATTRS{idProduct}=="2808", RUN+="/usr/local/sbin/madfuload -l -3 -f /usr/share/usb/maudio/ma008100.bin -D $ENV{DEVNAME}"

Note the different location of madfuload, but this is where make install puts it. That should not matter i think. After restarting udev and switching on my ozone, i can see this in dmesg:

[ 4654.948012] usb 5-2: new full speed USB device using uhci_hcd and address 10
[ 4655.106378] usb 5-2: configuration #1 chosen from 1 choice

No mention of madfuload, not even an error. "asoundconf list" should show the ozone if it were load, but does not list it. Output from 'lsusb' is correct though:

yvan@sound:/home/yvan$ lsusb
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 002: ID 046d:c51a Logitech, Inc. MX Revolution/G7 Cordless Mouse
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 010: ID 0763:2808 Midiman
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

I also rand the tests as suggested by Neil (see attachment). Nothing gives me a hint there either, so I'm rather clueless. Is there anything else i could try?

Revision history for this message
yvan vander sanden (yvan-youngmusic) wrote :

ok, found that error. It was rather obvious: ma008100.bin was located in /usr/local/share, not in /usr/share. And /dev/.udev/db was not writable by udev.

Still got no sound, but i think the next problem has to do with snd-usb-audio and me having 2 soundcards:

[ 697.028013] usb 5-2: new full speed USB device using uhci_hcd and address 4
[ 697.259006] usb 5-2: configuration #1 chosen from 1 choice
[ 697.261991] cannot find the slot for index 0 (range 0-0), error: -16
[ 697.261996] cannot create card instance 0
[ 697.262002] snd-usb-audio: probe of 5-2:1.0 failed with error -5
[ 697.265366] cannot find the slot for index 0 (range 0-0), error: -16
[ 697.265369] cannot create card instance 0
[ 697.265374] snd-usb-audio: probe of 5-2:1.3 failed with error -5

So that is outside the scope of this thread.

Revision history for this message
Neil Wilson (neil-aldur) wrote :

An updated package for Karmic containing the fix is available on my PPA.

https://launchpad.net/~neil-aldur/+archive/ppa

The debdiff fix has been sent for sponsorship:

https://bugs.edge.launchpad.net/ubuntu/+source/madfuload/+bug/301771/comments/16

Changed in madfuload (Ubuntu):
assignee: Neil Wilson (neil-aldur) → nobody
Neil Wilson (neil-aldur)
summary: - madfuload doesn't work on Jaunty
+ madfuload doesn't work
Changed in madfuload (Debian):
status: Unknown → New
Revision history for this message
James Westby (james-w) wrote :

Taking for sponsorship from the merge request.

Thanks,

James

Changed in madfuload (Ubuntu):
assignee: nobody → James Westby (james-w)
Changed in madfuload (Debian):
status: New → Fix Released
Changed in madfuload (Debian):
status: Fix Released → New
Revision history for this message
Benjamin Drung (bdrung) wrote :

I am unsubscribing ubuntu-universe-sponsors, because James wanted to sponsor it. Please resubscribe ubuntu-universe-sponsors, when someone else should do it.

Changed in madfuload (Debian):
status: New → Fix Released
Revision history for this message
Neil Wilson (neil-aldur) wrote :

New version in Debian which fixes the problems - please sync for Lucid.

madfuload (1.2-4) unstable; urgency=low

  * Imported changes from Ubuntu 1.2-2ubuntu3~karmic~ppa2 (Closes: #547336,
    thanks to Neil Wilson):

    - 42-madfuload.rules.in: substitution variables need to be in lower case

 -- Free Ekanayaka <email address hidden> Fri, 26 Mar 2010 17:23:26 +0100

madfuload (1.2-3) unstable; urgency=low

  * Imported changes from Ubuntu 1.2-2ubuntu2 (Closes #547336, thanks
    to Scott James Remnan):

    - 42-madfuload.rules.in: Add -D $root/$name to madfuload calls so we use
      /dev/bus/usb paths.
    - Makefile.in, Makefile.am: Install udev rules into /lib/udev/rules.d
    - configure.ac, configure: Drop attempt to figure out the path, the conf
      file is always in /etc but the rules are in /lib
    - configure.ac, configure: Update to call udevadm info
    - debian/control: Depend on udev

 -- Free Ekanayaka <email address hidden> Thu, 12 Nov 2009 15:28:15 +0000

Revision history for this message
Neil Wilson (neil-aldur) wrote :
Revision history for this message
Benjamin Drung (bdrung) wrote :

madfuload 1.2-4 was synced to Ubuntu 10.04 (lucid).

Changed in madfuload (Ubuntu):
assignee: James Westby (james-w) → nobody
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.