USB device persistence during system suspend — The Linux Kernel documentation (2024)

What is the problem?¶

According to the USB specification, when a USB bus is suspended thebus must continue to supply suspend current (around 1-5 mA). Thisis so that devices can maintain their internal state and hubs candetect connect-change events (devices being plugged in or unplugged).The technical term is “power session”.

If a USB device’s power session is interrupted then the system isrequired to behave as though the device has been unplugged. It’s aconservative approach; in the absence of suspend current the computerhas no way to know what has actually happened. Perhaps the samedevice is still attached or perhaps it was removed and a differentdevice plugged into the port. The system must assume the worst.

By default, Linux behaves according to the spec. If a USB hostcontroller loses power during a system suspend, then when the systemwakes up all the devices attached to that controller are treated asthough they had disconnected. This is always safe and it is the“officially correct” thing to do.

For many sorts of devices this behavior doesn’t matter in the least.If the kernel wants to believe that your USB keyboard was unpluggedwhile the system was asleep and a new keyboard was plugged in when thesystem woke up, who cares? It’ll still work the same when you type onit.

Unfortunately problems _can_ arise, particularly with mass-storagedevices. The effect is exactly the same as if the device really hadbeen unplugged while the system was suspended. If you had a mountedfilesystem on the device, you’re out of luck -- everything in thatfilesystem is now inaccessible. This is especially annoying if yourroot filesystem was located on the device, since your system willinstantly crash.

Loss of power isn’t the only mechanism to worry about. Anything thatinterrupts a power session will have the same effect. For example,even though suspend current may have been maintained while the systemwas asleep, on many systems during the initial stages of wakeup thefirmware (i.e., the BIOS) resets the motherboard’s USB hostcontrollers. Result: all the power sessions are destroyed and againit’s as though you had unplugged all the USB devices. Yes, it’sentirely the BIOS’s fault, but that doesn’t do _you_ any good unlessyou can convince the BIOS supplier to fix the problem (lots of luck!).

On many systems the USB host controllers will get reset after asuspend-to-RAM. On almost all systems, no suspend current isavailable during hibernation (also known as swsusp or suspend-to-disk).You can check the kernel log after resuming to see if either of thesehas happened; look for lines saying “root hub lost power or was reset”.

In practice, people are forced to unmount any filesystems on a USBdevice before suspending. If the root filesystem is on a USB device,the system can’t be suspended at all. (All right, it _can_ besuspended -- but it will crash as soon as it wakes up, which isn’tmuch better.)

What is the solution?¶

The kernel includes a feature called USB-persist. It tries to workaround these issues by allowing the core USB device data structures topersist across a power-session disruption.

It works like this. If the kernel sees that a USB host controller isnot in the expected state during resume (i.e., if the controller wasreset or otherwise had lost power) then it applies a persistence checkto each of the USB devices below that controller for which the“persist” attribute is set. It doesn’t try to resume the device; thatcan’t work once the power session is gone. Instead it issues a USBport reset and then re-enumerates the device. (This is exactly thesame thing that happens whenever a USB device is reset.) If there-enumeration shows that the device now attached to that port has thesame descriptors as before, including the Vendor and Product IDs, thenthe kernel continues to use the same device structure. In effect, thekernel treats the device as though it had merely been reset instead ofunplugged.

The same thing happens if the host controller is in the expected statebut a USB device was unplugged and then replugged, or if a USB devicefails to carry out a normal resume.

If no device is now attached to the port, or if the descriptors aredifferent from what the kernel remembers, then the treatment is whatyou would expect. The kernel destroys the old device structure andbehaves as though the old device had been unplugged and a new deviceplugged in.

The end result is that the USB device remains available and usable.Filesystem mounts and memory mappings are unaffected, and the world isnow a good and happy place.

Note that the “USB-persist” feature will be applied only to thosedevices for which it is enabled. You can enable the feature by doing(as root):

echo 1 >/sys/bus/usb/devices/.../power/persist

where the “...” should be filled in the with the device’s ID. Disablethe feature by writing 0 instead of 1. For hubs the feature isautomatically and permanently enabled and the power/persist filedoesn’t even exist, so you only have to worry about setting it fordevices where it really matters.

Is this the best solution?¶

Perhaps not. Arguably, keeping track of mounted filesystems andmemory mappings across device disconnects should be handled by acentralized Logical Volume Manager. Such a solution would allow youto plug in a USB flash device, create a persistent volume associatedwith it, unplug the flash device, plug it back in later, and stillhave the same persistent volume associated with the device. As suchit would be more far-reaching than USB-persist.

On the other hand, writing a persistent volume manager would be a bigjob and using it would require significant input from the user. Thissolution is much quicker and easier -- and it exists now, a giantpoint in its favor!

Furthermore, the USB-persist feature applies to _all_ USB devices, notjust mass-storage devices. It might turn out to be equally useful forother device types, such as network interfaces.

WARNING: USB-persist can be dangerous!!¶

When recovering an interrupted power session the kernel does its bestto make sure the USB device hasn’t been changed; that is, the samedevice is still plugged into the port as before. But the checksaren’t guaranteed to be 100% accurate.

If you replace one USB device with another of the same type (samemanufacturer, same IDs, and so on) there’s an excellent chance thekernel won’t detect the change. The serial number string and otherdescriptors are compared with the kernel’s stored values, but thismight not help since manufacturers frequently omit serial numbersentirely in their devices.

Furthermore it’s quite possible to leave a USB device exactly the samewhile changing its media. If you replace the flash memory card in aUSB card reader while the system is asleep, the kernel will have noway to know you did it. The kernel will assume that nothing hashappened and will continue to use the partition tables, inodes, andmemory mappings for the old card.

If the kernel gets fooled in this way, it’s almost certain to causedata corruption and to crash your system. You’ll have no one to blamebut yourself.

For those devices with avoid_reset_quirk attribute being set, persistmaybe fail because they may morph after reset.

YOU HAVE BEEN WARNED! USE AT YOUR OWN RISK!

That having been said, most of the time there shouldn’t be any troubleat all. The USB-persist feature can be extremely useful. Make themost of it.