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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 6 Aug 2012 11:25:30 -0700 (PDT)
From:	Hugh Dickins <hughd@...gle.com>
To:	Daniel Vetter <daniel.vetter@...ll.ch>
cc:	Hugh Dickins <hughd@...gle.com>, Takashi Iwai <tiwai@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Chris Wilson <chris@...is-wilson.co.uk>,
	Giacomo Comes <comes@...c.edu>, linux-kernel@...r.kernel.org
Subject: Re: i915 regression on 3.6-rc1: lid blanks screen

On Mon, 6 Aug 2012, Daniel Vetter wrote:
> On Mon, Aug 6, 2012 at 6:21 AM, Hugh Dickins <hughd@...gle.com> wrote:
> > On Sun, 5 Aug 2012, Takashi Iwai wrote:
> >> At Sat, 4 Aug 2012 10:01:13 -0700 (PDT),
> >> Hugh Dickins wrote:
> >> >
> >> > Sorry to report that with 3.6-rc1, closing and opening the lid on
> >> > this ThinkPad T420s leaves the screen blank, and I have to reboot.
> >> >
> >> > Bisection led to this commit, and reverting indeed gets my screen back:
> >> >
> >> > commit 520c41cf2fa029d1e8b923ac2026f96664f17c4b
> >> > Author: Daniel Vetter <daniel.vetter@...ll.ch>
> >> > Date:   Wed Jul 11 16:27:52 2012 +0200
> >> >
> >> >     drm/i915/lvds: ditch ->prepare special case
> > ...
> >>
> >> Hm, it's surprising.
> >>
> >> Could you check whether the counter-part intel_lvds_enable() is
> >> called?  If the prepare callback affects, it must be from the mode
> >> setting (drm_crtc_helper_set_mode()).
> >
> > Yes, I put a dump_stack() in both, and intel_lvds_enable() gets called
> > about 0.28 seconds after the intel_lvds_disable() when I lift the lid;
> > but with no video display until I revert that commit.
> 
> Can you please boot with drm.debug=0xe added to your kernel cmdline,
> reproduce the issue (with the two dump_stack calls added) and then
> attach the full dmesg?

Collected, I'll send it to you both privately in a moment.

> 
> Also a few other things to try: What happens if you do a modeset on
> the LVDS while it's still working, e.g.

In the dmesg, I've only gone to runlevel 3, simply working on the
console without startx.  For these xrandrs to work, I did startx
and used the graphics screen.

> 
> xrandr --outpu LVDS1 --auto --crtc 1

Blanks and restores the screen.

> 
> then switch back to crtc 0 with
> 
> xrandr --outpu LVDS1 --auto --crtc 0

Blanks and restores the screen.

> 
> Would also be interesting to know whether this can resurrect your machine.

Indeed it does: the first (--crtc 1) restores the display from
its blank state after opening the lid, the second (--crtc 0) then
behaves as before, briefly blanking then restoring the display.

> 
> Also, how blank is the screen? I.e. is only the backlight off, but you
> can (dimly) see some screen contents, or is it completely off?

Completely off.

Thanks,
Hugh
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