linux-kernel - Re: [git pull] drm for 4.4-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151214071409.76cd05a7@mir>
Date:	Mon, 14 Dec 2015 07:14:09 +0100
From:	Stefan Lippers-Hollmann <s.l-h@....de>
To:	Daniel Vetter <daniel@...ll.ch>
Cc:	Dave Airlie <airlied@...ux.ie>,
	DRI mailing list <dri-devel@...ts.freedesktop.org>,
	linux-kernel@...r.kernel.org,
	Sonika Jindal <sonika.jindal@...el.com>,
	Shashank Sharma <shashank.sharma@...el.com>,
	Rodrigo Vivi <rodrigo.vivi@...el.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>
Subject: Re: [git pull] drm for 4.4-rc1

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@...el.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@...el.com>
> Date:   Fri Nov 27 18:55:29 2015 +0200
> 
>     drm/i915: take a power domain reference while checking the HDMI live status

both 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.

Regards
	Stefan Lippers-Hollmann
Download attachment "dmesg-v4.4-rc4-113-g0bd0f1e-working.gz" of type "application/gzip" (21936 bytes)