USB device persistence during system suspend

Author:Alan Stern <>
Date:September 2, 2006 (Updated February 25, 2008)

What is the problem?


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


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

Unfortunately problems _can_ arise, particularly with mass-storage devices. The effect is exactly the same as if the device really had been unplugged while the system was suspended. If you had a mounted filesystem on the device, you’re out of luck – everything in that filesystem is now inaccessible. This is especially annoying if your root filesystem was located on the device, since your system will instantly crash.

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


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

What is the solution?






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


where the ”...” should be filled in the with the device’s ID. Disable the feature by writing 0 instead of 1. For hubs the feature is automatically and permanently enabled and the power/persist file doesn’t even exist, so you only have to worry about setting it for devices where it really matters.

Is this the best solution?


On the other hand, writing a persistent volume manager would be a big job and using it would require significant input from the user. This solution is much quicker and easier – and it exists now, a giant point in its favor!


WARNING: USB-persist can be dangerous!!

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

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


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

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


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