1 USB device persistence during system suspend 2 3 Alan Stern <stern@rowland.harvard.edu> 4 5 September 2, 2006 (Updated February 25, 2008) 6 7 8 What is the problem? 9 10According to the USB specification, when a USB bus is suspended the 11bus must continue to supply suspend current (around 1-5 mA). This 12is so that devices can maintain their internal state and hubs can 13detect connect-change events (devices being plugged in or unplugged). 14The technical term is "power session". 15 16If a USB device's power session is interrupted then the system is 17required to behave as though the device has been unplugged. It's a 18conservative approach; in the absence of suspend current the computer 19has no way to know what has actually happened. Perhaps the same 20device is still attached or perhaps it was removed and a different 21device plugged into the port. The system must assume the worst. 22 23By default, Linux behaves according to the spec. If a USB host 24controller loses power during a system suspend, then when the system 25wakes up all the devices attached to that controller are treated as 26though they had disconnected. This is always safe and it is the 27"officially correct" thing to do. 28 29For many sorts of devices this behavior doesn't matter in the least. 30If the kernel wants to believe that your USB keyboard was unplugged 31while the system was asleep and a new keyboard was plugged in when the 32system woke up, who cares? It'll still work the same when you type on 33it. 34 35Unfortunately problems _can_ arise, particularly with mass-storage 36devices. The effect is exactly the same as if the device really had 37been unplugged while the system was suspended. If you had a mounted 38filesystem on the device, you're out of luck -- everything in that 39filesystem is now inaccessible. This is especially annoying if your 40root filesystem was located on the device, since your system will 41instantly crash. 42 43Loss of power isn't the only mechanism to worry about. Anything that 44interrupts a power session will have the same effect. For example, 45even though suspend current may have been maintained while the system 46was asleep, on many systems during the initial stages of wakeup the 47firmware (i.e., the BIOS) resets the motherboard's USB host 48controllers. Result: all the power sessions are destroyed and again 49it's as though you had unplugged all the USB devices. Yes, it's 50entirely the BIOS's fault, but that doesn't do _you_ any good unless 51you can convince the BIOS supplier to fix the problem (lots of luck!). 52 53On many systems the USB host controllers will get reset after a 54suspend-to-RAM. On almost all systems, no suspend current is 55available during hibernation (also known as swsusp or suspend-to-disk). 56You can check the kernel log after resuming to see if either of these 57has happened; look for lines saying "root hub lost power or was reset". 58 59In practice, people are forced to unmount any filesystems on a USB 60device before suspending. If the root filesystem is on a USB device, 61the system can't be suspended at all. (All right, it _can_ be 62suspended -- but it will crash as soon as it wakes up, which isn't 63much better.) 64 65 66 What is the solution? 67 68The kernel includes a feature called USB-persist. It tries to work 69around these issues by allowing the core USB device data structures to 70persist across a power-session disruption. 71 72It works like this. If the kernel sees that a USB host controller is 73not in the expected state during resume (i.e., if the controller was 74reset or otherwise had lost power) then it applies a persistence check 75to each of the USB devices below that controller for which the 76"persist" attribute is set. It doesn't try to resume the device; that 77can't work once the power session is gone. Instead it issues a USB 78port reset and then re-enumerates the device. (This is exactly the 79same thing that happens whenever a USB device is reset.) If the 80re-enumeration shows that the device now attached to that port has the 81same descriptors as before, including the Vendor and Product IDs, then 82the kernel continues to use the same device structure. In effect, the 83kernel treats the device as though it had merely been reset instead of 84unplugged. 85 86The same thing happens if the host controller is in the expected state 87but a USB device was unplugged and then replugged, or if a USB device 88fails to carry out a normal resume. 89 90If no device is now attached to the port, or if the descriptors are 91different from what the kernel remembers, then the treatment is what 92you would expect. The kernel destroys the old device structure and 93behaves as though the old device had been unplugged and a new device 94plugged in. 95 96The end result is that the USB device remains available and usable. 97Filesystem mounts and memory mappings are unaffected, and the world is 98now a good and happy place. 99 100Note that the "USB-persist" feature will be applied only to those 101devices for which it is enabled. You can enable the feature by doing 102(as root): 103 104 echo 1 >/sys/bus/usb/devices/.../power/persist 105 106where the "..." should be filled in the with the device's ID. Disable 107the feature by writing 0 instead of 1. For hubs the feature is 108automatically and permanently enabled and the power/persist file 109doesn't even exist, so you only have to worry about setting it for 110devices where it really matters. 111 112 113 Is this the best solution? 114 115Perhaps not. Arguably, keeping track of mounted filesystems and 116memory mappings across device disconnects should be handled by a 117centralized Logical Volume Manager. Such a solution would allow you 118to plug in a USB flash device, create a persistent volume associated 119with it, unplug the flash device, plug it back in later, and still 120have the same persistent volume associated with the device. As such 121it would be more far-reaching than USB-persist. 122 123On the other hand, writing a persistent volume manager would be a big 124job and using it would require significant input from the user. This 125solution is much quicker and easier -- and it exists now, a giant 126point in its favor! 127 128Furthermore, the USB-persist feature applies to _all_ USB devices, not 129just mass-storage devices. It might turn out to be equally useful for 130other device types, such as network interfaces. 131 132 133 WARNING: USB-persist can be dangerous!! 134 135When recovering an interrupted power session the kernel does its best 136to make sure the USB device hasn't been changed; that is, the same 137device is still plugged into the port as before. But the checks 138aren't guaranteed to be 100% accurate. 139 140If you replace one USB device with another of the same type (same 141manufacturer, same IDs, and so on) there's an excellent chance the 142kernel won't detect the change. The serial number string and other 143descriptors are compared with the kernel's stored values, but this 144might not help since manufacturers frequently omit serial numbers 145entirely in their devices. 146 147Furthermore it's quite possible to leave a USB device exactly the same 148while changing its media. If you replace the flash memory card in a 149USB card reader while the system is asleep, the kernel will have no 150way to know you did it. The kernel will assume that nothing has 151happened and will continue to use the partition tables, inodes, and 152memory mappings for the old card. 153 154If the kernel gets fooled in this way, it's almost certain to cause 155data corruption and to crash your system. You'll have no one to blame 156but yourself. 157 158YOU HAVE BEEN WARNED! USE AT YOUR OWN RISK! 159 160That having been said, most of the time there shouldn't be any trouble 161at all. The USB-persist feature can be extremely useful. Make the 162most of it. 163