On Tue, 2008-07-15 at 16:56 +0200, Takashi Iwai wrote:
Could you try the git tree git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git ?
Certainly, compiled and running: Linux prometheus 2.6.26-rc7-00240-gfae47c0 #1 SMP Mon Jul 14 22:10:33 BST 2008 x86_64 Quad-Core AMD Opteron(tm) Processor 2354 AuthenticAMD GNU/Linux
The card is detected, and the auto-detection really seems to do quite well: ACPI: PCI Interrupt Link [LK2E] enabled at IRQ 47 ACPI: PCI Interrupt 0000:83:00.0[A] -> Link [LK2E] -> GSI 47 (level, high) -> IRQ 47 PCI: Setting latency timer of device 0000:83:00.0 to 64 ALSA sound/pci/hda/hda_intel.c:2022: chipset global capabilities = 0x3500 ALSA sound/pci/hda/hda_intel.c:754: codec_mask = 0x2 ALSA sound/pci/hda/hda_codec.c:3242: autoconfig: line_outs=4 (0xd/0xf/0xe/0x10/0x0) ALSA sound/pci/hda/hda_codec.c:3246: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) ALSA sound/pci/hda/hda_codec.c:3250: hp_outs=1 (0x11/0x0/0x0/0x0/0x0) ALSA sound/pci/hda/hda_codec.c:3251: mono: mono_out=0x0 ALSA sound/pci/hda/hda_codec.c:3259: inputs: mic=0x14, fmic=0x0, line=0x13, fline=0x0, cd=0x0, aux=0x0 ALSA device list: #0: HDA Intel at 0xd0100000 irq 47
Unfortunately, it now reverts to the same "short attention span" problem that I have seen before. This occured when I tried to write a patch_creative.c myself, and I had blamed this on my unfamiliarity with the framework: hda_codec: num_steps = 0 for NID=0x8 (ctl = Line Capture Volume) ALSA sound/pci/hda/hda_intel.c:601: hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x101f000a ALSA sound/pci/hda/hda_intel.c:608: hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x101f000a ALSA sound/pci/hda/hda_intel.c:666: hda-intel: get_response timeout: IRS=0x0
I provoked this with a simple: cat /proc/asound/card0/codec#1
It produces valid-looking output the first time (that I shared with you in my initial e-mail), and then the card's short attention span gets the better of it. It is dead in the water, and no matter how hard ALSA tries, it gets no response out of it:
ALSA sound/pci/hda/hda_intel.c:666: hda-intel: get_response timeout: IRS=0x0 ALSA sound/pci/hda/hda_intel.c:666: hda-intel: get_response timeout: IRS=0x0 __ratelimit: 3 messages suppressed ALSA sound/pci/hda/hda_intel.c:666: hda-intel: get_response timeout: IRS=0x0 __ratelimit: 85 messages suppressed ALSA sound/pci/hda/hda_intel.c:666: hda-intel: get_response timeout: IRS=0x0
Can you perhaps decode the command from the printk to a problematic widget that should be left alone? I will now powercycle the machine and try to use the soundcard without poking at the codec info.
Note that I've tried this card on MSI as well, and the behaviour is exactly the same (only disabling MSI is another troubleshooting step for the framework, which is equally unsuccessful). The card displays various completely broken codec configurations once in this state, occasionally causing an 'Invalid AFG subtree' message but usually settling on a GPIO configuration with 255 I/Os (seemingly caused by reading an area of all ones): GPIO: io=255, o=255, i=255, unsolicited=1, wake=1 IO[0]: enable=1, dir=1, wake=1, sticky=1, data=1 IO[1]: enable=1, dir=1, wake=1, sticky=1, data=1 (and so on)
The mainboard that I'm trying this on is a Tyan Thunder n6650W (S2915-E) on BIOS revision 2.07; the card is in one of the 8-lane PCI-express slots.
Regards, Tony V.