E-MU PCI card not initializing on kernel 6.6

ITzTravelInTime · 2023-12-01 01:58:05

Hi, i have been running arch on i7 12700k pc with an E-MU EM8810 PCI card + the external E-MU 1820 dock via a PCIe to PCI riser/adapter and i have card mounted in my vertical GPU slot. On the 6.1 LTS kernel all has been working fine, but since Linux 6.4 and especially since 6.6 i have issues every time i boot any of those more recent kernels in any forks.

Basically since 6.4 i have no forms of inputs working whatsoever on my sound card (also tried changing settings using gnome-alsamixer and pavucontrol but so far nothing) and only outputs working and since 6.6 the every kernel i tried doesn't initialize the card at all, it even doesn't advance playback if i try to play back anything using any player, so it seems that the system, doesn't even get responses from the card anymore.

This sound card requires alsa-firmware to be able to program its integrated fpgas on both the PCI part and the external part and also to basically tell the PCI card to power on the external module, something it isn't doing on 6.6, i was thinking it might be something having to do with the firmware programming process and driver-related but i am not sure, and I don't know any way of testing if this is actually the case and also to try and force manually the card to be re-initialized after boot.

Thanks in advice for the help and suggestions.

seth · 2023-12-01 09:02:19

Some actual data might be helpful, notably comparative journals for LTS and main kernel.

sudo journalctl -b | curl -F 'file=@-' 0x0.st

ITzTravelInTime · 2023-12-01 12:38:15

seth wrote:

Some actual data might be helpful, notably comparative journals for LTS and main kernel.
sudo journalctl -b | curl -F 'file=@-' 0x0.st

Fair enough, here is the latest 6.6.0.15 linux-rt kernel journal:
- http://0x0.st/HxQo.txt
And here is the 6.1.59.16. linux-rt-lts one:
- http://0x0.st/HxQX.txt

As I said, I have those issues regardless of the kernel fork I use, so I decided to upload both the latest rt and the lts-rt because it's what I have already installed in my system.

Thank you for the help.

V1del · 2023-12-01 13:17:15

dic 01 13:27:57 itztravelintime-EOS kernel: snd_emu10k1 0000:09:05.0: emu1010: Audio Dock detached
dic 01 13:27:57 itztravelintime-EOS kernel: snd_emu10k1 0000:09:05.0: emu1010: EMU_HANA+DOCK_ID = 0x7f
dic 01 13:27:57 itztravelintime-EOS kernel: snd_emu10k1 0000:09:05.0: emu1010: Loading Audio Dock Firmware file failed, reg = 0x7f

Do you know the kernel where this first started failing? You mention 6.4 which are like multiple major kernels in between. There's a whole bunch of changes in that driver https://github.com/torvalds/linux/commi … ci/emu10k1 random guess based on the dock firmware loading failure -- https://github.com/torvalds/linux/commi … 67d1e75783

Also note that Endeavour OS is not supported here and you should be asking on their help channels, but this is very likely a kernel issue that's going to affect everything, so I suggest you report that on the kernel bugzilla/mailinglist as a regression. But it would be better if you could single out certain kernel versions better. You are lacking a year of major development when sticking to LTS and not reporting/checking on issues that crop up in latter updates.

seth · 2023-12-01 15:13:30

firewire on the same device also complain w/ the main kernel (but not LTS)

dic 01 13:27:41 itztravelintime-EOS kernel: firewire_ohci 0000:09:05.2: isochronous cycle inconsistent
…
dic 01 13:27:43 itztravelintime-EOS kernel: firewire_core 0000:09:05.2: BM lock failed (timeout), making local node (ffc0) root

Interestingly the LTS kernel has

dic 01 13:33:07 itztravelintime-EOS kernel: spi-nor spi0.0: s25fl064k (8192 Kbytes)
dic 01 13:33:07 itztravelintime-EOS kernel: spi-nor spi0.1: BFPT parsing failed. Please consider using SPI_NOR_SKIP_SFDP when declaring the flash
dic 01 13:33:07 itztravelintime-EOS kernel: spi-nor: probe of spi0.1 failed with error -524

while that's not a problem on the main kernel.

On a limb, blacklist spi-nor

Scimmia · 2023-12-01 15:21:30

dic 01 13:27:41 itztravelintime-EOS systemd[1]: Found device CT1000P5PSSD8 endeavouros.

Is this Arch or EndeavourOS?

seth · 2023-12-01 15:25:53

V1del wrote:

Also note that Endeavour OS is not supported here and you should be asking on their help channels

