linux-kernel - Re: i915 regression on 3.6-rc1: lid blanks screen

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: <alpine.LSU.2.00.1208052113530.1300@eggly.anvils>
Date:	Sun, 5 Aug 2012 21:21:56 -0700 (PDT)
From:	Hugh Dickins <hughd@...gle.com>
To:	Takashi Iwai <tiwai@...e.de>
cc:	Daniel Vetter <daniel.vetter@...ll.ch>,
	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 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.
> > 
> > I understand there's also an nVidia graphics device in here,
> > but I have that configured out, preferring to use the i915:
> > 
> > 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
> > 	Subsystem: Lenovo Device 21d3
> > 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
> > 	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> > 	Latency: 0
> > 	Interrupt: pin A routed to IRQ 41
> > 	Region 0: Memory at f1400000 (64-bit, non-prefetchable) [size=4M]
> > 	Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
> > 	Region 4: I/O ports at 5000 [size=64]
> > 	Expansion ROM at <unassigned> [disabled]
> > 	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
> > 		Address: fee0100c  Data: 41c2
> > 	Capabilities: [d0] Power Management version 2
> > 		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
> > 		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> > 	Capabilities: [a4] PCI Advanced Features
> > 		AFCap: TP+ FLR+
> > 		AFCtrl: FLR-
> > 		AFStatus: TP-
> > 	Kernel driver in use: i915
> > 
> > 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.

Hugh

> 
> 
> Takashi
> 
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c
> > index 49f09a8..e05c0d3 100644
> > --- a/drivers/gpu/drm/i915/intel_lvds.c
> > +++ b/drivers/gpu/drm/i915/intel_lvds.c
> > @@ -409,13 +409,7 @@ static void intel_lvds_prepare(struct drm_encoder *encoder)
> >  {
> >  	struct intel_lvds *intel_lvds = to_intel_lvds(encoder);
> >  
> > -	/*
> > -	 * Prior to Ironlake, we must disable the pipe if we want to adjust
> > -	 * the panel fitter. However at all other times we can just reset
> > -	 * the registers regardless.
> > -	 */
> > -	if (!HAS_PCH_SPLIT(encoder->dev) && intel_lvds->pfit_dirty)
> > -		intel_lvds_disable(intel_lvds);
> > +	intel_lvds_disable(intel_lvds);
> >  }
> >  
> >  static void intel_lvds_commit(struct drm_encoder *encoder)
--
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/