Re: 2.6.18: hda_intel: azx_get_response timeout, switching to single_cmd mode...

22 Aufrufe
Direkt zur ersten ungelesenen Nachricht

Pavel Machek

ungelesen,
25.09.2006, 16:30:3225.09.06
an
Hi!

> I have a ThinkPad X60 which uses the Intel 82801G HDA
> audio chip. This used to work for me, but lately
> (sometime during 2.6.18-rcX series) it stopped working -
> programs trying to use it tend to just block forever
> waiting for /dev/dsp.

I have x60 here,

> The only obvious symptom is:
>
> hda_intel: azx_get_response timeout, switching to
> single_cmd mode...
>

sometimes see this message, too, and sound more or less works for me.
(Using alsa interface, mplayer works ok. mpg123 does not work).


--
Thanks for all the (sleeping) penguins.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jeremy Fitzhardinge

ungelesen,
25.09.2006, 21:20:0525.09.06
an
Pavel Machek wrote:
> sometimes see this message, too, and sound more or less works for me.
> (Using alsa interface, mplayer works ok. mpg123 does not work).
>

That's how it used to be for me, but not any more.

J

Michael Clark

ungelesen,
25.09.2006, 21:20:0425.09.06
an
Pavel Machek wrote:
> Hi!
>
>
>> I have a ThinkPad X60 which uses the Intel 82801G HDA
>> audio chip. This used to work for me, but lately
>> (sometime during 2.6.18-rcX series) it stopped working -
>> programs trying to use it tend to just block forever
>> waiting for /dev/dsp.
>>
>
> I have x60 here,
>
>
>> The only obvious symptom is:
>>
>> hda_intel: azx_get_response timeout, switching to
>> single_cmd mode...
>>
>>

