Bug 7467

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