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