Most recent kernel where this bug did not occur: unknown (booted 2.6.17/Debian-amd64, 2.6.18/Debian-amd64, 2.6.19-rc4/own-amd64, 2.6.19-rc4/own-i386) Distribution: Debian 'sid' amd64 (now), i386 (first) Hardware Environment: DFI RS482 mainboard, Athlon64 3200+ Software Environment: Debian 'sid' + selfmade kernel Problem Description: Loading 'snd-atiixp' kernel module gives: ----------------------------------------------------------- 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. atiixp: no codec available ACPI: PCI interrupt for device 0000:00:14.5 disabled ----------------------------------------------------------- 'codec read timeout' lines are repeating many times. Due to https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2081 it is ACPI problem. I tried pci=noacpi, acpi=off, pci=routeirq, irqpoll (last one was needed to get NIC working with i386 kernel) - each time same results. Steps to reproduce: Boot kernel, modprobe snd-atiixp module.
Created attachment 9426 [details] dmesg -s40000 output
Created attachment 9427 [details] lspci -vv output
Created attachment 9428 [details] kernel config from my kernel
Why is this thought to be an acpi problem? From the bugtrack.alsa-project.org report I see no confirmation that acpi is involved?
Most of informations which I found related to this bug cames with suggestions that this is related to ACPI.
There was an accidental code change in: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=ee42381e71c56328db9e9d64d19a4de7a2f09a93;hp=dc4cafbadad1ae2322e598f2cb72720ef4095fee In snd_ac97_try_volume_mix(struct snd_ac97 * ac97, int reg) it now reads register twice in a row which seems pointless. I'll attach a patch.
Created attachment 9442 [details] One read the register one time. Restore old behavior.
No, reading twice is intentional. Some hardwares require a dummy fetch first for reflecting the real value. I'm wondering whether your patch fixes your problem. Does it?
ALSA sound/pci/atiixp.c:458: atiixp: codec read timeout (reg 3c) ALSA sound/pci/atiixp.c:458: atiixp: codec read timeout (reg 1c) ALSA sound/pci/atiixp.c:458: atiixp: codec read timeout (reg 0) ALSA sound/pci/atiixp.c:458: atiixp: codec read timeout (reg 3c) ALSA sound/pci/atiixp.c:458: atiixp: codec read timeout (reg 1c) ALSA sound/pci/ac97/ac97_codec.c:2030: AC'97 2 does not respond - RESET ALSA sound/pci/ac97/ac97_codec.c:2039: AC'97 2 access is not valid [0xffffffff], removing mixer. ALSA sound/pci/atiixp.c:1404: atiixp: codec 2 not available for audio ALSA sound/pci/atiixp.c:1411: atiixp: no codec available ACPI: PCI interrupt for device 0000:00:14.5 disabled normal boot with 2.6.19-rc5 + modified snd-ac97-codec ;(
I don't actually have the hardware, I was just grovelling through the code to see what changed recently. But actually it seems like this sound card didn't use to work with old kernels. > Most recent kernel where this bug did not occur: unknown Marcin, we're missing most of the dmesg output before the module was loaded. Could you post that? You've got that proprietary ATI module as well but that is getting loaded after the errors occur so probably that's not the problem.
Created attachment 9446 [details] dmesg output from boot dmesg output from boot begin to 'single' login (before loading snd-atiixp module)
btw - booted 2.6.12/i386 - card was not working too
See https://bugzilla.novell.com/show_bug.cgi?id=200476 , could you try APIC setup as suggested marcel@hilzinger.hu : ----- I had similar problems with snd_atiixp on several Suse machines (10.0/10.1). Yesterday I could resolve on: I had to change APIC interrupt routing in the BIOS from Disabled to Enabled. So perhaps it's not a ACPI, but an APIC problem. Perhaps booting with the 'noapic' or 'nolapic' options helps. -----
I enabled APIC and ACPI in first day. Today I tried with APIC disabled in BIOS, but still no change. Booted 2.6.19-rc5 with noacpi, noapic, nolapic, pci=biosirq - nothing changed.
You had those APIC messages going on at the end. I've seen those messages before and normally they don't impact performance at all but obviously it's worth while to check. You seem pretty serious about fixing this, try compiling with: CONFIG_SND_DEBUG=y CONFIG_SND_DEBUG_DETECT=y The messages that you are scrolling by are from snd_ac97_mixer() atiixp: codec read timeout (reg 0) #define AC97_RESET 0x00 /* Reset */ atiixp: codec read timeout (reg 3c) #define AC97_EXTENDED_MID 0x3c /* Extended Modem ID */ atiixp: codec read timeout (reg 1c) #define AC97_REC_GAIN 0x1c /* Record Gain */ The ACPI line: > ACPI: PCI interrupt for device 0000:00:14.5 disabled That actually comes from pci_disable_device() in snd_atiixp_create(). The call tree is: pci_disable_device() -> pcibios_disable_device() -> pcibios_disable_irq() -> acpi_pci_irq_disable(). Anyway, compile with debug enabled and post your dmesg again.
Created attachment 9475 [details] dmesg with CONFIG_SND_DEBUG* > You seem pretty serious about fixing this I will get this sound working or will have to buy PCI soundcard (which I want to avoid because I have only one free PCI slot). > CONFIG_SND_DEBUG=y > CONFIG_SND_DEBUG_DETECT=y Both flags were already set - dmesg attached is from 'modprobe snd-atiixp-modem;insmod snd-atiixp.ko-' (module renamed to not full dmesg with errors on boot).
So there are three codecs that it probes for. Codecs 0 and 1 come back as not ready in snd_atiixp_interrupt() and we probe for 2 and it generates all the error messages. I did a google search and it turns out that there are a bunch of windows users having the same problem you are. I wonder if the chip is maybe returning wrong information in snd_atiixp_interrupt(). Just for grins, what happens if you use the attached patch?
Created attachment 9476 [details] Short circuit the proper probing and test all 3 codecs
Created attachment 9477 [details] dmesg with IRQ_HANDLED patch After patch applied I got this in /proc/asound/cards: 0 [IXP ]: ATIIXP - ATI IXP ATI IXP rev 80 with ALC850 at 0xfe029000, irq 17 And sound works :) But I got many APIC errors (they are common on this machine) and driver was eating interrupts so: - my PS/2->USB adapter which I use for mouse was reattached many times - MPlayer with 320x240 DivX few times said that this machine is too slow. /proc/interrupts: CPU0 0: 10907864 <NULL>-edge timer 1: 25931 IO-APIC-edge i8042 8: 0 IO-APIC-edge rtc 9: 0 IO-APIC-fasteoi acpi 12: 3 IO-APIC-edge i8042 14: 224820 IO-APIC-edge libata 15: 236605 IO-APIC-edge libata 17: 21174813 IO-APIC-fasteoi bttv0, fglrx, ATI IXP 19: 2217380 IO-APIC-fasteoi ehci_hcd:usb1, ohci_hcd:usb2, ohci_hcd:usb3 21: 211406 IO-APIC-fasteoi eth0 NMI: 8910 LOC: 10948064 ERR: 663
Booted with 'irqpoll noapic nolapic' and loaded patched driver. With 'cat /dev/urandom > /dev/null' working MPlayer sound output was skipping like I would try to play MP3 on 386DX.
Created attachment 9478 [details] Add a parameter ac97_codec That last patch was just for testing. I've created a new patch that adds a parameter to let you hard code what ac97 codec to use. Add "ac97_codec=0" the snd-atiixp line in /etc/modprobe.conf I've compile tested it only, but I think it should get rid of the crud in dmesg. Don't boot with 'irqpoll noapic nolapic'. It shouldn't be needed.
irqpoll is needed for my network card (it I do not use then sooner or later card die - for example after remove/insert bttv). Booted with 'irqpoll' and then 'modprobe snd-ac97-codec;insmod snd-atiixp.ko ac97_codec=0': Nov 12 23:36:31 localhost kernel: ACPI: PCI Interrupt 0000:00:14.5[B] -> GSI 17 (level, low) -> IRQ 17 Nov 12 23:36:31 localhost kernel: ALSA sound/pci/atiixp.c:575: atiixp: no codec detected! Nov 12 23:36:31 localhost kernel: ACPI: PCI interrupt for device 0000:00:14.5 disabled
Created attachment 9479 [details] Add a parameter ac97_codec [take 2] Found a bug in the other patch. Try the next one. Sooner or later it's got to start working... ;)
Dan, you are great ;) With #9479 patch sound is working: ACPI: PCI Interrupt 0000:00:14.5[B] -> GSI 17 (level, low) -> IRQ 17 MPlayer is able to play video with sync with 'cat /dev/urandom>/dev/null' in background. Now I can listen to radio streams during digging into mail...
http://www.hrw.one.pl/2006/11/13/sound-is-working-on-dfi-rs482/ for those who has same problem.
Great to hear it's working now. But I would check the option rather in snd_atiixp_codec_detect() instead of checking in irq handler. It's much safer. Dan, care to rewrite the patch? If it's confirmed to work, I'll add it to ALSA tree. So, please don't forget to add a description of the new option in Documentation/sound/alsa/ALSA-Configuration.txt and sign-off of the patch, too. Thanks.
Created attachment 9501 [details] Add a parameter ac97_codec [take 3] No problem. I've attached the modified patch. Marcin, you've been a trooper, could you give this one a test?
The patch looks good for manual tests, but I would suggest to add also automatic detection for problematic machines using the subdevice PCI ID. A short notice for syslog informing that a workaround has been activated would be nice, too. It's just idea to improve situation.
#9501 patch also works. lspci -n output for soundcard: 00:14.5 0401: 1002:4370 (rev 80) Subsystem: 15bd:3100 Flags: bus master, 66MHz, slow devsel, latency 64, IRQ 17 Memory at fe029000 (32-bit, non-prefetchable) [size=256] Capabilities: [40] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
Created attachment 9515 [details] Add a parameter ac97_codec [take 4] 15bd:3100 eh? No problem. This patch should detect that automatically so you don't have to specify the codec anymore. If someone else needs to they still can or if you want to force probing then use "ac97_codec=-2".
ACPI: PCI Interrupt 0000:00:14.5[B] -> GSI 17 (level, low) -> IRQ 17 Atiixp quirk for DFI RS482. Forcing codec 0 Thx a lot guys.
Thanks, I included the patch (take4) to ALSA HG/git tree. This shall be merged to the next mm tree.
Installed nightly build from ALSA HG Tree which should fix this problem. Module now load successfully, alsamixer runs fine. But I've got still no sound on my SPDIF. Unmuted all channels. Any suggestions?
toggm, could you compile with CONFIG_SND_DEBUG=y CONFIG_SND_DEBUG_DETECT=y and post your dmesg from the point where it loads the module? Also post the `lspci -n` output for the sound card.
Created attachment 9610 [details] toggm: dmesg Attached output of dmesg and lspci. Couldn't compbile with CONFIG_SND_DEBUG=y because I'm using the newest ALSA HG Tree modules. But compiled with --debug-level=full.
Created attachment 9611 [details] toggm: lscpi toggm: lspci
What happens if you "modprobe snd-atiixp spdif_aclink=0"?
Still no sound on SPDIF. It only deactivates controls in alsamixer.
Got sound working. After a few hours playing with alsamixer settings I found the control adjusting AC97-SPSA. Setting this to zero activated sound on SPDIF.
From mny reading of this bug record, everyone's bugs got fixed. Correct?
Works great for me. Listening to Eric Clapton via Last.fm right now.
ok, thanks - I'll close it. Say Hi to Eric for me ;)