Re: [Intel-gfx] [BUG?] 3.16-rc6 ... at drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()

[Imre Deak]

On Thu, 2014-07-31 at 23:47 +0200, Ian Kumlien wrote:
> On tor, 2014-07-31 at 14:39 +0300, Imre Deak wrote:
> > On Wed, 2014-07-30 at 22:52 +0200, Ian Kumlien wrote:
> > > Sorry for the delay, it's been damned hot - vacation is over and
> > > overtime has been all the rage at work...
> > 
> > No problem, thanks for the feedback.
> > 
> > > On fre, 2014-07-25 at 12:28 +0300, Imre Deak wrote:
> > > > On Thu, 2014-07-24 at 01:33 +0200, Ian Kumlien wrote:
> > > > > Try four, now including CC lists for the intel driver...
> > > > 
> > > > Could you give a try to the 2 patches at:
> > > > https://patchwork.kernel.org/patch/4437061/
> > > 
> > > Didn't quite get that it was two separate patches at first, but when i
> > > did i also spotted a v2 of the patch set.
> > > 
> > > I applied:
> > > https://patchwork.kernel.org/patch/4648961/
> > > https://patchwork.kernel.org/patch/4648951/
> > > 
> > > On to 3.16-rc7 (there was some fuzz but it applied fine)
> > > 
> > > I didn't see any OOPS:es (didn't scroll around too much) but otoh the
> > > screen never turned off? (it's one of those silly mac things, the apple
> > > is still lit) and the machine doesn't "suspend/sleep" anymore.
> > > 
> > > AFAIR it does, after some coaxing, on the unpatched kernel (ie, not the
> > > first time but the second time i turn down the lid, i tried three times
> > > and play:ed with brightness as i assume you can see in the log)
> > 
> > Hm, I can't see how these patches could prevent system suspend. Also
> > according to the dmesg you sent suspend didn't even start, so I guess
> > you're seeing a separate issue. Maybe the lid notification isn't
> > properly handled, but I can't really help tracking that down.
> 
> It works without the drm.debug=14 so it might be something else... 
> 
> > In any case to reproduce the particular bug in question (or see if the
> > fix works) you need to get the machine to suspend/resume somehow. One
> > way is to 'echo mem > /sys/power/state' as root and resume by pressing
> > power button or similar; could you still try this, again sending the
> > dmesg?
> 
> You'll find it attached ;)

Ok, I see the trace of suspend/resume now, but the bug has vanished.. I
can't see the WARN backtrace in your original report, nor the debug
message from the above fix, that would indicate that it had fixed
anything ("VDD left on by BIOS, adjusting state tracking"). So I'm a bit
lost, I would need a full dmesg with either the WARN or this debug
message.

--Imre

Attachment: signature.asc
Description: This is a digitally signed message part