I assume the thread currently remains open for personal interest of a moderator

ITzTravelInTime · 2023-12-01 17:17:27

To be honest that's just my volume label because that's what i used to run, but if you want i can just spend a couple of hours re-installing a clean system on a spare SSD i got, but regardless i am pretty sure i get the same error since it's kernel and driver related it seems.

Anyway, any ideas about how can i test single kernel releases to narrow down the commit? i am pretty much a noob when it comes to installing a kernel from source and doing some debug work on it, i only did similar stuff on OS X though since i maintain a fork of the mac kx audio driver (and back ported it to PPC machines).

seth · 2023-12-01 17:29:13

You can get older kernels from the https://wiki.archlinux.org/title/Arch_Linux_Archive - since the kernel is mostly self-contained, that's "fine". And in doubt you'll have the LTS kernel to boot.

Edit: did you try to blacklist spi-nor?

Last edited by seth (2023-12-01 17:29:31)

ITzTravelInTime · 2023-12-01 18:48:33

seth wrote:

You can get older kernels from the https://wiki.archlinux.org/title/Arch_Linux_Archive - since the kernel is mostly self-contained, that's "fine". And in doubt you'll have the LTS kernel to boot.
Edit: did you try to blacklist spi-nor?

Here is the journal output with spi_nor disabled using the kernel boot args: http://0x0.st/Hxjy.txt

To try kernel commits i will have to do it when i have some more time available, i will keep you posted when i have news,

In the meanwhile i was also thinking about getting into contact with that developer doing work for the snd_emu10k1 driver and perhaps troubleshooting the issue together, since i am familiar with stuff about this chip families by having worked on my fork of the kx audio driver, can this be a good idea?

seth · 2023-12-01 22:20:15

"BM lock failed" is gone, but "isochronous cycle inconsistent" remains and so does "Loading Audio Dock Firmware file failed"

Try to add "modprobe.blacklist=snd_emu10k1" and only explicitly load the module after the boot.
Does the dock still power on with the bad kernels?

You'll eventually have to rise this upstream anyway, I'm not 100% sure that it's strictly related to the snd_emu10k1 module, though (b/c the firewire issue, this might be rather the bus)

ITzTravelInTime · 2023-12-02 18:30:37

seth wrote:

"BM lock failed" is gone, but "isochronous cycle inconsistent" remains and so does "Loading Audio Dock Firmware file failed"
Try to add "modprobe.blacklist=snd_emu10k1" and only explicitly load the module after the boot.
Does the dock still power on with the bad kernels?
You'll eventually have to rise this upstream anyway, I'm not 100% sure that it's strictly related to the snd_emu10k1 module, though (b/c the firewire issue, this might be rather the bus)

Loading the driver after boot just causes the dock light to flash for a moment and then everything to be off, and the commit pointed out by @V1del seems to be a pretty strong suspect, as you can see here https://github.com/torvalds/linux/blob/ … ain.c#L735, since in the file emu10k1_main.c inside the emu1010_firmware_work function, the temp value which determinate the success of the firmware programming has different values, on 6.1 LTS kernel is 0x55 and now on 6.6 0x7F and so the driver goes into a sort of fallback state because it seems like the programming failed, on the 6.1 in case of failed programming the driver would also attempt to re-schedule a re-loading which now it no longer does.

It looks like that this approach of using an interrupt based method to trigger a load of the firmware for the dock actually broke things, it seems, at least for me.

Anyway, what do you think might be the best way of getting into contact with the driver developers/maintainers ?

loqs · 2023-12-02 19:05:45

I would suggest you start by testing a 6.5 kernel. You can obtain old kernels from the ALA. If that has the issue that rules out V1del's suspect. If that does not have the issue I can build a kernel for the suspect commit and one for its parent. If only the suspect kernel has the issue you have found the cause.

ITzTravelInTime · 2023-12-02 19:36:27

loqs wrote:

I would suggest you start by testing a 6.5 kernel. You can obtain old kernels from the ALA. If that has the issue that rules out V1del's suspect. If that does not have the issue I can build a kernel for the suspect commit and one for its parent. If only the suspect kernel has the issue you have found the cause.

Since the rt kernel was updated pretty late to 6.6 i can confirm that with 6.5 the fpa firmware loaded, although i had no inputs working.

loqs · 2023-12-02 22:13:29

7d43f51e4046c49230dea0d4f991c4cd1759327f
https://drive.google.com/file/d/1_u-Ad4 … sp=sharing linux-6.5rc1.r4.g7d43f51e4046-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/15BMLyv … sp=sharing linux-headers-6.5rc1.r4.g7d43f51e4046-1-x86_64.pkg.tar.zst

