linux-kernel - Re: audio: hda_intel azx_get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <s5htzft5n55.wl%tiwai@suse.de>
Date:	Mon, 16 Jun 2008 19:02:14 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	"Justin Mattock" <justinmattock@...il.com>
Cc:	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: audio: hda_intel azx_get_response timeout

At Mon, 16 Jun 2008 16:57:07 +0000,
Justin Mattock wrote:
> 
> On Mon, Jun 16, 2008 at 4:44 PM, Takashi Iwai <tiwai@...e.de> wrote:
> > At Sun, 15 Jun 2008 17:43:01 +0000,
> > Justin Mattock wrote:
> >>
> >> I've noticed this([   14.630815] hda_intel: azx_get_response timeout,
> >> switching to polling mode: last cmd=0x00bf1c00
> >>  with 2.6.26-rc2 or 3, when connecting external speakers to listen to
> >> music(keep in mind this was only once),
> >> Now with kernel 2.6.26-rc5 and 6 I'm seeing this pop up every so
> >> often,(seen this three times now). attached is dmesg of the message.
> >> If I see anything else I'll send a post.
> >
> > Well, this is no fatal error but a warning, but of course better
> > without it.
> >
> > It might be related with the position that runs.  I see the clock
> > source tsc unstable message right after it, so the timeout check could
> > be unreliable...
> >
> >
> > Takashi
> >
> 
> Hmmm, Well, whenever this goes off, if and when it decides, I'm not
> hearing anything different
> with the sound. Seems like a minor issue nothing to intense.

There will be no difference in the sound quality regarding this
indeed.  In the polling mode, the driver tries to poll the codec
receive buffer while it waits for the IRQ ack in the default
(non-polling) mode.  So, you can need a few more cycles for polling,
but it doesn't influence on the real performance at all.

The switch to the polling mode occurs for some hardwares that don't
issue the IRQ properly in the timely manner by any reason.  Then in
your report, I thought it might be rather the time source issue.
Well, just a wild guess, though.


Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/