flicker-free suspend/resume on Intel [LWN.net]

flicker-free suspend/resume on Intel

Posted Mar 5, 2013 23:23 UTC (Tue) by sebas (guest, #51660)
Parent article: The conclusion of the 3.9 merge window

I've read that it was planned that flicker-free suspend and resume (i.e. no vt switching for S3) for the Intel KMS driver was planned for this release. Short of going through huge git log, does anybody know off-hand if this change-set made it in?

to post comments

flicker-free suspend/resume on Intel

Posted Mar 6, 2013 0:42 UTC (Wed) by marduk (guest, #3831) [Link] (1 responses)

It might be in 3.9-rc1 already. I didn't see any vt switching when resuming from suspend (but I never noticed it before either)

flicker-free suspend/resume on Intel

Posted Mar 6, 2013 11:44 UTC (Wed) by blackwood (guest, #44174) [Link]

Nope, missed the 3.9 cycle. Originally I've merged the core pm/fbdev patches for 3.9, but due to too much config madness and broken compilations I've taken them out again. The drm/i915 part itself wasn't ready in time, we still have outstanding issues. Should all land in 3.10.

flicker-free suspend/resume on Intel

Posted Mar 6, 2013 1:26 UTC (Wed) by neilbrown (subscriber, #359) [Link]

Well if you look in kernel/power/suspend.c, in suspend_prepare(), you can see an unconditional call to pm_prepare_console(), and in kernel/power/console.c pm_prepare_console() always calls vt_move_to_console(SUSPEND_CONSOLE, 1), where
#define SUSPEND_CONSOLE (MAX_NR_CONSOLES-1)

This will always switch console unless disable_vt_switch is set, and that only gets set by a call to pm_set_vt_switch(0).

This is only called by drivers/video/geode/gxfb_core.c and drivers/video/geode/gxfb_core.c, which defaults it to 0 unless it is set by a module parameter:

module_param(vt_switch, int, 0);
MODULE_PARM_DESC(vt_switch, "enable VT switch during suspend/resume");

So it looks like, with 3.9-rc1, you always get a vt switch at suspend/resume unless you have a GEODE video controller.

(note to self: I really should use that pm_set_vt_switch() call for my omap3 display on the GTA04 instead of commenting out the call to pm_prepare_console())

flicker-free suspend/resume on Intel

Posted Mar 6, 2013 1:30 UTC (Wed) by Tobu (subscriber, #24111) [Link] (2 responses)

I don't use it myself, but Phoronix mentioned that this merge has part of intel's "fastboot" work, which seems to be about reusing bios-allocated frame buffers.

flicker-free suspend/resume on Intel

Posted Mar 6, 2013 1:37 UTC (Wed) by Tobu (subscriber, #24111) [Link] (1 responses)

Also, here is airlied's pull request. It doesn't name fastboot, but does give a shootout to “the worst news site ever”, the one I've just linked to :P

flicker-free suspend/resume on Intel

Posted Mar 6, 2013 11:47 UTC (Wed) by blackwood (guest, #44174) [Link]

Getting fastboot merged is a long road, we've pulled in preparatory infrastructure since 3.7. Currently I'm optimistic that 3.10 will have something which can actually avoid the initial modeset in some configurations. But there are still a lot of loose pieces to nail down.

flicker-free suspend/resume on Intel

Posted Mar 7, 2013 13:12 UTC (Thu) by sebas (guest, #51660) [Link] (9 responses)

Thanks all for the answers, that's exactly what I wanted to know.

Looking forward to flicker-free suspend/resume. Because I do that approximately a 100 times more often than rebooting, so not sure why everybody cares so much about flicker-free boot, with suspend states working stable and fast.I also hope to get a nice speedup from this, as the vt switch takes a long time here and is quite blocking.

Now if I only could convince networkmanager to not drop the wifi connection purposefully, on suspend/resume, because that's apparently not necessary anymore with this nice ultrabook hardware. Using ifup/ifdown, it does not and is immediately online. Did anybody try that?

flicker-free suspend/resume on Intel

Posted Mar 7, 2013 14:03 UTC (Thu) by johill (subscriber, #25196) [Link] (8 responses)

The "immediately" online behaviour isn't really immediate, you will typically have been disconnected from the AP. In fact, this disconnection is now going to be enforced for 3.10 because the other behaviour doesn't gain a whole lot (you still need to reconnect etc.) and trying to keep the connection causes a huge amount of issues, particularly with USB hardware (that can be unplugged while suspended.)

The "ultrabook" behaviour you refer to can be achieved with WoWLAN (http://wireless.kernel.org/en/users/Documentation/WoWLAN) and network scanning offload (while in suspend), but this doesn't exist in Linux yet.

However, a much easier solution could be implemented in NetworkManager: instead of scanning on all channels when resuming, it could scan just the channel that it was previously connected on. If that finds the previously connected AP, it would be able to reconnect almost immediately (delay of less than half a second), vs. a full scan that can take up to 10-15 seconds. This should be a fairly simple NetworkManager change.

flicker-free suspend/resume on Intel

Posted Mar 7, 2013 17:18 UTC (Thu) by raven667 (guest, #5198) [Link] (7 responses)

It's also not as if this kind of problem is unique to Linux or NetworkManager, I experience very similar behavior on my MacOSX laptop when resuming from suspend, so this is a common problem with wireless. The stated solution probably won't speed up connection when changing location but keeping the same SSID as you will likely be connecting to a different AP on a different channel and it'll have to scan anyway.

flicker-free suspend/resume on Intel

Posted Mar 7, 2013 20:39 UTC (Thu) by johill (subscriber, #25196) [Link] (2 responses)

Well, yes. Although you could scan the channels in the right order, i.e. the ones that you'd expect the same network (SSID) on first. Say your corporate installation -- it's probably only going to use a handful of channels (1,6,11,36,149 or so), so if you know from "experience" that (almost) all of the APs for the network are there, you can scan those first.

But ultimately you're right, in the general case you have to scan all channels and that simply takes a while. It shouldn't be more than a few seconds since you're not connected; here it takes ~3.5 seconds to scan all the channels my card supports, but I know that it can be (much) slower depending on the device.

flicker-free suspend/resume on Intel

Posted Mar 7, 2013 23:25 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

well, you should first check the channel you were last using, and then do the normal scan you would do if someone just gave the SSID and told you to connect to it.

flicker-free suspend/resume on Intel

Posted Mar 8, 2013 0:10 UTC (Fri) by johill (subscriber, #25196) [Link]

Yeah, that's what I suggested first (and indeed Dan has now opened a bug for to implement it in NM), however it is possible to break it down further like I was trying to describe later:

1) scan the last channel
2) scan the known channels for the last SSID
3) scan all (remaining) channels

The intermediate step only makes sense if those known channels are a relatively small subset of all channels, but with typical installations they will be. In fact, for many networks like your home network 1) and 2) will be exactly the same because you only have a single AP, but for typical enterprise networks 2) will still be better than 3).

flicker-free suspend/resume on Intel

Posted Mar 8, 2013 0:56 UTC (Fri) by mgedmin (guest, #34497) [Link] (3 responses)

Somewhat tangentially there's a very interesting article about DHCP tricks that MacOS X does to reconnect faster.

I'd love to see Network Manager pick up something from that.

Instead, currently when I suspend a laptop via ssh -t foo sudo pm-suspend, I get to enjoy a lapsed DHCP lease on resume, for a few hours. According to strace that's because dhcpd expiration timer (i.e. select() with a timeout) simply stops while the laptop is suspended. Connection still works, but the wifi router doesn't resolve the laptop's hostname until dhcpd finally wakes up.

flicker-free suspend/resume on Intel

Posted Mar 8, 2013 9:07 UTC (Fri) by johill (subscriber, #25196) [Link]

This would be easier in connman as it has DHCP built into it rather than calling out to dhclient (running as a daemon)

flicker-free suspend/resume on Intel

Posted Mar 8, 2013 15:35 UTC (Fri) by njwhite (guest, #51848) [Link]

Ah, I've run into this with wpa_supplicant on Debian. Have you found a solution to it? Is there a straightforward way to get dhclient to wake up when the computer resumes?

flicker-free suspend/resume on Intel

Posted Mar 14, 2013 0:46 UTC (Thu) by kevinm (guest, #69913) [Link]

If CLOCK_MONOTONIC in Linux actually worked according to POSIX spec, then a timer based on this clock could be used to fix this problem.

(POSIX says that CLOCK_MONOTONIC measures time elapsed since "an unspecified point in the past", and further "This point does not change after system start-up time.". On Linux however, CLOCK_MONOTONIC stops while the system is suspended, which is clearly nonconforming).