[Bug 71701] Regression, Dual-Head, i915 mode-setting driver, "pipe B stuck"

[bugzilla-daemon at bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=71701

--- Comment #6 from Kris Karas <bugs-a13 at moonlit-rail.com> ---
Please nix comment #4.
It turns out that when booting 3.13.6, the BUG/WARNING only shows up 86% of the
time.  And when the warning is issued, the screen may still work one out of
every few times.  As luck would have it, when I booted after backing out the
commit in comment #4, the bug/warning was not issued and the screen worked;
luckier still, rebooting once more to confirm resulted in the screen working
yet again (though the bug/warning actually was issued, I just didn't see it).

Commit 05524f5b61c3c15859477a2165cff81e3d682743 is not at fault.
Chris Wilson's test patch had no effect; failure rate with his patch was 43 out
of 50 boots, coincidentally identical to vanilla 3.13.6 (86 failures out of 100
boots).

The REAL problem commit is 87c3c227f580e2965feceae5f8973e9a38644963
                          "drm/i915/dp: add native aux defer retry limit"
Backing that out, I get 50 good boots out of 50 tries, or 100%.

Narrowing it down, I alternately applied the first and second halves of the
patch (turning for(;;){} into for(retry=0;retry<7;++retry){}) and the culprit
is the first half, the function intel_dp_aux_native_write()
Patching the second function, intel_dp_aux_native_read(), does not trigger the
bug.

The bug is that we've gone from an infinite loop waiting for
AUX_NATIVE_REPLY_ACK to be set in intel_dp, to a paltry 3500 microseconds.  I
don't know what the hardware does with this bit, so I'm guessing into the wind
here. If the "ack" awaits a status change in the displayport hardware, and the
hardware is connected to a possibly-sleeping monitor, does the ACK wait for the
monitor to wake up or communicate in some way?  If so, the timeout is orders of
magnitude short.

-- 
You are receiving this mail because:
You are on the CC list for the bug.