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