After a suspend/resume cycle, my power consumption usually
goes up by over a watt. I think this is due to i915, because of an
experiment I did:
1. Boot with modesetting off into single user mode.
2. Suspend and resume
3. Reload i915 with modesetting on. Power consumption is low.
4. Suspend and resume. Power consumption is high.
5. Unbind and rebind i915. Power consumption is high.
6. Suspend. System hangs (seperate bug, I guess).
I get similar results if I boot single user with modesetting on: power
consumption is low, becomes high after suspend/resume, and goes low
again after rebinding i915.
This is on 2.6.32-rc1 + a little (i.e. 84d88d5d4e from Linus' tree
plus an ext4 fix). I'm having trouble reproducing any of this on
I'm using a Lenovo X200s.
Could you try again on the for-linus branch of my kernel tree? It's got a fix from jbarnes to restore FBC setup on resume.
On a single try using 58a27471d00dc09945cbcfbbc5cbcdcd3c28211d (from anholt/drm-inte for-linus) I couldn't reproduce the bug. Power was 6.7 watts after resume, which is pretty good.
(Oddly enough, it was 7 watts before suspend, but maybe I just didn't wait long enough for it to settle.)
I'm a bit surprised this had any effect, since I have a GM45 and this patch wasn't applied:
So are you still seeing this with the latest bits? We did find some issues with the self refresh programming for 945GM, but that shouldn't affect your GM45 platform... I'll see if I can reproduce on my x200.
I still see this bug on 18.104.22.168 and on a hacked-up hybrid that's 22.214.171.124 with include/drm and drivers/gpu/drm yanked from a merge of dd59f6c and c566ec4 (i.e. Linus' tree from today with drm-next from today). I can't usefully test on a real 2.6.33-rc1 tree because I can't get it to suspend without freezing.
Note that I've never been able to reproduce this reliably on demand. It usually seems to happen when I'm doing something else, then I suspend, then I come back awhile later and resume. I think that 2.6.33's driver has less of a difference between the good and bad states, but I won't swear to that (maybe it's due to RC6 support).
Any update on this Andy? I guess you've been able to get 2.6.33-rc working at least a little (aside from the hotplug/sluggishness issue), have you been able to reproduce the power problem?
(In reply to comment #5)
> Any update on this Andy? I guess you've been able to get 2.6.33-rc working at
> least a little (aside from the hotplug/sluggishness issue), have you been able
> to reproduce the power problem?
I haven't tested it much on 2.6.33-rcX because the hotplug bug kept my uptime from being high enough. A single test with a kernel that has HDMI, DP, and SDVO patched out didn't show the problem, but that isn't a great test and it would mask the bug if the problem were in that code.
I'll keep you posted.
optimistically marking this as fixed
on Mar 24, 2017 at 04:21:17.
(provided by the Example extension).