Intel Rapid Start on Linux

[Melsion]

Hi!

just a few days ago I got my new laptop, it's an HP Spectre XT ultrabook. It's a neat machine, and more importantly, everything works on linux with little or no work at all (wifi, webcam, uefi boot... even the touchscreen) which is very important for me as I use Gentoo as my only OS. Anyway, it comes with Intel Rapid Start (iRST) technology... which is the only thing I can't get to work properly.

Basically, you need to have a partition with a size equal to your system's memory. When you suspend to ram (S3), the BIOS wakes up after some time and flushes all pages in RAM to the partition earlier mentioned and shut's down the system. When you open the lid or press the power button, the BIOS directly restores all data to RAM and the OS comes back thinking it has been in a normal S3 state, so you can boot into your system in under 5 seconds. It's like hibernation, but directly from BIOS.

The thing is, I've seen some motherboards (specially for desktops) allow the user to adjust the timer from BIOS, my laptop doesn't, it just allows to deactivate the technology. So it seems the OS passes the timeout and some options to the BIOS (acpi?) before entering S3.

When I close the lid, it enters S3, bot from there on.... it's all random. Sometimes it wakes up inmediatelly to hibernate with iRST, sometimes it does it after a few random minutes, sometimes it stays in S3 forever, and sometimes (and this is troublesome) it actually wakes up the OS after some time and stays on forever, ignoring the lid status and reading random data from the touchscreen causing a mess (apps open, moves all desktop elements, erases files.... it's like leaving your cat playing with the mouse).

So I was wondering if anyone has had any experience playing with this technology and knows how to configure it.

My /proc/acpi only has two entries: button (the lid) and wakeup, it's contents are:

Code: Select all

Device  S-state   Status   Sysfs node
P0P1      S4    *disabled
GLAN      S4    *disabled
EHC1      S3    *enabled   pci:0000:00:1d.0
EHC2      S3    *enabled   pci:0000:00:1a.0
XHC       S3    *enabled   pci:0000:00:14.0
HDEF      S0    *disabled  pci:0000:00:1b.0
RP01      S5    *disabled  pci:0000:00:1c.0
PXSX      S5    *enabled   pci:0000:01:00.0
RP02      S4    *disabled  pci:0000:00:1c.1
PXSX      S4    *disabled  pci:0000:02:00.0
RP03      S4    *disabled
PXSX      S4    *disabled
RP04      S4    *disabled  pci:0000:00:1c.3
PXSX      S4    *disabled  pci:0000:03:00.0
RP05      S5    *disabled  pci:0000:00:1c.4
PXSX      S5    *disabled
HRUP      S5    *disabled
HRDN      S5    *disabled
RP06      S4    *disabled
PXSX      S4    *disabled
RP07      S4    *disabled                                                                                                                                                                                                                    
PXSX      S4    *disabled
RP08      S4    *disabled
PXSX      S4    *disabled
PEG0      S4    *disabled
PEGP      S4    *disabled
PEG1      S4    *disabled
PEG2      S4    *disabled
PEG3      S4    *disabled
LID0      S3    *disabled

Any ideas? Where in the /sys or /proc tree could I find a file related to this system?

Thanks in advance and sorry for my poor english!

[jpc22]

I dont know much about that technology but i did some research on hibernation and suspend to ram a while ago and some threads i remember mentioned pretty much the same as irst (saving the ram content in a ``swap`` partition at shutdown/suspend to resume and boot faster from it) but implemented with linux software instead of directly from the bios.
unfortunately i cant remember where i saw this, and im not using this feature on my machines for security issues with cryptography.


Ultrabooks and irst are pretty new , so maybe the linux kernels conflicts with the bios over the control for processor states and confuses irst.


I suggest you do some research and thinker really carefully (acpi controls a lot of important stuff life fans , voltage...) with acpi related boot arguments by passing them to your bootloader in order to enable some features or fix a linux/bios conflict. The method to pass such arguments will vary according to your bootloader.

ie: append=`` acpi_osi=Linux Backlight=vendor`` is what used to work on my laptop to enable keyboard backlight when i used lilo.



just my two cents, that being said, if you cant get the 5 second boot directly from bios and or linux support for irst, the software possibility remains.

[Hu]

