Explaining Intel Rapid Start Technology
Jul. 2nd, 2013 03:50 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59Recent Intel-based systems often implement something called Intel Rapid Start Technology. Like many things with the word "Technology" in the name, there's a large part of this that's marketing. The relatively small amount of technical documentation available implies that it's tied to your motherboard chipset and CPU, but as far as I can tell it's entirely implemented in firmware and could work just as well on, say, a Cyrix on a circa 1996 SIS-based motherboard if someone wrote the BIOS code[1]. But since nobody has, we're stuck with the vendors who've met Intel's requirements and licensed the code.
The concept of IRST is pretty simple. There's a firmware mechanism for setting a sleep timeout. If you suspend your computer and this timeout expires, it'll resume. However, instead of handing control back to the OS, the firmware just copies the entire contents of RAM to a special partition and turns the computer off. Next time you hit the power button, the firmware dumps the partition contents back into RAM and resumes as if nothing had changed. This takes a few seconds longer than resume from S3 but is far faster than resume from hibernation since it starts the moment the system gets power.
At a more technical level, it's a little more complicated. The first thing to know about this feature is that it's entirely invisible unless your hard drive is set up correctly. There needs to be a partition that's at least the size of your system's physical RAM. For GPT systems, this needs to have a type GUID of D3BFE2DE-3DAF-11DF-BA-40-E3A556D89593. For MBR systems, you need a partition type of 0x84[2]. If the firmware doesn't find an appropriate partition then the OS will get no indication that the firmware supports it. Boo.
(The second thing is that it seems like it really does have to be on an SSD, and if you try to do this on spinning media your firmware will ignore it anyway)
If all the prerequisites are in place, an ACPI device with an HID of INT3392 will exist. It has four methods associated with it: GFFS, SFFS, GFTV and SFTV. GFFS returns an integer representing the events that will cause the system to wake up from S3 and suspend to SSD. The system will wake after the timeout expires if bit 0 is set, and will wake when the battery becomes critically low if bit 1 is set. The other bits appear to be unused at the moment[3]. SFFS sets the wakeup events, using the same bit values as GFFS. GFTV returns an integer containing the current wakeup timeout in minutes. SFTV sets it. Values above 1440 (ie, 24 hours) seem to be considered invalid - if I set them the value instead ends up as 10 and the timeout flag gets cleared from the wakeup events field.
I've submitted a patch that adds a sysfs interface for setting these values, and unless anyone objects it'll probably end up in 3.11. There's still the remaining question of how userspace should make use of these, and also how installers should behave when it comes to systems that support IRST. As previously mentioned, there's no obvious indication to the OS that the feature is supported unless the appropriate partition already exists. The easiest way to deal with this is for installers to default to retaining any partitions with the magic IDs, but I'm still looking into whether it's possible to get the firmware to cough up some more information so it can be created automatically even if the drive's entirely blank.
And now, having got this working on a test machine, I just need to split my Thinkpad's swap partition in half and make sure it works here as well. Woo.
[1] Note: I am not going to do this.
[2] Conveniently, the same as the partition type that APM systems used for suspend to disk back when dubstep hadn't been invented yet
[3] At least, if you attempt to set them they get ignored.
The concept of IRST is pretty simple. There's a firmware mechanism for setting a sleep timeout. If you suspend your computer and this timeout expires, it'll resume. However, instead of handing control back to the OS, the firmware just copies the entire contents of RAM to a special partition and turns the computer off. Next time you hit the power button, the firmware dumps the partition contents back into RAM and resumes as if nothing had changed. This takes a few seconds longer than resume from S3 but is far faster than resume from hibernation since it starts the moment the system gets power.
At a more technical level, it's a little more complicated. The first thing to know about this feature is that it's entirely invisible unless your hard drive is set up correctly. There needs to be a partition that's at least the size of your system's physical RAM. For GPT systems, this needs to have a type GUID of D3BFE2DE-3DAF-11DF-BA-40-E3A556D89593. For MBR systems, you need a partition type of 0x84[2]. If the firmware doesn't find an appropriate partition then the OS will get no indication that the firmware supports it. Boo.
(The second thing is that it seems like it really does have to be on an SSD, and if you try to do this on spinning media your firmware will ignore it anyway)
If all the prerequisites are in place, an ACPI device with an HID of INT3392 will exist. It has four methods associated with it: GFFS, SFFS, GFTV and SFTV. GFFS returns an integer representing the events that will cause the system to wake up from S3 and suspend to SSD. The system will wake after the timeout expires if bit 0 is set, and will wake when the battery becomes critically low if bit 1 is set. The other bits appear to be unused at the moment[3]. SFFS sets the wakeup events, using the same bit values as GFFS. GFTV returns an integer containing the current wakeup timeout in minutes. SFTV sets it. Values above 1440 (ie, 24 hours) seem to be considered invalid - if I set them the value instead ends up as 10 and the timeout flag gets cleared from the wakeup events field.
I've submitted a patch that adds a sysfs interface for setting these values, and unless anyone objects it'll probably end up in 3.11. There's still the remaining question of how userspace should make use of these, and also how installers should behave when it comes to systems that support IRST. As previously mentioned, there's no obvious indication to the OS that the feature is supported unless the appropriate partition already exists. The easiest way to deal with this is for installers to default to retaining any partitions with the magic IDs, but I'm still looking into whether it's possible to get the firmware to cough up some more information so it can be created automatically even if the drive's entirely blank.
And now, having got this working on a test machine, I just need to split my Thinkpad's swap partition in half and make sure it works here as well. Woo.
[1] Note: I am not going to do this.
[2] Conveniently, the same as the partition type that APM systems used for suspend to disk back when dubstep hadn't been invented yet
[3] At least, if you attempt to set them they get ignored.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Re: Thanks for this!
Date: 2013-07-04 07:56 pm (UTC)So basically I just need to set up something to echo my desired value on boot, yes? I wonder if systemd's tmpfiles.d or a udev rule would do the trick...
Re: Thanks for this!
Date: 2013-07-04 09:43 pm (UTC)So I did "modinfo intel-rst" to get the alias. Sure enough I have a /sys/bus/acpi/devices/INT3392:00, which has a physical path of /sys/devices/LNXSYSTM:00/device:00/INT3392:00. In this directory I am able to find the wakeup_events and wakeup_time files.
Is this a result of using it on 3.10 and not 3.11?
Re: Threat to dm-crypt
Date: 2013-07-05 12:02 am (UTC)Critical level
Date: 2013-07-05 03:00 am (UTC)But what is the "critical level"? Can I set this myself, or is it hard coded into the firmware?
Re: Critical level
Date: 2013-07-05 03:10 am (UTC)sysfs Patches
Date: 2013-07-05 07:42 am (UTC)Re: Threat to dm-crypt
Date: 2013-07-05 11:55 am (UTC)Re: sysfs Patches
Date: 2013-07-05 03:08 pm (UTC)Re: Critical level
Date: 2013-07-05 11:24 pm (UTC)Re: Threat to dm-crypt
Date: 2013-07-08 03:03 am (UTC)See this 2008 paper (https://citp.princeton.edu/research/memory/) or watch the video (http://www.youtube.com/watch?v=JDaicPIgn9U) demonstrating a technique to pull unencrypted passphrases/keys out of RAM from a suspended machine to unlock dm-crypt, TrueCrypt, FileVault, etc.
Re: What goes around comes around
Date: 2013-07-09 07:24 pm (UTC)Re: What goes around comes around
Date: 2013-07-09 07:27 pm (UTC)Working only with UEFI?
Date: 2013-07-11 11:35 am (UTC)Sorry if this is a stupid question. Does this stuff only work when you boot in UEFI mode, or also with legacy BIOS? Asking because I am using a Samsung laptop, and I am forced booting with legacy BIOS if I want to load the samsung-laptop-module.
Second question, should I create some filesystem on the partition, or it does not matter?
Cheers,
Alessandro
Re: Working only with UEFI?
Date: 2013-07-11 11:53 am (UTC)Re: Working only with UEFI?
Date: 2013-07-11 11:58 am (UTC)Trying it today!
Thanks a lot for the nice blog post
Re: Working only with UEFI?
Date: 2013-07-11 08:55 pm (UTC)If I boot in BIOS mode, and I use a GPT partition table, then the thing does not work, and there is no INT3392 under /sys. However, after some gdisk magic and turning my partition table to MBR, now it works as a charm :)
Hence, I guess that you either need BIOS+MBR or UEFI+GPT (I wanted to try the UEFI+GPT combination first, but I have no idea for what damn reason I cannot make the laptop booting my Linux EFI stub).
Thanks again for the blog post and for the driver, this thing seems to be quite nice since it recovers from hibernation much more quickly than other methods
Just Works
Date: 2013-07-13 02:50 pm (UTC)FWIW, I created the requisite type 84 partition of the necessary size on my new W530, having installed a 240GB Plextor mSATA drive, and Rapid Start is working with Linux Mint 15 stock.
I guess that's not much of a surprise, given that Rapid Start is BIOS-based with only some optional hints from the OS, but I thought that you'd want a confirmation.
Since I do have it working, I'll also volunteer to once again be one of your guinea pigs. :-) Presumably you'll want for me to install Fedora into the mix?
Just Works
Date: 2013-07-13 03:33 pm (UTC)FWIW, I created the requisite type 84 partition of the necessary size on my new W530, having installed a 240GB Plextor mSATA drive, and Rapid Start is working with Linux Mint 15 stock.
I guess that's not much of a surprise, given that Rapid Start is BIOS-based with only some optional hints from the OS, but I thought that you'd want a confirmation.
Since I do have it working, I'll also volunteer to once again be one of your guinea pigs. :-) Presumably you'll want for me to install Fedora into the mix?
Re: Just Works
Date: 2013-07-13 03:57 pm (UTC)Was working with a Medion Akoya i7
Date: 2013-07-15 08:49 am (UTC)The good thing about it is that it is working totally separate from the OS. The bad thing - if you change your RAM size you have to grow the partition!
I have tested it but it wasn't really quicker as normal hibernate and hibernating 8 Gig or more takes a while (~20 seconds). Booting the system from scratch is faster (~10 seconds). So I stick with suspend-to-ram (~1 sec) or just plain boot on SSD anyway.
HP
Re: Threat to dm-crypt
Date: 2013-07-16 04:36 am (UTC)I actually got as far as setting up the partition's GUID before the implications occurred to me. It would be nice, but for now hibernate is my only safe option.
Testing in other kernels than mainline
Date: 2013-07-21 10:46 pm (UTC)I was anxiously waiting for someone with some insight on this tech to develop some way of setting up the timeout value on linux, thanks a lot!
Since I didn't want to build the whole kernel to test the module, I isolated it and set up a dkms script for it along with some upstart script to set values on boot.
https://kassick@bitbucket.org/kassick/intel-rst.git
(clone and run setup.sh )
I've just installed it on Quantal/3.5.0-31-generic, seems to work fine; I'll keep you posted.
Kassick.
Re: Testing in other kernels than mainline
Date: 2013-07-21 11:06 pm (UTC)Re: Testing in other kernels than mainline
Date: 2013-07-22 02:21 pm (UTC)https://aur.archlinux.org/packages/dkms-intel-rst/
Re: Just Works
Date: 2013-09-26 05:24 pm (UTC)