0001 .. _usb-persist:
0002
0003 USB device persistence during system suspend
0004 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0005
0006 :Author: Alan Stern <stern@rowland.harvard.edu>
0007 :Date: September 2, 2006 (Updated February 25, 2008)
0008
0009
0010 What is the problem?
0011 ====================
0012
0013 According to the USB specification, when a USB bus is suspended the
0014 bus must continue to supply suspend current (around 1-5 mA). This
0015 is so that devices can maintain their internal state and hubs can
0016 detect connect-change events (devices being plugged in or unplugged).
0017 The technical term is "power session".
0018
0019 If a USB device's power session is interrupted then the system is
0020 required to behave as though the device has been unplugged. It's a
0021 conservative approach; in the absence of suspend current the computer
0022 has no way to know what has actually happened. Perhaps the same
0023 device is still attached or perhaps it was removed and a different
0024 device plugged into the port. The system must assume the worst.
0025
0026 By default, Linux behaves according to the spec. If a USB host
0027 controller loses power during a system suspend, then when the system
0028 wakes up all the devices attached to that controller are treated as
0029 though they had disconnected. This is always safe and it is the
0030 "officially correct" thing to do.
0031
0032 For many sorts of devices this behavior doesn't matter in the least.
0033 If the kernel wants to believe that your USB keyboard was unplugged
0034 while the system was asleep and a new keyboard was plugged in when the
0035 system woke up, who cares? It'll still work the same when you type on
0036 it.
0037
0038 Unfortunately problems _can_ arise, particularly with mass-storage
0039 devices. The effect is exactly the same as if the device really had
0040 been unplugged while the system was suspended. If you had a mounted
0041 filesystem on the device, you're out of luck -- everything in that
0042 filesystem is now inaccessible. This is especially annoying if your
0043 root filesystem was located on the device, since your system will
0044 instantly crash.
0045
0046 Loss of power isn't the only mechanism to worry about. Anything that
0047 interrupts a power session will have the same effect. For example,
0048 even though suspend current may have been maintained while the system
0049 was asleep, on many systems during the initial stages of wakeup the
0050 firmware (i.e., the BIOS) resets the motherboard's USB host
0051 controllers. Result: all the power sessions are destroyed and again
0052 it's as though you had unplugged all the USB devices. Yes, it's
0053 entirely the BIOS's fault, but that doesn't do _you_ any good unless
0054 you can convince the BIOS supplier to fix the problem (lots of luck!).
0055
0056 On many systems the USB host controllers will get reset after a
0057 suspend-to-RAM. On almost all systems, no suspend current is
0058 available during hibernation (also known as swsusp or suspend-to-disk).
0059 You can check the kernel log after resuming to see if either of these
0060 has happened; look for lines saying "root hub lost power or was reset".
0061
0062 In practice, people are forced to unmount any filesystems on a USB
0063 device before suspending. If the root filesystem is on a USB device,
0064 the system can't be suspended at all. (All right, it _can_ be
0065 suspended -- but it will crash as soon as it wakes up, which isn't
0066 much better.)
0067
0068
0069 What is the solution?
0070 =====================
0071
0072 The kernel includes a feature called USB-persist. It tries to work
0073 around these issues by allowing the core USB device data structures to
0074 persist across a power-session disruption.
0075
0076 It works like this. If the kernel sees that a USB host controller is
0077 not in the expected state during resume (i.e., if the controller was
0078 reset or otherwise had lost power) then it applies a persistence check
0079 to each of the USB devices below that controller for which the
0080 "persist" attribute is set. It doesn't try to resume the device; that
0081 can't work once the power session is gone. Instead it issues a USB
0082 port reset and then re-enumerates the device. (This is exactly the
0083 same thing that happens whenever a USB device is reset.) If the
0084 re-enumeration shows that the device now attached to that port has the
0085 same descriptors as before, including the Vendor and Product IDs, then
0086 the kernel continues to use the same device structure. In effect, the
0087 kernel treats the device as though it had merely been reset instead of
0088 unplugged.
0089
0090 The same thing happens if the host controller is in the expected state
0091 but a USB device was unplugged and then replugged, or if a USB device
0092 fails to carry out a normal resume.
0093
0094 If no device is now attached to the port, or if the descriptors are
0095 different from what the kernel remembers, then the treatment is what
0096 you would expect. The kernel destroys the old device structure and
0097 behaves as though the old device had been unplugged and a new device
0098 plugged in.
0099
0100 The end result is that the USB device remains available and usable.
0101 Filesystem mounts and memory mappings are unaffected, and the world is
0102 now a good and happy place.
0103
0104 Note that the "USB-persist" feature will be applied only to those
0105 devices for which it is enabled. You can enable the feature by doing
0106 (as root)::
0107
0108 echo 1 >/sys/bus/usb/devices/.../power/persist
0109
0110 where the "..." should be filled in the with the device's ID. Disable
0111 the feature by writing 0 instead of 1. For hubs the feature is
0112 automatically and permanently enabled and the power/persist file
0113 doesn't even exist, so you only have to worry about setting it for
0114 devices where it really matters.
0115
0116
0117 Is this the best solution?
0118 ==========================
0119
0120 Perhaps not. Arguably, keeping track of mounted filesystems and
0121 memory mappings across device disconnects should be handled by a
0122 centralized Logical Volume Manager. Such a solution would allow you
0123 to plug in a USB flash device, create a persistent volume associated
0124 with it, unplug the flash device, plug it back in later, and still
0125 have the same persistent volume associated with the device. As such
0126 it would be more far-reaching than USB-persist.
0127
0128 On the other hand, writing a persistent volume manager would be a big
0129 job and using it would require significant input from the user. This
0130 solution is much quicker and easier -- and it exists now, a giant
0131 point in its favor!
0132
0133 Furthermore, the USB-persist feature applies to _all_ USB devices, not
0134 just mass-storage devices. It might turn out to be equally useful for
0135 other device types, such as network interfaces.
0136
0137
0138 WARNING: USB-persist can be dangerous!!
0139 =======================================
0140
0141 When recovering an interrupted power session the kernel does its best
0142 to make sure the USB device hasn't been changed; that is, the same
0143 device is still plugged into the port as before. But the checks
0144 aren't guaranteed to be 100% accurate.
0145
0146 If you replace one USB device with another of the same type (same
0147 manufacturer, same IDs, and so on) there's an excellent chance the
0148 kernel won't detect the change. The serial number string and other
0149 descriptors are compared with the kernel's stored values, but this
0150 might not help since manufacturers frequently omit serial numbers
0151 entirely in their devices.
0152
0153 Furthermore it's quite possible to leave a USB device exactly the same
0154 while changing its media. If you replace the flash memory card in a
0155 USB card reader while the system is asleep, the kernel will have no
0156 way to know you did it. The kernel will assume that nothing has
0157 happened and will continue to use the partition tables, inodes, and
0158 memory mappings for the old card.
0159
0160 If the kernel gets fooled in this way, it's almost certain to cause
0161 data corruption and to crash your system. You'll have no one to blame
0162 but yourself.
0163
0164 For those devices with avoid_reset_quirk attribute being set, persist
0165 maybe fail because they may morph after reset.
0166
0167 YOU HAVE BEEN WARNED! USE AT YOUR OWN RISK!
0168
0169 That having been said, most of the time there shouldn't be any trouble
0170 at all. The USB-persist feature can be extremely useful. Make the
0171 most of it.