Linux has supported a similar feature for quite a while, although the ordering is necessarily a little different. Linux suspend-to-both writes a hibernation image, then places the machine in S3. If you retain power, you can resume from S3. If power fails, you can resume from hibernation. This requires writing the hibernation image immediately, but for spinning drives, this is a better choice, since it means you do not wake up the drive at some later point (possibly in a laptop bag) for the iRST disk write. Linux suspend-to-both also means that your standard hibernation location is used, so you do not need to dedicate extra storage for iRST.

[Melsion]

Thanks for the info! I'll do some research.

I've done some testing and, as far as I can tell, irst is barely 2 seconds faster than linux hibernate. I suppose it's the time it takes to read the kernel image before it can load the pages back to memory, wich is something irst avoids. I can live with that. Specially since I load the kernel image from UEFI directly, and I have to compile the boot options in the kernel image itself.... bad idea for toying with boot options.

I didn't know about suspend to both, will give it a try as soon as I can. But there's a function I'd be missing anyway, having the BIOS shutdown the system after a timeout. I'd like to be able to close the lid and have the system automatically suspend but, if I don't get back to the laptop after, say, half an hour, the system should shutdown completelly. With suspend to both, it would resume from RAM if I opened the lid before the timeout and resume from disk afterwards. Is it even possible from linux?

Quick search on google shows nothing... any ideas?

[Hu]

As I understand it, suspend-to-both does not directly support the use case you describe. You could probably kludge it with a resume timer to exit S3 and trigger an explicit hibernate to disk, but that would arguably be worse than just trying to make iRST to do the right thing. On most machines, S3 consumes very little power, so unless you expect the machine to go for at least a day, the extra complexity may not be worth it.

[invigo]

I think that Rapid Start Tech refers to using a small (8gb) SSD as sort of a cache. I do not think its meant to be used on a regular SSD. Some motherboards even come with the tiny SSD soldered on to the motherboard.

[Melsion]

invigo, I believe you're refering to Intel Rapid Storage, it's something completely different.

Just updating this thread because support for iRST has been implemented in the kernel some time ago and works like a charm in my laptop. In my case the setup was easy, just leave a partition (4Gb) for iRST and install Gentoo normally. If I leave the iRST option active in BIOS, when gentoo suspends the bios it will automatically """hibernate""" it to the iRST partition without intervention from the OS. When booting, the bios itself loads the image to ram and the kernel "believes" it's waking from S3. It's actually a bit faster than linux hibernate because you don't have to wait for the BIOS - GRUB - Kernel sequence before the image is copied to RAM.

The only problem is, I can't find the option the documentation says there is in /proc to adjust the timeout. I can live with that.

[roarinelk]

This should help:
http://mjg59.dreamwidth.org/26022.html

[Melsion]

Thanks!

[albright]

I can't help but am also curious about this

I have a thinkpad T440S set to dual boot with windows.

I didn't touch the basic partition layout and there is
one partition like this:

/dev/sda5 985534464 1000214527 14680064 7G Intel Fast Flash

But I too see random entry into the "deep sleep" mode (I've never seen
your wake-up problem though). I can't see any pattern - sometimes the
system goes into sleep-to-ram, sometimes "deep sleep".

[Melsion]

Hi albright

With the latest kernels, if you enable the iRST option (somewhere in devices/x86 platform devices) it works as it should. The problem was that, without the driver, the system went to S3 (sleep to ram) and then the firmware awoke the system after the preset timeout and, for reasons beyound my knowledge, sometimes it knows what to do and sometimes it doesn't. With the module enabled, it works perfectly.

BTW, I found the sysfs path (for my laptop) to adjust the behaviour of the firmware:

/sys/bus/acpi/drivers/intel_rapid_start/INT3392\:00/

with the file "wakeup_time" (captain obvious here) you can set up how many minutes go between entering S3 and the firmware going to hibernation, as for the "wakeup_events" file, I have no idea.

[albright]

@melsion - thanks for that; very informative

however, although I have the intel_rst module loaded,

the ls -l of /sys/bus/acpi/drivers/intel_rapid_start/
is just this:

