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. 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? Thanks, Imre
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
