Firewire M-Audio 410 driver won't load firmware


#1

I’m using Netrunner Rolling, which actually runs Manjaro as a base if I understand correctly. I’ve tried all of the rt, LTS, and regular kernels that are listed in the kernel manager and always have the same problem, which I’ll detail below.

I have an M-Audio Firewire 410 semi-professional external soundcard that I’d really like to keep using. It should be supported according to the following link but I’m not having any luck with it.

When I have the 410 connected at boot time, or when I connect it after the system is up and running, I get the following or something close to it in dmesg.

[25219.826085] firewire_core 0000:03:00.0: rediscovered device fw0
[25219.826096] firewire_core 0000:03:00.0: phy config: new root=ffc1, gap_count=5
[25222.998659] firewire_core 0000:03:00.0: created device fw1: GUID 000d6c01109dc17a, S400
[25223.074782] snd-bebob fw1.0: Failed to send a cue to load firmware
[25223.074801] snd-bebob: probe of fw1.0 failed with error -5

I also have Windows 7 on this machine and when I boot into that the firmware is loaded and the device works. If I reboot into Linux from Windows then the power to the 410 is maintained, as is the firmware in the 410, and all looks good up to and including the login prompt. The light on the 410 stays solid throughout the reboot, which indicates that the firmware is loaded. When I log in it appears that the OS tries to initialize the device and fails in a manner similar to the above output and the light starts blinking to indicate that the device isn’t ready.

For some reason this firmware loading process isn’t working despite the fact that the hardware is natively supported by the kernel. I’m not a kernel guru, but from the information in the above link it would seem that regular kernels work fine. Is there a module that isn’t included with Manjaro kernels? If so, what would it be and how would I go about fixing it?
Thanks in advance.

Output of “inxi -Fx”

System: Host: HPPC-L Kernel: 4.14.48-2-MANJARO x86_64 bits: 64 compiler: gcc v: 8.1.1
Desktop: KDE Plasma 5.12.5 tk: Qt 5.11.0 Distro: Netrunner 2018.01 Rolling
Machine: Type: Desktop System: HP-Pavilion product: NY549AAR-ABA p6230y v: N/A serial:
Mobo: FOXCONN model: ALOE v: 1.01 serial: BIOS: American Megatrends v: 5.05
date: 10/26/2009
CPU: Topology: Quad Core model: AMD Phenom II X4 810 bits: 64 type: MCP arch: K10 rev: 2
L2 cache: 2048 KiB
flags: lm nx pae sse sse2 sse3 sse4a svm bogomips: 20758
Speed: 2600 MHz min/max: 800/2600 MHz Core speeds (MHz): 1: 2600 2: 800 3: 800 4: 800
Graphics: Card-1: Advanced Micro Devices [AMD/ATI] Barts PRO [Radeon HD 6850] driver: radeon v: kernel
bus ID: 01:00.0
Display: x11 server: X.Org 1.19.6 driver: radeon tty: N/A
OpenGL: renderer: AMD BARTS (DRM 2.50.0 / 4.14.48-2-MANJARO LLVM 6.0.0) v: 3.3 Mesa 18.1.1
direct render: Yes
Audio: Card-1: Advanced Micro Devices [AMD/ATI] SBx00 Azalia driver: snd_hda_intel v: kernel
bus ID: 00:14.2
Card-2: AMD Barts HDMI Audio [Radeon HD 6790/6850/6870 / 7720 OEM] driver: snd_hda_intel v: kernel
bus ID: 01:00.1
Sound Server: ALSA v: k4.14.48-2-MANJARO
Network: Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8168 v: 8.045.08-NAPI
port: e800 bus ID: 04:00.0
IF: enp4s0 state: up speed: 1000 Mbps duplex: full mac: 00:26:55:44:0d:18
Drives: HDD Total Size: 931.51 GiB used: 41.17 GiB (4.4%)
ID-1: /dev/sda vendor: Seagate model: ST1000DM010-2EP102 size: 931.51 GiB
Partition: ID-1: / size: 19.56 GiB used: 16.39 GiB (83.8%) fs: ext4 dev: /dev/sda6
ID-2: /home size: 83.55 GiB used: 24.78 GiB (29.7%) fs: ext4 dev: /dev/sda7
ID-3: swap-1 size: 2.01 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda5
Sensors: System Temperatures: cpu: 27.4 C mobo: N/A gpu: radeon temp: 36 C
Fan Speeds (RPM): N/A
Info: Processes: 180 Uptime: 7h 47m Memory: 7.79 GiB used: 2.34 GiB (30.0%) Init: systemd Compilers:
gcc: 8.1.1 Shell: bash v: 4.4.19 inxi: 3.0.10


#2

It does, though they do tweak and add various changes to the available packages.

Do you have any other Firewire devices, or another machine with a Firewire port, to rule out the interface on this particular machine?


#3