I got similar kernel message relating to an azx_get_response timeout
with an 82801G HDA audio running Debian kernel 2.6.16-2 (happened during
suspend to ram IIRC) - after replacing kernel alsa with alsa-source
1.0.12 (24 Aug release) the problem went away (in addition to making
sound come out when it didn't before).

Not sure if this info helps but trying the alsa-project release and
seeing if that works may help identify what needs fixing in mainline
hda_intel.

~mc

Takashi Iwai

ungelesen,
26.09.2006, 06:20:0826.09.06
an
At Mon, 25 Sep 2006 12:58:08 -0700,

Jeremy Fitzhardinge wrote:
>
> I have a ThinkPad X60 which uses the Intel 82801G HDA audio chip. This
> used to work for me, but lately (sometime during 2.6.18-rcX series) it
> stopped working - programs trying to use it tend to just block forever
> waiting for /dev/dsp.
>
> The only obvious symptom is:
>
> hda_intel: azx_get_response timeout, switching to single_cmd mode...
>
> appearing in the kernel log when booting.
>

There is no big change relevant to TP X60 during 2.6.18rc, so I don't
think it's a regression in the hd-audio driver code.

> Details attached. The dmesg output is for the FC6 distro kernel
> 2.6.18-1.2689.fc6PAE, but I see the same symptoms with 2.6.18-mm1.

You must see difference with mm1 (suppose that mm1 already includes
the latest ALSA patches). When the CORB/RIRB interrupt gets broken,
the driver first switches to poling mode, then single_cmd mode as
fallback.

Also, try disable_msi=1 option for mm1. MSI seems broken on some
systems.


Takashi

Randy Dunlap

ungelesen,
26.09.2006, 11:40:1226.09.06
an
On Tue, 26 Sep 2006 12:16:33 +0200 Takashi Iwai wrote:

> At Mon, 25 Sep 2006 12:58:08 -0700,
> Jeremy Fitzhardinge wrote:
> >
> > I have a ThinkPad X60 which uses the Intel 82801G HDA audio chip. This
> > used to work for me, but lately (sometime during 2.6.18-rcX series) it
> > stopped working - programs trying to use it tend to just block forever
> > waiting for /dev/dsp.
> >
> > The only obvious symptom is:
> >
> > hda_intel: azx_get_response timeout, switching to single_cmd mode...
> >
> > appearing in the kernel log when booting.
> >
>
> There is no big change relevant to TP X60 during 2.6.18rc, so I don't
> think it's a regression in the hd-audio driver code.
>
> > Details attached. The dmesg output is for the FC6 distro kernel
> > 2.6.18-1.2689.fc6PAE, but I see the same symptoms with 2.6.18-mm1.
>
> You must see difference with mm1 (suppose that mm1 already includes
> the latest ALSA patches). When the CORB/RIRB interrupt gets broken,
> the driver first switches to poling mode, then single_cmd mode as
> fallback.
>
> Also, try disable_msi=1 option for mm1. MSI seems broken on some
> systems.

is that "pci=nomsi" ?

---
~Randy

Takashi Iwai

ungelesen,
26.09.2006, 11:50:0426.09.06
an
At Tue, 26 Sep 2006 08:37:20 -0700,

Randy Dunlap wrote:
>
> On Tue, 26 Sep 2006 12:16:33 +0200 Takashi Iwai wrote:
>
> > At Mon, 25 Sep 2006 12:58:08 -0700,
> > Jeremy Fitzhardinge wrote:
> > >
> > > I have a ThinkPad X60 which uses the Intel 82801G HDA audio chip. This
> > > used to work for me, but lately (sometime during 2.6.18-rcX series) it
> > > stopped working - programs trying to use it tend to just block forever
> > > waiting for /dev/dsp.
> > >
> > > The only obvious symptom is:
> > >
> > > hda_intel: azx_get_response timeout, switching to single_cmd mode...
> > >
> > > appearing in the kernel log when booting.
> > >
> >
> > There is no big change relevant to TP X60 during 2.6.18rc, so I don't
> > think it's a regression in the hd-audio driver code.
> >
> > > Details attached. The dmesg output is for the FC6 distro kernel
> > > 2.6.18-1.2689.fc6PAE, but I see the same symptoms with 2.6.18-mm1.
> >
> > You must see difference with mm1 (suppose that mm1 already includes
> > the latest ALSA patches). When the CORB/RIRB interrupt gets broken,
> > the driver first switches to poling mode, then single_cmd mode as
> > fallback.
> >
> > Also, try disable_msi=1 option for mm1. MSI seems broken on some
> > systems.
>
> is that "pci=nomsi" ?

No, snd-hda-intel driver has a new module option "disable_msi" to
disable MSI support on that driver. As default, it's off, i.e. MSI is
enabled if available. (Well, I feel it's better to rename it
enable_msi and set on as default...)

Sorry for unclear text.


Takashi

Randy Dunlap

ungelesen,
26.09.2006, 12:00:1826.09.06
an

ugh. We shouldn't have drivers with such options IMO.
I have seen/used MSI for ethernet, SATA, and audio.
It either works for all of them or none of them AFAIK.

Why do you think that it should not just be a global system option/flag?

---
~Randy

Takashi Iwai

ungelesen,
26.09.2006, 12:20:0726.09.06
an
At Tue, 26 Sep 2006 08:56:11 -0700,

Heh, you're a lucky guy :)

> It either works for all of them or none of them AFAIK.
>
> Why do you think that it should not just be a global system option/flag?

In the ealier version, we didn't call pci_enable_msi() in the driver
while the newer version does unless you pass disable_msi=1 option.
Thus, this option means to behave like the old driver. This makes
much easier to find out a regression than a global boot option
affecting all subsytems.


Takashi

Andrew Morton

ungelesen,
26.09.2006, 12:40:0926.09.06
an
On Tue, 26 Sep 2006 12:16:33 +0200
Takashi Iwai <ti...@suse.de> wrote:

> You must see difference with mm1 (suppose that mm1 already includes
> the latest ALSA patches).

No, the alsa tree was accidentally omitted from 2.6.18-mm1, sorry.

Takashi Iwai

ungelesen,
26.09.2006, 12:50:1026.09.06
an
At Tue, 26 Sep 2006 09:31:42 -0700,

Andrew Morton wrote:
>
> On Tue, 26 Sep 2006 12:16:33 +0200
> Takashi Iwai <ti...@suse.de> wrote:
>
> > You must see difference with mm1 (suppose that mm1 already includes
> > the latest ALSA patches).
>
> No, the alsa tree was accidentally omitted from 2.6.18-mm1, sorry.

Ah, that makes sense. Thanks for notice.


Takashi

Jeremy Fitzhardinge

ungelesen,
01.10.2006, 02:10:0701.10.06
an
Takashi Iwai wrote:
> You must see difference with mm1 (suppose that mm1 already includes
> the latest ALSA patches). When the CORB/RIRB interrupt gets broken,
> the driver first switches to poling mode, then single_cmd mode as
> fallback.
>

I tried -mm2, and I'm seeing the same problem.

> Also, try disable_msi=1 option for mm1. MSI seems broken on some
> systems.
>

This made no difference.

J

Takashi Iwai

ungelesen,
04.10.2006, 05:30:0904.10.06
an
At Sat, 30 Sep 2006 23:03:08 -0700,

Jeremy Fitzhardinge wrote:
>
> Takashi Iwai wrote:
> > You must see difference with mm1 (suppose that mm1 already includes
> > the latest ALSA patches). When the CORB/RIRB interrupt gets broken,
> > the driver first switches to poling mode, then single_cmd mode as
> > fallback.
> >
>
> I tried -mm2, and I'm seeing the same problem.

At least, you have to see a different kernel message after the
patch... Could you confirm it?


Takashi

Tomasz Torcz

ungelesen,
04.10.2006, 10:00:2804.10.06
an
On Mon, Sep 25, 2006 at 12:58:08PM -0700, Jeremy Fitzhardinge wrote:
> I have a ThinkPad X60 which uses the Intel 82801G HDA audio chip. This
> used to work for me, but lately (sometime during 2.6.18-rcX series) it
> stopped working - programs trying to use it tend to just block forever
> waiting for /dev/dsp.
>
> The only obvious symptom is:
>
> hda_intel: azx_get_response timeout, switching to single_cmd mode...
>
> appearing in the kernel log when booting.


Just a blind shot -- do you have modem enabled in BIOS? Sometimes
disabling (hiding) modem breaks sound.

--
Tomasz Torcz To co nierealne -- tutaj jest normalne.
zdzichu@irc.-nie.spam-.pl Ziomale na życie mają tu patenty specjalne.

Jeremy Fitzhardinge

ungelesen,
04.10.2006, 11:20:0804.10.06
an
Tomasz Torcz wrote:
> Just a blind shot -- do you have modem enabled in BIOS? Sometimes
> disabling (hiding) modem breaks sound.
>

Good suggestion. It might be disabled; I'll switch it around next time
I reboot.

J

Jeremy Fitzhardinge

ungelesen,
04.10.2006, 11:20:1204.10.06
an
Takashi Iwai wrote:
> At least, you have to see a different kernel message after the
> patch... Could you confirm it?
>

No, it looks like the same message as ever:

hda_intel: azx_get_response timeout, switching to polling mode...


hda_intel: azx_get_response timeout, switching to single_cmd mode...


This is with -mm3.

J

Takashi Iwai

ungelesen,
04.10.2006, 11:40:1204.10.06
an
At Wed, 04 Oct 2006 08:16:17 -0700,

Jeremy Fitzhardinge wrote:
>
> Takashi Iwai wrote:
> > At least, you have to see a different kernel message after the
> > patch... Could you confirm it?
> >
>
> No, it looks like the same message as ever:
>
> hda_intel: azx_get_response timeout, switching to polling mode...

This is a new message. There was no poling mode on 2.6.18.

> hda_intel: azx_get_response timeout, switching to single_cmd mode...

So, this looks like that the CORB/RIRB register mapping is actually
broken...


Takashi

Takashi Iwai

ungelesen,
04.10.2006, 15:10:1504.10.06
an
At Wed, 04 Oct 2006 08:16:17 -0700,
Jeremy Fitzhardinge wrote:
>
> Takashi Iwai wrote:
> > At least, you have to see a different kernel message after the
> > patch... Could you confirm it?
> >
>
> No, it looks like the same message as ever:
>
> hda_intel: azx_get_response timeout, switching to polling mode...
> hda_intel: azx_get_response timeout, switching to single_cmd mode...

A counter of RIRB pending commands could overflow the size of RIRB
when a bunch of commands are sent but not synced. This may lead to
the azx_get_response error, theoretically.

Could you apply the patch below and check what values are shown there?


thanks,

Takashi

diff -r 4963791e6192 sound/pci/hda/hda_intel.c
--- a/sound/pci/hda/hda_intel.c Wed Oct 04 18:38:16 2006 +0200
+++ b/sound/pci/hda/hda_intel.c Wed Oct 04 20:59:57 2006 +0200
@@ -325,6 +325,7 @@ struct azx {
/* CORB/RIRB */
struct azx_rb corb;
struct azx_rb rirb;
+ int max_rirb_cmds;

/* BDL, CORB/RIRB and position buffers */
struct snd_dma_buffer bdl;
@@ -480,6 +481,8 @@ static int azx_corb_send_cmd(struct hda_

spin_lock_irq(&chip->reg_lock);
chip->rirb.cmds++;
+ if (chip->rirb.cmds > chip->max_rirb_cmds)
+ chip->max_rirb_cmds = chip->rirb.cmds;
chip->corb.buf[wp] = cpu_to_le32(val);
azx_writel(chip, CORBWP, wp);
spin_unlock_irq(&chip->reg_lock);
@@ -538,12 +541,16 @@ static unsigned int azx_rirb_get_respons
if (!chip->polling_mode) {
snd_printk(KERN_WARNING "hda_intel: azx_get_response timeout, "
"switching to polling mode...\n");
+ snd_printk(KERN_WARNING " RIRB pending = %d, peak = %d\n",
+ chip->rirb.cmds, chip->max_rirb_cmds);
chip->polling_mode = 1;
goto again;
}

snd_printk(KERN_ERR "hda_intel: azx_get_response timeout, "
"switching to single_cmd mode...\n");
+ snd_printk(KERN_ERR " RIRB pending = %d, peak = %d\n",
+ chip->rirb.cmds, chip->max_rirb_cmds);
chip->rirb.rp = azx_readb(chip, RIRBWP);
chip->rirb.cmds = 0;
/* switch to single_cmd mode */

Jeremy Fitzhardinge

ungelesen,
04.10.2006, 16:10:1104.10.06
an
Takashi Iwai wrote:
> A counter of RIRB pending commands could overflow the size of RIRB
> when a bunch of commands are sent but not synced. This may lead to
> the azx_get_response error, theoretically.
>
> Could you apply the patch below and check what values are shown there?
>
I'll try it, but I re-enabled the modem in the bios, and I no longer get
this message and it appears to work (there seems to be a secondary
problem that the volume hotkeys have stopped working, but I suspect
that's more ACPI-related).

J

Takashi Iwai

ungelesen,
05.10.2006, 06:10:1105.10.06
an
At Wed, 04 Oct 2006 13:07:56 -0700,

Jeremy Fitzhardinge wrote:
>
> Takashi Iwai wrote:
> > A counter of RIRB pending commands could overflow the size of RIRB
> > when a bunch of commands are sent but not synced. This may lead to
> > the azx_get_response error, theoretically.
> >
> > Could you apply the patch below and check what values are shown there?
> >
> I'll try it, but I re-enabled the modem in the bios, and I no longer get
> this message and it appears to work (there seems to be a secondary
> problem that the volume hotkeys have stopped working, but I suspect
> that's more ACPI-related).

Ah, that's good to hear.

Is the modem also HD-audio modem? If so, you have two codec#* files
in /proc/asound/card0.


Takashi

Shai Peretz

ungelesen,
28.10.2006, 02:10:0528.10.06
an
Jeremy Fitzhardinge <jeremy <at> goop.org> writes:

>
> Takashi Iwai wrote:
> > You must see difference with mm1 (suppose that mm1 already includes
> > the latest ALSA patches). When the CORB/RIRB interrupt gets broken,
> > the driver first switches to poling mode, then single_cmd mode as
> > fallback.
> >
>
> I tried -mm2, and I'm seeing the same problem.
>
> > Also, try disable_msi=1 option for mm1. MSI seems broken on some
> > systems.
> >
>
> This made no difference.
>
> J
>

> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>

Hi,

I am trying to fight the same issue for few weeks now, with no progress.
under windows sound works fine, so seems like no hardware issue.
under ubuntu 6.10, with latest alsa drivers, I get the message above.
seems like the kernel only see the modem part of the sound card, and not the
other part.
on my system, I can't disable/enable the modem in the bios, only the whole sound
card.

Any idea what to look for next?

Thanks, Shai.

Allen antworten
Dem Autor antworten
Weiterleiten
0 neue Nachrichten