aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/usb
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/usb')
-rw-r--r--Documentation/usb/persist.txt144
1 files changed, 144 insertions, 0 deletions
diff --git a/Documentation/usb/persist.txt b/Documentation/usb/persist.txt
new file mode 100644
index 000000000000..6dcd5f884795
--- /dev/null
+++ b/Documentation/usb/persist.txt
@@ -0,0 +1,144 @@
1 USB device persistence during system suspend
2
3 Alan Stern <stern@rowland.harvard.edu>
4
5 September 2, 2006 (Updated March 27, 2007)
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 suspend-to-disk (also known as swsusp). You can
56check the kernel log after resuming to see if either of these has
57happened; 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
68Setting CONFIG_USB_PERSIST will cause the kernel to work around these
69issues. It enables a mode in which the core USB device data
70structures are allowed to persist across a power-session disruption.
71It works like this. If the kernel sees that a USB host controller is
72not in the expected state during resume (i.e., if the controller was
73reset or otherwise had lost power) then it applies a persistence check
74to each of the USB devices below that controller. It doesn't try to
75resume the device; that can't work once the power session is gone.
76Instead it issues a USB port reset and then re-enumerates the device.
77(This is exactly the same thing that happens whenever a USB device is
78reset.) If the re-enumeration shows that the device now attached to
79that port has the same descriptors as before, including the Vendor and
80Product IDs, then the kernel continues to use the same device
81structure. In effect, the kernel treats the device as though it had
82merely been reset instead of unplugged.
83
84If no device is now attached to the port, or if the descriptors are
85different from what the kernel remembers, then the treatment is what
86you would expect. The kernel destroys the old device structure and
87behaves as though the old device had been unplugged and a new device
88plugged in, just as it would without the CONFIG_USB_PERSIST option.
89
90The end result is that the USB device remains available and usable.
91Filesystem mounts and memory mappings are unaffected, and the world is
92now a good and happy place.
93
94
95 Is this the best solution?
96
97Perhaps not. Arguably, keeping track of mounted filesystems and
98memory mappings across device disconnects should be handled by a
99centralized Logical Volume Manager. Such a solution would allow you
100to plug in a USB flash device, create a persistent volume associated
101with it, unplug the flash device, plug it back in later, and still
102have the same persistent volume associated with the device. As such
103it would be more far-reaching than CONFIG_USB_PERSIST.
104
105On the other hand, writing a persistent volume manager would be a big
106job and using it would require significant input from the user. This
107solution is much quicker and easier -- and it exists now, a giant
108point in its favor!
109
110Furthermore, the USB_PERSIST option applies to _all_ USB devices, not
111just mass-storage devices. It might turn out to be equally useful for
112other device types, such as network interfaces.
113
114
115 WARNING: Using CONFIG_USB_PERSIST can be dangerous!!
116
117When recovering an interrupted power session the kernel does its best
118to make sure the USB device hasn't been changed; that is, the same
119device is still plugged into the port as before. But the checks
120aren't guaranteed to be 100% accurate.
121
122If you replace one USB device with another of the same type (same
123manufacturer, same IDs, and so on) there's an excellent chance the
124kernel won't detect the change. Serial numbers and other strings are
125not compared. In many cases it wouldn't help if they were, because
126manufacturers frequently omit serial numbers entirely in their
127devices.
128
129Furthermore it's quite possible to leave a USB device exactly the same
130while changing its media. If you replace the flash memory card in a
131USB card reader while the system is asleep, the kernel will have no
132way to know you did it. The kernel will assume that nothing has
133happened and will continue to use the partition tables, inodes, and
134memory mappings for the old card.
135
136If the kernel gets fooled in this way, it's almost certain to cause
137data corruption and to crash your system. You'll have no one to blame
138but yourself.
139
140YOU HAVE BEEN WARNED! USE AT YOUR OWN RISK!
141
142That having been said, most of the time there shouldn't be any trouble
143at all. The "persist" feature can be extremely useful. Make the most
144of it.