Bug 4888 - ATI: no audio w/o acpi=noirq - HP Pavillion zv5231ea
Summary: ATI: no audio w/o acpi=noirq - HP Pavillion zv5231ea
Status: REJECTED UNREPRODUCIBLE
Alias: None
Product: ACPI
Classification: Unclassified
Component: Config-Interrupts (show other bugs)
Hardware: i386 Linux
: P2 high
Assignee: Len Brown
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-15 06:26 UTC by Folkert van Heusden
Modified: 2007-09-06 16:21 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.12.2
Subsystem:
Regression: ---
Bisected commit-id:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Folkert van Heusden 2005-07-15 06:26:01 UTC 
Distribution: not applicable (selfmade kernel)
Hardware Environment: HP Pavillion zv5231ea laptop
Software Environment:
Problem Description: when NOT giving 'pci=noacpi' on the kernel-commandline, the
kernel spits out some debugging about the audio-device in this laptop and from
then on refuses to produce any sound. WITH pci=noacpi, everything works fine.
<...>
atiixp: codec read timeout (reg 1c)
atiixp: codec read timeout (reg 0)
atiixp: codec read timeout (reg 3c)
atiixp: codec read timeout (reg 1c)
atiixp: codec read timeout (reg 0)
atiixp: codec read timeout (reg 3c)
atiixp: codec read timeout (reg 1c)
atiixp: codec read timeout (reg 0)
atiixp: codec read timeout (reg 3c)
atiixp: codec read timeout (reg 1c)
atiixp: codec read timeout (reg 0)
atiixp: codec read timeout (reg 3c)
atiixp: codec read timeout (reg 1c)
atiixp: codec read timeout (reg 0)
atiixp: codec read timeout (reg 3c)
atiixp: codec read timeout (reg 1c)
AC'97 2 does not respond - RESET
AC'97 2 access is not valid [0xffffffff], removing mixer.
(the timeouts appear a lot more by the way, I shortened things)

ehm:/home/folkert# lspci
0000:00:00.0 Host bridge: ATI Technologies Inc: Unknown device 5833 (rev 02)
0000:00:01.0 PCI bridge: ATI Technologies Inc: Unknown device 5838
0000:00:13.0 USB Controller: ATI Technologies Inc: Unknown device 4347 (rev 01)
0000:00:13.1 USB Controller: ATI Technologies Inc: Unknown device 4348 (rev 01)
0000:00:14.0 SMBus: ATI Technologies Inc ATI SMBus (rev 16)
0000:00:14.1 IDE interface: ATI Technologies Inc: Unknown device 4349
0000:00:14.3 ISA bridge: ATI Technologies Inc: Unknown device 434c
0000:00:14.4 PCI bridge: ATI Technologies Inc: Unknown device 4342
0000:00:14.5 Multimedia audio controller: ATI Technologies Inc IXP150 AC'97
Audio Controller
0000:00:14.6 Modem: ATI Technologies Inc: Unknown device 434d (rev 01)
0000:01:05.0 VGA compatible controller: ATI Technologies Inc: Unknown device 5835
0000:02:00.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000
Controller (PHY/Link)
0000:02:02.0 Network controller: Broadcom Corporation BCM4301 802.11b (rev 02)
0000:02:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
0000:02:04.0 CardBus bridge: Texas Instruments: Unknown device ac54 (rev 01)
0000:02:04.1 CardBus bridge: Texas Instruments: Unknown device ac54 (rev 01)
0000:02:04.2 System peripheral: Texas Instruments: Unknown device 8201 (rev 01)
0000:02:07.0 USB Controller: NEC Corporation USB (rev 43)
0000:02:07.1 USB Controller: NEC Corporation USB (rev 43)
0000:02:07.2 USB Controller: NEC Corporation USB 2.0 (rev 04)

I've discussed this problem with Andrew Morton, perex@suse.cz and tiwai@suse.de
and Andrew asked me to submit this problem into bugzilla.
Comment 1 Andrew Morton 2005-07-29 00:28:37 UTC 
Does this still happen in 2.6.13-rc4?

Are you able to identify an early 2.6 version which 
didn't need the `pci=noacpi'?
Comment 2 Len Brown 2005-08-14 22:43:34 UTC 
Is "acpi=noirq" a sufficient workaround, or is "pci=noacpi" required?
Does "pnpacpi=off" make any difference?

Is this still an issue in the latest kernel.org kernel (eg. 2.6.13-rc6)?

Was there an earlier ACPI-enabled kernel where this worked,
or has it always been broken?
Comment 3 Folkert van Heusden 2005-08-23 12:20:15 UTC 
acpi=noirq works fine too. So: both pci=noacpi and acpi=noirq work fine.
Should I try pnpacpi=off as well?
Comment 4 Len Brown 2007-08-18 20:48:31 UTC 
Still a problem with 2.6.22.stable?

if yes, do please try "pnpacpi=off" all by itself.

Also, please attach the dmesg and /proc/interrupts for
when booting with and without "acpi=noirq".  Also,
please attach a single copy of the output from
acpidump and lspci -vv
Comment 5 Len Brown 2007-09-06 16:21:28 UTC 
please re-open if still a problem in 2.6.22.stable or later.
Note You need to log in before you can comment on or make changes to this bug.