From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756733AbYFPRCX (ORCPT ); Mon, 16 Jun 2008 13:02:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753971AbYFPRCQ (ORCPT ); Mon, 16 Jun 2008 13:02:16 -0400 Received: from mx1.suse.de ([195.135.220.2]:43724 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752987AbYFPRCP (ORCPT ); Mon, 16 Jun 2008 13:02:15 -0400 Date: Mon, 16 Jun 2008 19:02:14 +0200 Message-ID: From: Takashi Iwai To: "Justin Mattock" Cc: "Linux Kernel Mailing List" Subject: Re: audio: hda_intel azx_get_response timeout In-Reply-To: References: User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 MULE XEmacs/21.5 (beta28) (fuki) (x86_64-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At Mon, 16 Jun 2008 16:57:07 +0000, Justin Mattock wrote: > > On Mon, Jun 16, 2008 at 4:44 PM, Takashi Iwai 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