Most recent kernel where this bug did not occur: none Distribution: ubuntu Hardware Environment: gericom supersonic pci-e nv7 (Turion64 based notebook with ati mb) Problem Description: When system booted with acpi turned on sound is avaiable only through headphones (and very quiet). When system booted with acpi=off sound works. This bug exist also in alsa bugzilla: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1162 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2125 Steps to reproduce: boot with or without acpi=off
Created attachment 8124 [details] acpidump
Created attachment 8125 [details] dmesg output
Created attachment 8126 [details] dmidecode
Created attachment 8127 [details] interrupts
Created attachment 8128 [details] lspci
Did this work properly in any previous release? Sound fails by default, but works with "acpi=off"? possibly some sort of an an IRQ problem with the sound device, though it is strange that the headphones work at any volume in that case. Please try "pci=noirq" if that works, please try "acpi=noirq" Please try "noapic" Please attach the dmesg -s64000 (please disable the timestamps) and /proc/interrupts for the working and failing cases. The other possibility is that some BIOS SMI support is disabled when entering ACPI mode on this system. If this is the case, then you may be needing a platform-specific driver (ie. one ships with windows, but the analogous one may be missing from linux) to control things like hotkeys, sound volume or output.
Yes - sound fails by default, but works with "acpi=off". noapic boot paremeter makes no difference (I tried this as a first shot) as well as pci=noacpi (this was proposed as a workaround somewere). The erliest kernel I have tried was 2.6.15 shipped with ubuntu dapper drake (tested also 2.6.16.16, 2.6.17-rc4, 2.6.17-rc4 + acpi-test-20060310) but google says that some people had similar problems with earlier versions as well - I'll test few others versions within few days. As a side note I have also recompiled DSDT table (I'm also hunting problem with only partialy working battery status). The iasl displayed only two warnings, no errors. During disscusion on alsa bugzilla there was a conclussion that acpi seems to disable power supply to soundcard's amplifire (thus card is basicly working but speakers are muted and volume on headphones is very low).
Proposed boot options makes no difference. dmesgs and /proc/interrupts attached
Created attachment 8138 [details] dmesg with acpi turned on
Created attachment 8139 [details] dmesg with acpi turned off
Created attachment 8140 [details] /proc/interrupts with acpi turned on
Created attachment 8141 [details] /proc/interrupts with acpi turned off
kernel 2.6.17-rc4-mm3 makes no difference
please post lspci -vvx output for both acpi turned on and turned off.
Created attachment 8207 [details] lspci -vvx with acpi turned on
Created attachment 8208 [details] lspci -vvx with acpi=off
Please try pci=noacpi
re : comment#16: I mean please post 1. lspci -vvx with acpi=off 2. lspci -vvx with pci=noacpi
with pci=noacpi there is no sound with noacpi sound works propperly there is no difference (according to diff -uN) between output from lspci -vvx in this two cases so I attached only one file (but run as root so maby some more details are present).
Created attachment 8259 [details] lspci -vvx (the same for noacpi and pci=noacpi parameters)
fix for comment #19 and attachement #20 boot parameters were of course acpi=off and pci=noacpi
Is it related to ACPI interrupt?
Is there some way to proof this? Interrupts are different for working (acpi=off) and non working case. Wireless card refuse to work with acpi=off for example (it complains about interrupts) but works ok with acpi turned on. I can provide additional information but honestly I'm out of idea where to look for origin of the problem. This machine is dual boot with winXP so maby I can take some debug info from windows side (working correctly as one can expect)?
Re: ACPI interrupt "pci=noacpi" will break your ACPI interrupt if you run in IOAPIC mode. This is a known limitation of the "pci=noacpi" workaround. Per comment #4: 9: 0 IO-APIC-edge acpi Which ignores the override telling the kernel that ACPI is level sensitive on IOAPIC pin 21: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 21 low level) You can verify that the ACPI interrupt is working in the default case this way: Kill acpid cat /proc/interrupts | grep acpi cat /proc/acpi/event press the power button a few times you should see some power button event lines come out cat /proc/interrupts |grep acpi you should see the count increment at least onece for each power button press Based on this non-zero count, I expect that this is working: 169: 1079 IO-APIC-level acpi Re: sound device 0000:00:14.5 Multimedia audio controller: ATI Technologies Inc IXP SB400 AC'97 Audio Controller (rev 01) Interrupt: pin B routed to IRQ 137 Sometimes different vector, depending on other use of vectors: ACPI: PCI Interrupt 0000:00:14.5[B] -> GSI 17 (level, low) -> IRQ 209 ALSA sound/pci/atiixp.c:518: atiixp: codec reset timeout But no indication that there is something wrong with pin 17. Just to simplify, please build your kernel with CONFIG_PCI_MSI=n Please observe /proc/interruts play sound so that you can hear it in the headphones observe /proc/interrupts You should see the line with "ATI IXP" increment If that line is shared with something else, then unload the driver for that something else. (I noticed this was the case for the pci=noacpi case, but not for the ACPI case) Re: windows it would be interesting to get a dump of the IRQ assignments from Windows to verify that it puts the devices the same place that we do. Eg. If they run in PIC mode and we run in IOAPIC mode, I'd take that as a big hint... Re: IOAPIC on ATI There are a number of things that are somewhat risky on this system with the IOAPIC enabled, including a timer workaround, sky2 running in MSI mode (does it work?), and APIC bus errors. It might make sense to try to isolate the sound issue by running only in the simpler "noapic" mode.
Re: ACPI interrupts it works (with the method stated above) Re: Sound device I builded kernel with CONFIG_PCI_MSI=n I can see count increment when plaing music in /proc/interrupts in line associated with sound hardware. Boot parameters makes no change in this. Re: Windows according to Device Manager: IRQ BUS DEV 0 isa system time 1 isa keyboard 3 isa serial port 8 isa cmos timer 12 isa PS/2 port 13 isa FPU 14 isa IDE Master 15 isa IDE Slave 21 isa Microsoft ACPI 17 pci AC'97 Modem 17 pci Conexant AC-link audio 18 pci ATI RADEON MOBILITY 18 pci IEEE 1394 Controller 19 pci USB OpenHCD Controller 19 pci USB OpenHCD Controller 19 pci Bridge PCI to USB 20 pci Ralink WiFi 22 pci Cardbus Controller 22 pci PCIxx21 FlashMedia Controller So it seems running in APIC mode Re: ATI IOAPIC sky2 works correctly in IOAPIC mode as well as Ralink WiFi. Should I resubmit lspci -vvx and /proc/interrupts with pci=noacpi noapic?
sound works also if acpi=ht is passed at boot.
Any news on this ? Is it working with 2.6.19, or is there any hope for this bug to be fixed when 2.6.19 is released ? Thanks...
Hi Look at the bug #7228 : it's not the same hardware, but it may be the same DSDT issue finally. Can you check your DSDT for the issue described there ?
There is some OS cheking in DSDT table but looks harmless to me. Anyway I have commented out whole block of the code in DSDT and hardcoded values for Windows XP SP2 (values for Vista are not in the table). This does not change anything. I am out of lack...
Does this still happen on the latest kernel?
*** This bug has been marked as a duplicate of bug 7228 ***