Messages in this thread |  | | | Date | Fri, 25 May 2012 09:25:11 +0200 | | From | Takashi Iwai <> | | Subject | Re: Linux 3.4 released |
| |
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/
|  |