[lkml]   [2012]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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 output (run with --no-upload option) for further


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2012-05-25 10:01    [W:0.040 / U:1.176 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site