edp backtrace spam on MacBookAir4,1

Daniel Vetter daniel at ffwll.ch
Thu Jun 7 00:21:20 PDT 2012


On Wed, May 30, 2012 at 08:39:13AM -0700, Linus Torvalds wrote:
> On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> >
> > Ok, Chris couldn't reproduce this on his mba. Can you please boot with
> > drm.debug=0xe, reproduce the noise and then attach the full dmesg?
> 
> Hmm. Now *I* can't reproduce it either.
> 
> I have updated my system in the meantime, so maybe this is related to
> that. However, I suspect it's more likely that it's some race
> condition, because when I got it, I got a *lot* of it, but they were
> all very tightly bunched together:
> 
>  [ 1588.996413] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1588.996650] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.000983] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.001225] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.005975] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.006218] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.010980] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.011224] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.015976] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.016211] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.020986] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.021232] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
> 
> ie that's 12 of those warnings (each of them with that huge backtrace
> etc), but they are all within 0.03 seconds of each other. So I suspect
> it needs to hit some particular timing window, and I was just
> (un)lucky.
> 
> Because when I try it now with DRM debugging, I can't hit it. And just
> to make sure, I re-did the test without debugging too (in case the
> debugging would have changed timing), but can't reproduce it that way
> either.

Meh, I've been totally blind. Note to self: Next time around actually look
at the backtrace. And I dunno how that escaped our dear QA that long ...

Below patch should shut this up (and might even fix an edp panel not
getting up again after having been switched off).

Yours, Daniel
---


More information about the dri-devel mailing list