Date: Fri, 25 May 2012 09:25:11 +0200
Message-ID: <s5hehq87meg.wl%tiwai@suse.de>
From: Takashi Iwai <tiwai@suse.de>
To: Tejun Heo <tj@kernel.org>
Cc: Fengguang Wu <fengguang.wu@intel.com>,
        =?UTF-8?B?SsO2cmctVm9sa2Vy?= Peetz <jvpeetz@web.de>,
        linux-kernel@vger.kernel.org
Subject: Re: Linux 3.4 released
In-Reply-To: <20120523202657.GB3933@htj.dyndns.org>
References: <CA+55aFwaobhbBZkE1LTyQJYhk8w8zk-cyOXXuXfPyE=BXzT3PA@mail.gmail.com>
	<4FBBB11D.7020904@web.de>
	<20120522155345.GC14339@google.com>
	<4FBBC461.4060008@web.de>
	<20120522170320.GD14339@google.com>
	<jpglns$1uj$1@dough.gmane.org>
	<CAOS58YPMh_hbJ4a49j4p9H68n8U1LzMUuaxmHx57gVTkmfxF6A@mail.gmail.com>
	<4FBBEDF2.8060803@web.de>
	<20120523182457.GD18143@google.com>
	<4FBD40F4.4090201@web.de>
	<20120523202657.GB3933@htj.dyndns.org>
User-Agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka)
 FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.7 Emacs/23.3
 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2375
Lines: 65

At Wed, 23 May 2012 13:26:57 -0700,
Tejun Heo wrote:
> 
> Cc'ing Takashi.  Hi!

Also Cc'ed Fengguang, who worked on ELD stuff.

> On Wed, May 23, 2012 at 09:56:36PM +0200, Jörg-Volker Peetz wrote:
> > May 23 21:32:33 hostname kernel: XXX delayed_work_timer_fn: cwq
> > (null), fn=hdmi_repoll_eld
> 
> So, we have the winner.
> 
> Takashi, sound/pci/hda/patch_hdmi.c::hdmi_repoll_eld() is causing
> workqueue code dereference %NULL pointer.  It *looks* like something
> is corrupting the work item while it's queued.  It could be a
> workqueue bug but I don't think that's likely - the code has been
> stable for quite some time now.  I glanced through the code and
> nothing stands out.  Does something ring a bell?

I also don't know of this problem.  My initial thought was that the
work struct placed right after sink_eld in struct hdmi_spec_per_pin is
overwritten wrongly by reading some ELD data.  But I failed to spot
out the bug...

Reading back through the thread, the problem seems triggered via usb
video cam.  I wonder how this is connected to the HDMI audio.

To get things straight: does this bug happen even without HDMI, DP or
DVI cable plugged, i.e. only with the laptop without connecting to the
external digital output?


> > (without line-break).
> > 
> > By the way, don't know if this is related, I have a phenomenon with a spurious
> > interrupt with every linux version I've used before on this notebook. Half a
> > minute after starting the system the computer produces approx. 220 lines like
> > 
> > ... kernel: hda-intel: spurious response 0x0:0x0, last cmd=0x170503
> > 
> > Now with 3.4.0, I see an additional message right before (the minute before) the
> > "XXX ..." line:
> > 
> > ...kernel: hda_intel: azx_get_response timeout, switching to single_cmd mode:
> > last cmd=0x003f0900
> 
> These too seem to be for you, Takashi. :)

This means essentially the codec communication got stalled.  This is a
bad signal.  It happens often with a wrong HD-audio verb, but often
with a bad IRQ, whatever.

I'd need alsa-info.sh output (run with --no-upload option) for further
analysis.


thanks,

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