total 0
--w------- 1 root root 4096 Sep 16 15:06 bind
lrwxrwxrwx 1 root root 0 Sep 16 15:06 module -> ../../../../module/intel_rst
--w------- 1 root root 4096 Sep 16 15:06 uevent
--w------- 1 root root 4096 Sep 16 15:06 unbind

no INT3392 ...

Not sure why

EDIT: ok, found INT3392:00 but it has no wakeup-time, just

Code: Select all

INT3392:00 # ls -l
total 0
-r--r--r-- 1 root root 4096 Sep 16 15:24 hid
-r--r--r-- 1 root root 4096 Sep 16 15:24 modalias
-r--r--r-- 1 root root 4096 Sep 16 15:24 path
drwxr-xr-x 2 root root    0 Sep 16 15:24 power
lrwxrwxrwx 1 root root    0 Sep 12 09:58 subsystem -> ../../../../bus/acpi
-rw-r--r-- 1 root root 4096 Sep 12 09:24 uevent

and inside /power:

Code: Select all

power # ls -l
total 0
-rw-r--r-- 1 root root 4096 Sep 16 15:24 autosuspend_delay_ms
-rw-r--r-- 1 root root 4096 Sep 16 15:24 control
-r--r--r-- 1 root root 4096 Sep 16 15:24 runtime_active_time
-r--r--r-- 1 root root 4096 Sep 16 15:24 runtime_status
-r--r--r-- 1 root root 4096 Sep 16 15:24 runtime_suspended_time

and cat autosuspend_delay_ms just gives

Code: Select all

autosuspend_delay_ms: Input/output error

[Melsion]

Do you have iRST enabled in BIOS?

[albright]

Do you have iRST enabled in BIOS?

yes, set for 3 hours, but as I said sometimes it enters the
deep sleep state long before then during sleep-to-ram

I'll set the timeout to 1 minute and see what happens

[albright]

after setting the bios timeout to 1 minute I several times
suspended to ram and waited (more than) 1 minute.

rapid start never kicked in ... I have no idea what makes
my machine sometimes go into the "deep sleep" mode

[Melsion]

The problem with iRST is that it's very obscure for troubleshooting, and in your case it seems it is disabled for some reason.

Looking at your first post, I see the "Intel Fast Flash" partition is just 7G, but I bet you have 8Gb of RAM. Keep in mind that it is just an hibernation partition, in windows, iRST has the capability to discard RAM pages to reduce the size of the image it's going to save, but that functionality is still not implemented in Linux. Maybe that's why it's not working... but I'm just guessing....

[albright]

Maybe that's why it's not working... but I'm just guessing....

I'm not really interested in having it work, but I am curious why
it doesn't work

and remember, every so often, my computer does go into the "deep sleep"
and takes about - say - 10 seconds to wake up and displays a
"resuming from deep sleep" bios-style message

so I think that sometimes rapid start *is* working

it's all rather confusing

[Melsion]

Sorry but... no idea, as I said, propietary implementations are allways so obscure that it's simply impossible to understand what's going on.

I'd bet on the memory problem, if the image fits in the partition it goes to deep sleep, if it doesn't it just wont. It also depends on the implementation every maker does of the function...

[ahferroin7]

So, I finally just got around to setting this up on my new thinkpad L540 which I'm dual booting with Gentoo and Windows 8.1, and I thought that I'd share some of the information that I've pulled together about it.

1. The 'wakeup_events' file is an integer bitmask for specifying what events trigger the transition from S3 to S4. Bit 0 indicates to trigger on a timer expiration, and bit 1 indicates to trigger when the battery reports as being almost empty.
2. During the transition itself, the firmware sends a TRIM command to the disk for the entire partition, and then only writes out bytes that from memory that are non-zero. This would explain why works sometimes when you have a partition that is too small. I don't know whether the firmware does any other transformations on the data, a number of SSD's I've seen return blocks of 0xFF bytes for areas that have been discarded by TRIM.
3. There isn't any way to set the low battery threshold for that trigger event, I would assume that the intent is for this to be hardcoded in the firmware to a known reliable value.
4. When it doesn't work on Linux, the ffirmware has a tendency to leave the system in S0 with the processor running in a tight loop, and appears to require a power-cycle to be usable again.
5. If you are booting in [U]EFI mode, the partition table for the SSD has to be GPT, and if you are booting in BIOS mode, the partition table has to be MBR