Kernel Bug Tracker – Bug 6575
sound only through headphones when acpi turned on
Last modified: 2008-01-12 16:02:10 UTC
Most recent kernel where this bug did not occur: none
Hardware Environment: gericom supersonic pci-e nv7 (Turion64 based notebook with
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
This bug exist also in alsa bugzilla:
Steps to reproduce:
boot with or without acpi=off
Created attachment 8124 [details]
Created attachment 8125 [details]
Created attachment 8126 [details]
Created attachment 8127 [details]
Created attachment 8128 [details]
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 126.96.36.199, 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
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
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
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
cat /proc/interrupts | grep acpi
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
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
Please observe /proc/interruts
play sound so that you can hear it in the headphones
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)
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.
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 ?
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 ***