As I mentioned, I can dual boot this machine into Windows 7 64 bit and the FW410 works just fine. I also have another firewire sound card, a Presonus FP10, that works fine with Netrunner/Manjaro on this machine. However, for various reasons, I want to be able to use the M-Audio FW410 with Manjaro on this machine and use the FP10 on a different machine (that’s also currently running Netrunner).

So the hardware itself is not a problem physically in this case.
I should add that when I remove and insert the snd-bebob module I get the same results, but just these two lines.
[18599.834164] snd-bebob fw1.0: Failed to send a cue to load firmware
[18599.834182] snd-bebob: probe of fw1.0 failed with error -5

I’m guessing that it’s a subtle difference between the Arch kernel that the user I referenced in the link is using and the Manjaro kernel, perhaps a compile flag that is set differently or something like that.
From reading everything that’s on the net about using the FW410 in Linux I am aware that people have used the following workaround in the past. Boot into Windows and the OS will load the firmware, then reboot (but don’t power off) the machine into Linux and the firmware stays in place. This seemed to work because the light remained solid which indicated that the device is ready. But when I went to login it appears to try to reload the driver and then the light begins blinking again. I’ll do a test of this now and post the relevant output of dmesg here because that might offer a clue.

As an aside, I was of the understanding that the changes Netrunner makes to Manjaro are primarily based on KDE operability. Things like integrating kwallet and using the latest KDE packages and whatnot, but the underlying OS and kernel are left alone for the most part. The Manjaro kernel manager is used and from what I can tell it lists Manjaro kernels, so my problem shouldn’t be a result of using Netrunner instead of Manjaro and the Manjaro forum should be the place to look for help in this matter.

Thanks for the response. It’s both encouraging and frustrating to know that someone has this working fine with a stock Arch kernel but I can’t get it working.


#4

how about double posting
Standard Re: Firewire Audio Treiber, M-Audio Firewire 410, Firewire Utilities

Then let them hear their news from there

and now