fbb64eedf5a3a98071ee75808cfc1367d1e75783
https://drive.google.com/file/d/109nhSq … sp=sharing linux-6.5rc1.r5.gfbb64eedf5a3-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1bohHCF … sp=sharing linux-headers-6.5rc1.r5.gfbb64eedf5a3-1-x86_64.pkg.tar.zst

ITzTravelInTime · 2023-12-30 06:55:59

loqs wrote:

7d43f51e4046c49230dea0d4f991c4cd1759327f
https://drive.google.com/file/d/1_u-Ad4 … sp=sharing linux-6.5rc1.r4.g7d43f51e4046-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/15BMLyv … sp=sharing linux-headers-6.5rc1.r4.g7d43f51e4046-1-x86_64.pkg.tar.zst
fbb64eedf5a3a98071ee75808cfc1367d1e75783
https://drive.google.com/file/d/109nhSq … sp=sharing linux-6.5rc1.r5.gfbb64eedf5a3-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1bohHCF … sp=sharing linux-headers-6.5rc1.r5.gfbb64eedf5a3-1-x86_64.pkg.tar.zst

Sorry if i am bothering you but i just had time now to come to this stuff, can you please re-upload those? i am also in contact with one of the maintainers and i want to test that commit specifically.

But that commit seems to not be the culprit, since that stuff was merged for 6.5.0 and today i installed an old kernel 6.5.9 package from the arch linux archive and the fpga firmware loaded fine, it seems to be something that was merged for 6.6.0

Last edited by ITzTravelInTime (2023-12-30 06:57:39)

ITzTravelInTime · 2024-01-11 19:00:12

Update, i have built the kernel from source and i have reverted the changes from commit https://github.com/torvalds/linux/commi … 67d1e75783, and that's indeed what caused my issue, since this dock interrupt feature seems to be missing or working differently on the dsp chip used by my 8810 pci card, compared to the hw probably used to test that changes in the first place (probably a later pci or pcie card that uses the 1616 or 1616m dock).

Also i have done some tests on my e-mu 1616m pcie setup on the secondary desktop and the new fpga programming trigger method introduced in the above mentioned commit is pretty flawed, basically it doesn't reprogram the fpga if you plug the audio dock while the system is running (unlike the older way of doing it), and it does trigger the programming only at start up. This might be an issue for the users of the cardbus e-dsp card too, since they might need to hotplug the dock.

So i have reported my problem and my findings to one of the developers (tiwai@suse.de that has made many commits to snd_emu10k1) and i am waiting for a reply, i have also recommended ditching that fpga programming trigger method entirely.

So for now that's it i am waiting for an official patch or at least an answer, in case nothing is done at the end i will seek help by the community or i might just try to get a patch merged into the mainline myself.

Arch Linux

#1 2023-12-01 01:58:05

E-MU PCI card not initializing on kernel 6.6

#2 2023-12-01 09:02:19

Re: E-MU PCI card not initializing on kernel 6.6

#3 2023-12-01 12:38:15

Re: E-MU PCI card not initializing on kernel 6.6

#4 2023-12-01 13:17:15

Re: E-MU PCI card not initializing on kernel 6.6

#5 2023-12-01 15:13:30

Re: E-MU PCI card not initializing on kernel 6.6

#6 2023-12-01 15:21:30

Re: E-MU PCI card not initializing on kernel 6.6

#7 2023-12-01 15:25:53

Re: E-MU PCI card not initializing on kernel 6.6

#8 2023-12-01 17:17:27

Re: E-MU PCI card not initializing on kernel 6.6

#9 2023-12-01 17:29:13

Re: E-MU PCI card not initializing on kernel 6.6

#10 2023-12-01 18:48:33

Re: E-MU PCI card not initializing on kernel 6.6

#11 2023-12-01 22:20:15

Re: E-MU PCI card not initializing on kernel 6.6

#12 2023-12-02 18:30:37

Re: E-MU PCI card not initializing on kernel 6.6

#13 2023-12-02 19:05:45

Re: E-MU PCI card not initializing on kernel 6.6

#14 2023-12-02 19:36:27

Re: E-MU PCI card not initializing on kernel 6.6

#15 2023-12-02 22:13:29

Re: E-MU PCI card not initializing on kernel 6.6

#16 2023-12-30 06:55:59

Re: E-MU PCI card not initializing on kernel 6.6

#17 2024-01-11 19:00:12

Re: E-MU PCI card not initializing on kernel 6.6

Board footer