On Mon, Dec 14, 2015 at 07:14:09AM +0100, Stefan Lippers-Hollmann wrote:
Hi
On 2015-12-10, Daniel Vetter wrote:
On Thu, Dec 10, 2015 at 04:04:20AM +0100, Stefan Lippers-Hollmann wrote:
On 2015-11-09, Dave Airlie wrote:
[...]
This patch seems to introduce a regression for i915 in Linus' v4.4-rc4-60-g9a0f76f, relative to v4.3 (and 4.3.1), on a sandy-bridge (Intel DH67CL) system with a single HDMI connected monitor (Medion MD20094) attached. Immediately after the modeswitch, the monitor switches off and stays off. Nothing catches my eyes in dmesg or Xorg.0.log, but bisecting the issue points me at:
237ed86c693d8a8e4db476976aeb30df4deac74b is the first bad commit commit 237ed86c693d8a8e4db476976aeb30df4deac74b Author: Sonika Jindal sonika.jindal@intel.com Date: Tue Sep 15 09:44:20 2015 +0530
drm/i915: Check live status before reading edid[...]
This is strange, after connecting a different monitor (Fujitsu-Siemens Scaleoview D19-1) as a second screen via DVI, both monitors came up fine and even after removing it (and reverting everything to the status quo ante), this HDMI connected Medion MD20094 monitor continues to work on the previously broken sandy-bridge DH67CL mainboard. Despite this problem being 100% reproducable and bisectable before, including multiple power cycles and replacing the HDMI cable, I have not been able to reproduce the issue again.
A few things to test:
- How does that screen fare on a working machine? Would tell us if the issue is with the sink or the source.
It is working fine on a Baytrail-D (ASRock Q1900DC-ITX) and an ivy-bridge (Gigabyte GA-H77M-D3H r1.1) system - and now on the previously affected sandy-bridge system (Intel DH67CL) as well.
- Please boot up with drm.debug=0xe on a working and broken kernel, grab dmesg for both.
dmesg-v4.4-rc4-113-g0bd0f1e-working.gz is attached, unfortunately I'm no longer able to reproduce the previous failure (tested with easy of the bisection steps, identical kernel binaries as before, and v4.4-rc5 as well), so I can't provide a broken trace.
- Extending the timeout magic might be worth a shot like in the below patch. Crank up retry if it doesn't help.
[...]
I can only imagine that it was right beyond the brink of the timeout before and something had a lasting, but probably subtile, effect on the timing after temporarily connecting the second screen; it is working now.
On 2015-12-10, Jani Nikula wrote: [...]
The very first thing to do is to ensure you've tried v4.4-rc4, which contains
I tested both plain v4.4-rc4 and v4.4-rc4-60-g9a0f76f
commit 0f5a9be15797f78c9a34e432f26c796165b6e49a Author: Imre Deak imre.deak@intel.com Date: Fri Nov 27 18:55:29 2015 +0200
drm/i915: take a power domain reference while checking the HDMI live statusboth containing this patch.
Thanks a lot and sorry for your trouble, I'll report back if anything changes - or if I can reproduce the problem again.
Ah no worries, this happens fairly often ;-) Could be the cable had a bad day or something like that. Also someone from intel noticed that the delay isn't quite working like it should (we don't do the full 3x10ms delay), patch for that should go to upstream hopefuly soon.
Anyway, thanks for reporting.
Cheers, Daniel