Sometimes, but not always, when starting a recording stream through this HDA controller, the recording stream is not successfully started. Instead, the controller generates a large amount of interrupts (~40 000 interrupts per second). After this has happened, jack sense (i e unsolicited events from the codec) stops working until the next system reboot.
=== Similar bugs ===
Here are some possible duplicates:
Bug #743266 (HP Pavilion dv7)
Bug #764062 (Lenovo x120e)
Bug #775245 (Lenovo x100e)
Bug #770555 (Asus 1215T)
Bug #755847 (HP Pavilion DV6-1210SA)
Bug #774654 Dell Inspiron 1546
Bug #778716 ASRock 890GM Pro3
Bug #780419 Sapphire Tech PCM-AM3RS790G
Bug #780532 Toshiba Satellite L645D
Bug #781240 ASUS 1215T
Bug #775788 Acer Aspire One 522
Bug #787281 MSI 880GM-P51 (MS-7623)
Bug #788371 BIOSTAR Group TA890GXE
Bug #782891 MICRO-STAR MS-7388
Bug #787147 HP 62G Notebook PC
Bug #787001 HP Presario CQ56 Notebook PC
These controllers are affected: ATI [1002:4383] and ATI [1002:4383] (rev 40)
=== Checking for duplicate ===
A bug is a duplicate of this if at some point all of the following conditions are fulfilled:
1) The PCI controller ID (as checked with "lspci -vvnn") is ATI [1002:4383] and ATI [1002:4383] (rev 40)
2) Jack sense is not working - i e, you still have sound from either internal speakers or headphones, but it remains the way it was when the system was last rebooted and does not change on plug/unplug.
3) Recording is not working - there is no recording stream
4) When you're trying to record, you're instead seeing massive interrupts ( > 10.000 per second) for hda_intel, i e, the output of "cat /proc/interrupts | grep hda_intel" is increasing rapidly while unsuccessfully recording.
=== Investigation ===
By inserting some printk's into the kernel code I've traced down the interrupt problem to the recording stream returning a FIFO error (SD0STS returns 0x28). The interrupt service routine acknowledges this error but does not do anything to counteract the root cause to the problem, so it appears again and again.
Restarting the stream does not seem to help.
I have seen this bug on
1) 2.6.35
2) 2.6.38-rc8 mainline kernel build
3) 2.6.35 + daily snapshot of ALSA HDA modules
I have seen it both with and without fglrx.
ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: alsa-base 1.0.23+dfsg-1ubuntu4
Uname: Linux 2.6.38-020638rc8-generic i686
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.23.
AplayDevices:
**** List of PLAYBACK Hardware Devices ****
card 0: SB [HDA ATI SB], device 0: CONEXANT Analog [CONEXANT Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
Architecture: i386
ArecordDevices:
**** List of CAPTURE Hardware Devices ****
card 0: SB [HDA ATI SB], device 0: CONEXANT Analog [CONEXANT Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC0: ubuntu 1292 F.... pulseaudio
Card0.Amixer.info:
Card hw:0 'SB'/'HDA ATI SB at 0xd0600000 irq 16'
Mixer name : 'Conexant CX20582 (Pebble)'
Components : 'HDA:14f15066,17aa21b2,00100301'
Controls : 8
Simple ctrls : 5
Card29.Amixer.info:
Card hw:29 'ThinkPadEC'/'ThinkPad Console Audio Control at EC reg 0x30, fw 6XHT42WW-1.182000'
Mixer name : 'ThinkPad EC 6XHT42WW-1.182000'
Components : ''
Controls : 1
Simple ctrls : 1
Card29.Amixer.values:
Simple mixer control 'Console',0
Capabilities: pswitch pswitch-joined penum
Playback channels: Mono
Mono: Playback [on]
CurrentDmesg:
[ 89.940031] hda-intel: azx_get_response timeout, switching to polling mode: last cmd=0x001f000a
[ 90.944071] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x001f000a
[ 181.943909] r8169 0000:02:00.0: eth0: link up
[ 181.944638] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Date: Thu Mar 24 11:39:51 2011
DistributionChannelDescriptor:
# This is a distribution channel descriptor
# For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor
canonical-oem-sutton-20110310-0
InstallationMedia: Ubuntu 10.10 "Maverick" - Build i386 LIVE Binary 20110310-01:59
PackageArchitecture: all
ProcEnviron:
LANG=en_US.utf8
SHELL=/bin/bash
SourcePackage: alsa-driver
dmi.bios.date: 10/28/2010
dmi.bios.vendor: LENOVO
dmi.bios.version: 6XET46WW (1.29 )
dmi.board.name: 287622U
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr6XET46WW(1.29):bd10/28/2010:svnLENOVO:pn287622U:pvrThinkPadX100e:rvnLENOVO:rn287622U:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 287622U
dmi.product.version: ThinkPad X100e
dmi.sys.vendor: LENOVO
I've tried a SB800 platform with "00:14.2 0403: 1002:4383 (rev 40)" HDA controller and ALC889, but unable to reproduce it.
Do you observe the large amount of interrupts and the following dmesg
[ 89.940031] hda-intel: azx_get_response timeout, switching to polling mode: last cmd=0x001f000a
[ 90.944071] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x001f000a
during every boot up?
The HD-Audio.txt (documentation/ sound/alsa) describes this problem as a fatal error. Can you try the workaround described in the document?