Suspend/Resume to Disk - Hibernation - iFFS/IRST Partition (Intel Fast Flash/Intel Rapid Start Technology)

What is this and how does it work?
  • On newer Intel-based computers, the UEFI/BIOS offers a switch to enable a iFFS/IRST partition to support suspend/resume.
    This is called "Intel Rapid Start Technology". It affects mainly mobiles (laptops & tablets), but also desktop and maybe server systems.
    Maybe there's similar functionality on AMD based systems?
  • This can serve as a work-around to suspend to disk for those who can not directly suspend to disk (aka hibernate)
    EDIT: Either the following is intended by the IRST specs, or a "feature" of my UEFI: When I press the power button quickly after suspending (within ~5 seconds), the system enters S4 state. This way, I can emulate hibernation w/o having to wait for the timer to fire
  • ACPI Power State Cheat Sheet (S0-5) Note that this might not 100% accurate...
  1. On suspend to RAM a countdown timer is started. The system enters the S3 state.
  2. When the timer fires, the UEFI/BIOS writes the contents of the RAM to this partition, flags it, the system enters S4 state and is switched off.
    Obviously, this saves much energy (battery runtime), since a system that is switched off does not need to refresh the RAM like in S3 state. I.e. it needs zero except the self-drainage of the battery plus what the ME needs to run.
  3. On restart, the UEFI/BIOS checks the iFFS/IRST partition for the flag.
  4. If it is flag'ed, the system boots from it, bypassing the active boot partition and usual boot procedure (efiboot->...->FreeBSD loader(8))
Prerequisites
  • Make shure your system successfully resumes from suspend-to-RAM.
    (mouse, USB, graphics device, etc.) Consult the handbook, wiki, and search the forum.
  • Check your UEFI/BIOS settings under "Power" to see if your system supports IRST.
    Watch out for "Intel Rapid Start", "Intel Fast Flash", "IRST", "iFFS" or similar
  • !The partition's size must be at least equal to the amount of RAM!
  • Check if you already have such a partition -- it's type is "!D3BFE2DE-3DAF-11DF-BA40-E3A556D89593"
    gpart show ada0
  • This only works for GPT partition scheme. You want that anyway.
  • Probably this only works with EFI boot; I did not try with the old legacy BIOS boot method.
  • NOTE: the IRST partition can not be used as swap device, unless IRST is disabled in the UEFI/BIOS or the system will never suspend-to-RAM. It can be used as a dump device, since a crashed kernel will not suspend-to-RAM after the crash.
    Using the IRST partition as dump device is not possible yet. A patch is in the works.
  • Usually, one can not directly suspend-to-disk (S4) to the IRST partition without going through S3 state (suspend-to-RAM) first - this is completely out of control of the OS and managed solely by the UEFI's ACPI.
  • On some systems, it is neccessary to disable the TRM/TTP security chip. So if you need TRM/TTP running, chances are it will not work for you.
Howto
  1. Either change the type of your existing swap partition: Step #3 or...
    On ZFS, you can instead swap to a ZVOL: zfs create -b 4k -V zpool/SWAP and add that to /etc/fstab
    Currently, you can not use the IRST as a dump device. I'm working to provide a patch for this. AFAIK, dumping to a ZVOL swap is not possible either.
  2. Create a partition of the size of your RAM and any enlargements you plan to stick in:
    gpart add -t ms-basic-data -i 3 -s 12G ada0 The type does not matter and will be changed later.
    Adjust "12G" to the size of your RAM, the index of the partition and name of your disk device
    Or when the installer reaches the task to partition the disk/SSD, let the installer create it.
    Either give the partition a type not used by FreeBSD, or open a shell and...
  3. Change the partition type to the iFFS magic number: gpart modify -i 3 -t \!D3BFE2DE-3DAF-11DF-BA40-E3A556D89593 ada0
    Replace "-i 3" with the index of the IRST partition, and "ada0" with your disk device and number. Note the backslash!
  4. Optionally label the partition: gpart -i 3 -l IRST ada0 iFFS would be a good label, too.
  5. Enable IRST in the UEFI/BIOS and set the timer to a very low value for testing purpose (e.g. 1 minute).
  6. Optionally de-activate or disable the TRM/TTP security chip in the UEFI/BIOS.
    This applies to Lenovo (at least Thinkpad T450s, very likely other models as well) and probably other brands, too.
  7. In the running system, enter suspend-to-RAM:
    zzz or acpiconf -s 3, or use your GUI's way to do that.
    If zzz complains, do sysctl hw.acpi.suspend_state=S3
    Optionally, start the timer of you mobile phone. Wait until the timer fires.
    Most computers will give feedback by a slowly blinking LED light, or in a small status LCD. Listen to the noise of the fan and disk
    After the timeout, it takes a few seconds to save the contests of RAM to disk, then the system switches off.
    LED/LCD goes off, fan and disk will stop
  8. Start the computer the usual way: Press the Power button or issue a wakeup packet on the network.
    The system will show something like "resuming from deep sleep state"
  9. If the system restarts successfully into the previous state:
    Click Thanks on this posting to give some feedback, so we can guess for how many it works.
    In the UEFI/BIOS, set the timer to a larger value, e.g. 15 minutes, else switch IRST off completely.
    See topic #6: TRM security chip and 1st topic of the Prerequisites