lspci -knnvvv
lspci | grep -i FireWire 
dmesg | grep -i firewire 
lsmod | grep firewire 
ls -l /dev/fw* 
grep -i firewire /lib/udev/rules.d/* 

#5

Hi, thanks for responding so quickly all.
The links to the OpenSUSE forums are questions that I had asked earlier this year but never received any reply to (which is part of why I started looking for a different distro). If you look at the details you’ll see that I used OpenSUSE for quite a while and didn’t really post much at all. This is because I tend to do quite a bit of digging and solving on my own before asking someone else to spend time on my problems so let me know if I’m breaking forum protocols here because I’m not really experienced with what’s proper. I also posted the github question in parallel with this because I was hoping to get some advice from the user that was successful with getting the FW410 to work. I hope that doesn’t appear to be a cross posting because believe me, I’m not trying to waste anyone’s time.

So I booted into Windows and got the unit working, then rebooted into Netrunner and it still appeared to be fine visually up to and including the login screen. When I logged in, partway through the process of loading the environment the light started flashing again which indicated that the device was no longer ready. Here’s some dmesg output that might help. Keep in mind that normally it wouldn’t have the firmware preloaded but because this was a reboot from Windows it did, so the results are going to be different than a cold boot.

[crankey@HPPC-L ~]$ dmesg | grep -i firewire
[    1.356764] firewire_ohci 0000:03:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x2
[    1.356870] firewire_ohci 0000:03:00.0: isochronous cycle inconsistent
[    1.870732] firewire_core 0000:03:00.0: created device fw0: GUID 78563412000000f5, S800
[    1.878137] firewire_core 0000:03:00.0: created device fw1: GUID 000d6c01009dc17a, S400
[    1.878531] firewire_core 0000:03:00.0: phy config: new root=ffc1, gap_count=5
[    3.890054] firewire_core 0000:03:00.0: BM lock failed (timeout), making local node (ffc0) root
[    3.890057] firewire_core 0000:03:00.0: phy config: new root=ffc0, gap_count=5
[  101.757715] firewire_core 0000:03:00.0: phy config: new root=ffc1, gap_count=5
[  103.760439] firewire_core 0000:03:00.0: refreshed device fw1
[crankey@HPPC-L ~]$ dmesg | grep -i fw
[    1.870732] firewire_core 0000:03:00.0: created device fw0: GUID 78563412000000f5, S800
[    1.878137] firewire_core 0000:03:00.0: created device fw1: GUID 000d6c01009dc17a, S400
[  103.731106] snd-bebob fw1.0: transaction failed: timeout
[  103.731122] snd-bebob fw1.0: fail to get an input for MSU in plug 1: -5
[  103.760416] snd-bebob fw1.0: Failed to send a cue to load firmware
[  103.760426] snd-bebob: probe of fw1.0 failed with error -5
[  103.760439] firewire_core 0000:03:00.0: refreshed device fw1
[crankey@HPPC-L ~]$

This time during bootup it actually creates the device (the ‘c17a’ is the FW410).

[    1.878137] firewire_core 0000:03:00.0: created device fw1: GUID 000d6c01009dc17a, S400

After that, when I log in, the snd-bebob module seems to break things.

As for the lspci, dmesg, lsmod, etc., did you want their output posted here? There’s quite a bit so I thought I’d ask just to be sure before looking like I’m spamming the forum.


#6

Short sections are fine to be posted here (especially in code blocks, see edits above).

Otherwise, a pastebin site (e.g. bpaste.net) is a better place for longer output.


#7

Okay, this is a bit bizzare.

This morning I planned to post the ouput of the requested commands, but I wanted to do some additional analysis first so that perhaps I could frame the information with some constructive observations. Towards that end I did a reboot from Windows because I wanted to get a comparative listing of the output from those commands when the firmware was present and when it wasn’t. So when it rebooted I left the login screen alone and switched to a virtual terminal so that the device would still be functional. This approach seemed to work quite well as I was able to get the command outputs and also see the functioning device using ffado commands. I also was surprised to find that I could remove and reload the snd-bebob module without causing the device to break.

Without logging out of the virtual terminal I switched back to the login screen and logged in, expecting the device to drop out of service like it always does but this time it didn’t. I can only guess that it’s probably because I removed and reloaded the module while in the virtual terminal; or perhaps it was probing the device with ffado commands. This doesn’t solve the firmware loading problem but it points to something that occurs while loading the environment after a regular login that breaks the device. Of course this probably won’t be a problem if the firmware loading works properly as it will just reload. I’m actually listening to something using this device as I type this so aside from the firmware loading issue the driver works.

As for the firmware loading issue, I’ve given it some thought and I don’t believe it’s a problem with the boot sequence as during a reboot with the firmware present the problem only occurs after logging in to the desktop and can be replicated then by unloading and reloading the snd-bebob module post-login. Why the same behavior isn’t observed when doing this from the virtual terminal without having entered the desktop mode is puzzling. It seems that while loading the desktop environment the firmware is wiped and at that point the device can’t be recovered but that should also happen after I’ve been in the virtual terminal.

To make it easier to reference I’ll make a separate post with the output of the requested commands both when the firmware is present and when it isn’t.

It’s nice to have this unit working in Linux, even if it is a workaround at the moment. It sounds good.


#8

Here is the output from the requested commands (plus another one), both with and without the firmware loaded.

lspci -knnvvv NoFirmware
https://bpaste.net/show/47711788b163
lspci -knnvvv YesFirmware
https://bpaste.net/show/92e995c12226

lspci | grep -i FireWire NoFirmware
https://bpaste.net/show/3f1de367b84e

lspci | grep -i FireWire YesFirmware
https://bpaste.net/show/ca336c2c2f12

dmesg | grep -i firewire NoFirmware
https://bpaste.net/show/c6f6290d4d36

dmesg | grep -i firewire YesFirmware
https://bpaste.net/show/299dea06fa14

lsmod | grep firewire NoFirmware
https://bpaste.net/show/467eef8c34b5

lsmod | grep firewire YesFirmware
https://bpaste.net/show/eecc4e4f3126

ls -l /dev/fw* NoFirmware
https://bpaste.net/show/dc4b0b5e4aad

ls -l /dev/fw* YesFirmware
https://bpaste.net/show/995bb1feea16

grep -i firewire /lib/udev/rules.d/* NoFirmware
https://bpaste.net/show/8d2ca4683ee9

grep -i firewire /lib/udev/rules.d/* YesFirmware
https://bpaste.net/show/5b21edbbf9b5

Here are a couple of other outputs that are somewhat informative. The difference between these two shows how the device has a different name after the firmware has been loaded, so it’s a quick way to verify that it has been successful.

FFADO-TEST-Devices-NoFirmware
https://bpaste.net/show/0e43cbb6419b

FFADO-TEST-Devices-YesFirmware
https://bpaste.net/show/0adcb951e8ab


#9

Update.
I think I’ve determined what caused the device to fail upon login to the desktop. One of the things that was suggested by the successful user in the github thread was to reset the device to factory defaults in Windows to avoid difficulties in Linux. While doing this I saw that it had been set at a 96kHz sample rate, which was fine for Windows and might be for Linux under Jack too. But I’m guessing that when the desktop environment got to the point where pulseaudio tried to communicate with the soundcard there was a mismatch in sample rates and the device tried to reset but of course failed.
I’ve done a reboot from Windows again and didn’t log in with a virtual terminal but just normally to the desktop. This time the firmware stayed intact and it’s probably because the device was reset to default parameters, which are a sample rate of 44.1kHz and a buffer of 256 bytes. When I’ve got the firmware loading in Linux I can play around with changing the sample rate and buffer size, but until then I’ll leave it with what works to avoid confusing the issue.

So now it’s back to focusing on the root problem, which is why the firmware won’t load.

Is there a way to get verbose output from the snd-bebob module at boot time?


#10

I received a reply on github from the driver developer.

He thinks the inability to load the firmware is a 1394 bus reset problem. It seems to be common across different distros so I’m not sure what to do now.