Bug 6575 - sound only through headphones when acpi turned on
Summary: sound only through headphones when acpi turned on
Status: CLOSED DUPLICATE of bug 7228
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Other (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Len Brown
Depends on:
Reported: 2006-05-17 07:34 UTC by Marcin Bukat
Modified: 2008-01-12 16:02 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.17rc4 + acpi-test-20060310
Regression: ---
Bisected commit-id:

acpidump (125.61 KB, application/octet-stream)
2006-05-17 07:35 UTC, Marcin Bukat
dmesg output (18.88 KB, application/octet-stream)
2006-05-17 07:36 UTC, Marcin Bukat
dmidecode (8.37 KB, application/octet-stream)
2006-05-17 07:36 UTC, Marcin Bukat
interrupts (564 bytes, application/octet-stream)
2006-05-17 07:37 UTC, Marcin Bukat
lspci (13.29 KB, application/octet-stream)
2006-05-17 07:37 UTC, Marcin Bukat
dmesg with acpi turned on (14.69 KB, application/octet-stream)
2006-05-18 14:21 UTC, Marcin Bukat
dmesg with acpi turned off (12.71 KB, application/octet-stream)
2006-05-18 14:22 UTC, Marcin Bukat
/proc/interrupts with acpi turned on (595 bytes, application/octet-stream)
2006-05-18 14:22 UTC, Marcin Bukat
/proc/interrupts with acpi turned off (526 bytes, application/octet-stream)
2006-05-18 14:22 UTC, Marcin Bukat
lspci -vvx with acpi turned on (15.85 KB, application/octet-stream)
2006-05-26 00:28 UTC, Marcin Bukat
lspci -vvx with acpi=off (15.86 KB, application/octet-stream)
2006-05-26 00:29 UTC, Marcin Bukat
lspci -vvx (the same for noacpi and pci=noacpi parameters) (17.97 KB, application/octet-stream)
2006-06-05 11:59 UTC, Marcin Bukat

Description Marcin Bukat 2006-05-17 07:34:15 UTC
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
This bug exist also in alsa bugzilla:

Steps to reproduce:
boot with or without acpi=off
Comment 1 Marcin Bukat 2006-05-17 07:35:24 UTC
Created attachment 8124 [details]
Comment 2 Marcin Bukat 2006-05-17 07:36:07 UTC
Created attachment 8125 [details]
dmesg output
Comment 3 Marcin Bukat 2006-05-17 07:36:37 UTC
Created attachment 8126 [details]
Comment 4 Marcin Bukat 2006-05-17 07:37:11 UTC
Created attachment 8127 [details]
Comment 5 Marcin Bukat 2006-05-17 07:37:32 UTC
Created attachment 8128 [details]
Comment 6 Len Brown 2006-05-18 00:54:22 UTC
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.
Comment 7 Marcin Bukat 2006-05-18 01:50:39 UTC
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.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

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).
Comment 8 Marcin Bukat 2006-05-18 14:20:04 UTC
Proposed boot options makes no difference. dmesgs and /proc/interrupts attached
Comment 9 Marcin Bukat 2006-05-18 14:21:27 UTC
Created attachment 8138 [details]
dmesg with acpi turned on
Comment 10 Marcin Bukat 2006-05-18 14:22:00 UTC
Created attachment 8139 [details]
dmesg with acpi turned off
Comment 11 Marcin Bukat 2006-05-18 14:22:28 UTC
Created attachment 8140 [details]
/proc/interrupts with acpi turned on
Comment 12 Marcin Bukat 2006-05-18 14:22:55 UTC
Created attachment 8141 [details]
/proc/interrupts with acpi turned off
Comment 13 Marcin Bukat 2006-05-24 05:01:15 UTC
kernel 2.6.17-rc4-mm3 makes no difference
Comment 14 Luming Yu 2006-05-24 06:01:20 UTC
please post lspci -vvx output for both acpi turned on and turned off.
Comment 15 Marcin Bukat 2006-05-26 00:28:54 UTC
Created attachment 8207 [details]
lspci -vvx with acpi turned on
Comment 16 Marcin Bukat 2006-05-26 00:29:42 UTC
Created attachment 8208 [details]
lspci -vvx with acpi=off
Comment 17 Luming Yu 2006-06-04 19:54:18 UTC
Please try pci=noacpi
Comment 18 Luming Yu 2006-06-04 19:57:39 UTC
re : comment#16:

I mean please post 
1. lspci -vvx with acpi=off 
2. lspci -vvx with pci=noacpi
Comment 19 Marcin Bukat 2006-06-05 11:57:58 UTC
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).
Comment 20 Marcin Bukat 2006-06-05 11:59:21 UTC
Created attachment 8259 [details]
lspci -vvx (the same for noacpi and pci=noacpi parameters)
Comment 21 Marcin Bukat 2006-06-05 12:02:00 UTC
fix for comment #19 and attachement #20
boot parameters were of course acpi=off and pci=noacpi
Comment 22 Luming Yu 2006-06-07 08:23:55 UTC
Is it related to ACPI interrupt?
Comment 23 Marcin Bukat 2006-06-07 11:36:07 UTC
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)?
Comment 24 Len Brown 2006-06-08 09:22:32 UTC
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
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

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
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...

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.

Comment 25 Marcin Bukat 2006-06-09 07:32:09 UTC
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:

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   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

sky2 works correctly in IOAPIC mode as well as Ralink WiFi.
Should I resubmit lspci -vvx and /proc/interrupts with pci=noacpi noapic?
Comment 26 Marcin Bukat 2006-11-10 13:32:53 UTC
sound works also if acpi=ht is passed at boot.
Comment 27 pinaraf 2006-11-22 11:53:04 UTC
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 ?

Comment 28 pinaraf 2007-01-13 11:12:23 UTC

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 ?
Comment 29 Marcin Bukat 2007-01-14 09:18:08 UTC
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...
Comment 30 Fu Michael 2007-10-24 19:07:19 UTC
Does this still happen on the latest kernel?
Comment 31 Fu Michael 2007-11-30 02:20:38 UTC

*** This bug has been marked as a duplicate of bug 7228 ***

Note You need to log in before you can comment on or make changes to this bug.