Help, It did not work!
  • If suspend-to-disk does not work with the IRST partition, it can be used otherwise, e.g. as swap or /var/tmp. Of course you'll have to change the partition type accordingly:
    gpart modify -i 3 -t freebsd-swap and optionally add a ZVOL to enlarge the swap space.
  • Destroy the partition with gpart(8) and enlarge it's neighbor to use the space with gpart resize
  • A ZFS zpool(8) can be enlarged to use new diskspace: zpool set autoexpand=on.
  • Use growfs(8) to enlarge an UFS filesystem.
See also
gpart(8), zpool(8), zzz(8), acpiconf(8), sysctl hw.acpi | grep -E 's(leep|uspend)'

Good luck!
If you are a native english speaker and want to correct my "gernglish", kindly ask the moderators to allow you to polish this.
 
Last edited:
I forgot to note to set hw.acpi.s4bios=1 in sysctl.conf(4) if your system resumes correctly from S3 state (suspend to RAM).
EDIT The sysctl(8) knob hw.acpi.s4bios enables the OS to go directly into S4 state (suspend to disk), and must be supported by the UEFI/BIOS. It does not work for me (does not resume), YMMV.
 
Last edited:
  • Like
Reactions: a6h
Thanks for tutorial. I appreciate your low-level introduction to tutorial. Providing an in-depth introductory remarks before beginning the lesson
is a good style of writing. Everyone should do that. Tutorial without in-depth introduction is mechanical and not very helpful. Thanks.
 
Dang! I have set up my SSD without a swap because I already use a ZVOL.

Also a caveat: you can only enlarge partitions upwards wits ufs because the superblock would not be found otherwise. No Idea right now about ZFS, my memory says something about markers at the end, but that might not be an issue.
 
Dang! I have set up my SSD without a swap because I already use a ZVOL.
Dong! IIRC, a ZVOL can't be used as a dump device, thus this is not recommended on a single disk setup, anyway.
Also a caveat: you can only enlarge partitions upwards wits ufs because the superblock would not be found otherwise. No Idea right now about ZFS, my memory says something about markers at the end, but that might not be an issue.
Yes, we have growfs(8) but no shrinkfs(8). Dito for ZFS: there is zpool set autoexpand=on, but neither zpool shrink nor zpool resize. The only shrinkable filesystems I know are FAT, NTFS & ext{2,3,4}fs.
  • A good nerd will regularly backup valuable data anyway. You're doing that, don't you? So then you can reinstall with a IRST partition, after you thoroughly verified your backups.
  • When did you latest verify your backups & excersized a recovery manœvre?
 
Last backup - two weeks (not doing much atm)
Last desaster check - 3 Month or so. Had to pull some stuff I accidently nuked out of that second backup (yes, two different kinds/ways to backup, so if one fails...)
 
The more people verify & confirm the procedure described in this howto is more or less sound, the sooner it will go into the Handbook or an article in the FreeBSD docs. Maybe eventually the necessary steps can be added to the bsdinstall(8). IMHO 4 feedbacks until now, plus one who reported to me via e-mail, is too less.
EDIT I did a reinstallation + data migration after I found out how to gain hibernation. Cost: ~1 day. Good opportunity to get rid of superfluous stuff, too.
 
Can we please have a tool to resize and move ZFS partitions? This absolute genius did indeed add a swap partition - of 2GB. I could hit my head into a pillow. So you all be warned.

Edit: point being, simply by spending these few GBs, would have saved me the trouble. Now I would need to invest more time in this than can be recovered should it work.
 
Can we please have a tool to resize and move ZFS partitions? This absolute genius did indeed add a swap partition - of 2GB. I could hit my head into a pillow. So you all be warned.
The genius is bsdinstall(8)? File in a bug report. Well, depending on the size of your RAM, that might be large enough to hold a minidump -- IIRC that's standard; full dumps must be enabled by sysctl debug.minidump=0. From my experience, a ratio of 1:3 for swap/dump partition:RAM is sufficient for a minidump. Thus you can go on & create a 2nd swap on a ZVOL, or choose manual partitioning in the installer & enlarge the swap partition to 1-2 x RAM for RAM >= 4 GB. For RAM <= 4 GB swap should be at least 2 x RAM.
  • On a SSD, it's fine to have sysctl vfs.zfs.mdcomp_disable="1" right from the start before installation starts & put that into loader.conf(5) (in /tmp/bsdinstall/... or such). This will speed up metadata access on a SDD for operations on large # of files.
 
Wow... thats a great guide!
Sadly I have no UEFI computer, so I cannot test this.

Do you think the new LUA boot loader could do what most Linux boot loaders can do, check flag, load memory contents from swap, and then enter the existing S3 restoration routine?
If it would it be (relatively) easy to add such thing to the new bootloader, we could make FreeBSD able to do S4 hibernate.
For energy saving and other reasons I consider this a very important feature.

(If this cannot not be done using the Lua bootloader, would it be possible, maybe even easy using the old Forth bootloader?)
 
Off-topic …

… is it my imagination, or did I recently read of an approach that does not require FFS/RST?

(I recall reading something very concise. Stupidly I didn't bookmark the page. I recall only that the approach was not for all types of hardware.)

(suspend to swap) never worked from my limited experiences.
 
Interesting, didn't know about that approach at all. Not sure if my laptops support this, and too bad that the regular suspend-to-disk / hibernation has never been implemented in FreeBSD as I know and used it with Linux.
 
Back
Top