Distribution: Debian (unstable) Hardware Environment: VIA Nehemiah CPU, via82xx audio (CL10000 mini-itx board) Problem Description: I am unable to play any audio since kernel version 2.6.6. Version 2.6.5 works fine and I have tested that 2.6.7 and 2.6.8-rc3-bk2 both do not work. When trying to play some audio, it sounds like there is about 0.5 seconds of audio played, which then loops for a few seconds, then the following message appears in dmesg: irq 9: nobody cared! [<c010490e>] dump_stack+0x1e/0x30 [<c0105d3b>] __report_bad_irq+0x2b/0x90 [<c0105e26>] note_interrupt+0x66/0xa0 [<c01060d3>] do_IRQ+0x133/0x150 [<c01044d8>] common_interrupt+0x18/0x20 [<c011961b>] do_softirq+0x2b/0x30 [<c01060a8>] do_IRQ+0x108/0x150 [<c01044d8>] common_interrupt+0x18/0x20 handlers: [<c01da946>] (acpi_irq+0x0/0x1a) Disabling IRQ #9 Steps to reproduce: "ogg123 somefile.ogg" or "mpg123 somefile.mp3", etc.
Created attachment 3484 [details] Kernel config file (2.6.8-rc3-bk2)
Created attachment 3485 [details] dmesg (2.6.8-rc3-bk2)
After reading a few more reports with similar error messages, I'm guessing this is probably an ACPI issue.
Created attachment 3496 [details] test patch I suspect your audio card should have a quirk. Could you please try the test patch? If it works, please send your 'lspci -vv' to me, I'll make a formal patch it. Thanks, shaohua.
After also adding #include <linux/delay.h> to the top of pci_irq.c, the patched kernel (2.6.8-rc4-bk2) compiled but this did not fix the problem. Dmesg is identical apart from the "Memory:" line and a HTB version increment.
Created attachment 3497 [details] patch for VIA audio quirk Via email Kevin confirmed that after correcting a typo (change '11' to '0x11') in the test patch the test patch works, so here is the formal patch. Hope I find the correct PCI id. Kevin, could you please try it? Thanks, Shaohua.
Yes, this new patch triggers the quirk/fixup and makes the audio playback work correctly. Thanks David. dmesg | grep Via PCI: Via IRQ fixup for 0000:00:10.2, from 9 to 10 PCI: Via IRQ fixup for 0000:00:11.5, from 9 to 10
Created attachment 3499 [details] lspci -vv output lspci -vv output, so others can validate the patch.
ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 10 11 12 14 *15) ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 11 12 14 15) *9 ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 10 11 *12 14 15) ... PCI: Using ACPI for IRQ routing ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 12 ACPI: PCI interrupt 0000:00:0f.0[A] -> GSI 12 (level, low) -> IRQ 12 ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 ACPI: PCI interrupt 0000:00:10.0[A] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 15 ACPI: PCI interrupt 0000:00:10.1[B] -> GSI 15 (level, low) -> IRQ 15 ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10 ACPI: PCI interrupt 0000:00:10.2[C] -> GSI 10 (level, low) -> IRQ 10 ACPI: PCI interrupt 0000:00:10.3[D] -> GSI 12 (level, low) -> IRQ 12 ACPI: PCI interrupt 0000:00:11.1[A] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI interrupt 0000:00:11.5[C] -> GSI 10 (level, low) -> IRQ 10 ACPI: PCI interrupt 0000:00:12.0[A] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI interrupt 0000:00:14.0[A] -> GSI 15 (level, low) -> IRQ 15 ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11 This is very unusual. BIOS put PCI devices on IRQ12 and IRQ 15. Good thing you don't have a PS/2 mouse or a secondary legacy IDE controller. Primary IDE comes up as a PCI device on IRQ11. cool -- show me your /proc/interrupts! ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 11 12 14 15) *9 This is a case of the "CRS outside of PRS", where the BIOS sets LNKC to IRQ9 and then tells Linux that IRQ9 is illegal, so Linux choses another IRQ from the list -- we chose IRQ10: ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10 ACPI: PCI interrupt 0000:00:10.2[C] -> GSI 10 (level, low) -> IRQ 10 ACPI: PCI interrupt 0000:00:11.5[C] -> GSI 10 (level, low) -> IRQ 10 which included one of the USB controllers: uhci_hcd 0000:00:10.2: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#3) and sound: Advanced Linux Sound Architecture Driver Version 1.0.4 (Mon May 17 14:31:44 2004 UTC). ACPI: PCI interrupt 0000:00:11.5[C] -> GSI 10 (level, low) -> IRQ 10 PCI: Setting latency timer of device 0000:00:11.5 to 64 ALSA device list: #0: VIA 8235 at 0xd400, irq 10 VIA has had a long standing quirk where in PIC mode you have to write into PCI config space in addition to the $PIRQ routing, and in this case the ACPI PCI Interrupt Link routing. Apparently this particular VIA chip-set was not yet in the list -- is it very new, or very old? I think David's fix is correct, and it would work even if ACPI were not used for IRQ routing on this box should the legacy PIRQ code decide to move that interrupt. Perhaps you can include the dmesg and /proc/interrupts from the "acpi=off" case to confirm that the legacy code either leaves sound on IRQ9, or performs the quirk when it moves sound to IRQ 10?
I suppose the chipset is reasonably new. It's a Via mini-itx board - see here: http://www.viaembedded.com/product/epia_cl_spec.jsp?motherboardId=181 Currently this machine is out of action with a dead hard-drive, but I'll get that other information to you as soon as I can. So, to clarify, you want: /proc/interrupts (with acpi running as normal) /proc/interrupts (with acpi=off) dmesg (with acpi=off) Would that be with or without the quirk patch from this bug?
Created attachment 3586 [details] /proc/interrupts (with acpi running as normal)
Created attachment 3587 [details] /proc/interrupts (acpi=off)
Created attachment 3588 [details] dmesg (acpi=off)
Created attachment 3705 [details] final patch patch using new PCI quirk syntax. Len, please merge it.
Created attachment 3963 [details] Shaohua's patch as ported to 2.6.10 tree
Since the code is the same on kernels 2.4, this patch should go on kernel 2.4 too.
Shipped in Linux 2.6.10-rc2 - closed.
Created attachment 4240 [details] new test patch Made quirk for every device is really tough. Could you please remove previous patch and try this patch? This patch lools more generic. Thanks.
Yes, the new patch also works (applied against a clean 2.6.9 tree)