Kernel Bug Tracker – Bug 1440
sound problems from incorrect IRQ routing - IOAPIC + LNK
Last modified: 2010-03-04 09:03:28 UTC
Distribution: redhat 8.0
Hardware Environment: athlon
Software Environment: ??
Problem Description: cannot play sound
Steps to reproduce: boot -> play sound
If I revert the ChangeSet@1.1063.43.16, no sound problem.
Created attachment 1225 [details]
cat /proc/interrupts using the kernel that has sound problem
Created attachment 1226 [details]
alsa error message while trying to play sound
Created attachment 1227 [details]
outputs of acpidmp
Created attachment 1228 [details]
outputs of dmidecode
Created attachment 1229 [details]
outputs of dmesg
Created attachment 1230 [details]
/proc/interrupts using kernel which revert ChangeSet@1.1063..43.16
Created attachment 1314 [details]
regression isolated to this patch
The acpi_pci_link_allocate patch (attached) was integrated to address bug
It would be a mistake to quickly revert it in the kernel, as those systems
But it is a workaround for systems which we don't program properly.
So it seems like a mistake to have it enabled by default, as it can
negatively impact system which do not require the workaround,
resulting IRQ routing may be non-optimal (bug #1391),
or incorrect (this report).
Probably we should enable the workaround on the failing systems
manually via boot flag, or by black-list, rather than always.
Created attachment 1352 [details]
patch to address the issue
Please test this patch -- run the sound, attach the dmesg and /proc/interrupts.
Turns out that this systems is one of the rare birds that uses
PCI Link Devices when in IO-APIC mode.
Please attach the lspci -v output so we can get a better description of the hardware.
Also, it would be interesting to know if the the systems works properly
with the attached patch and "noapic" on the cmdline.
Created attachment 1355 [details]
dmesg (kernel-BK + patch(id=1352)
Using current BK kernel + patch (id=1352), NO sound problem.
Created attachment 1356 [details]
/proc/interrupts: kernel-BK + patch (id=1352)
Created attachment 1357 [details]
lspci -v output
If I add 'pci=noacpi' cmdline option, X does not run.
I could see only BLANK screen.
I remember this system worked fine without ACPI (not-compiled into kernel). I
included ACPI code for automatic power-off (halt -p).
here is the /proc/interrupts with 'pci=noacpi':
0: 6535 IO-APIC-edge timer
1: 151 IO-APIC-edge keyboard
2: 0 XT-PIC cascade
8: 1 IO-APIC-edge rtc
9: 0 IO-APIC-edge usb-uhci, usb-uhci
10: 3 IO-APIC-edge acpi, eth0
14: 4569 IO-APIC-edge ide0
15: 6 IO-APIC-edge ide1
Thanks for confirming that the patch fixes the sound problem.
the pci=noacpi problem is because the system is fooled into enabling the IOAPIC
when it hasn't got IOAPIC info from ACPI (and MPS doesn't exist). this is bug #1219.
Can you try out booting with "noapic"?
Ah! I already tried 'noacpi'. Because I could not see any
difference, I tried 'pci=noacpi'.
I had no problem with 'noacpi' cmdline option.
There is no such option "noacpi" -- so it is ignored.
The option we want to try is "noapic".
oops! With 'noapic', the sound works fine. I checked dmesg.
ACPI: Skipping IOAPIC probe due to 'noapic' option.
Kernel command line: ro hdc=ide-scsi vga=0x317 noapic
9: 0 XT-PIC usb-uhci, usb-uhci
10: 2143 XT-PIC acpi, eth0, VIA686A
fix shipped in 2.4.23
2.6.0 patch is here:
included with latest ACPI for 2.6.0 here:
*** Bug 15427 has been marked as a duplicate of this bug. ***