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] [day] [month] [year] [list]

Message-ID: <20151214083012.GB3189@phenom.ffwll.local>
Date:	Mon, 14 Dec 2015 09:30:12 +0100
From:	Daniel Vetter <daniel@...ll.ch>
To:	Stefan Lippers-Hollmann <s.l-h@....de>
Cc:	Daniel Vetter <daniel@...ll.ch>, 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

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

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/