Lines Matching refs:the
8 What is the problem?
10 According to the USB specification, when a USB bus is suspended the
16 If a USB device's power session is interrupted then the system is
17 required to behave as though the device has been unplugged. It's a
18 conservative approach; in the absence of suspend current the computer
19 has no way to know what has actually happened. Perhaps the same
21 device plugged into the port. The system must assume the worst.
23 By default, Linux behaves according to the spec. If a USB host
24 controller loses power during a system suspend, then when the system
25 wakes up all the devices attached to that controller are treated as
26 though they had disconnected. This is always safe and it is the
29 For many sorts of devices this behavior doesn't matter in the least.
30 If the kernel wants to believe that your USB keyboard was unplugged
31 while the system was asleep and a new keyboard was plugged in when the
32 system woke up, who cares? It'll still work the same when you type on
36 devices. The effect is exactly the same as if the device really had
37 been unplugged while the system was suspended. If you had a mounted
38 filesystem on the device, you're out of luck -- everything in that
40 root filesystem was located on the device, since your system will
43 Loss of power isn't the only mechanism to worry about. Anything that
44 interrupts a power session will have the same effect. For example,
45 even though suspend current may have been maintained while the system
46 was asleep, on many systems during the initial stages of wakeup the
47 firmware (i.e., the BIOS) resets the motherboard's USB host
48 controllers. Result: all the power sessions are destroyed and again
49 it's as though you had unplugged all the USB devices. Yes, it's
50 entirely the BIOS's fault, but that doesn't do _you_ any good unless
51 you can convince the BIOS supplier to fix the problem (lots of luck!).
53 On many systems the USB host controllers will get reset after a
56 You can check the kernel log after resuming to see if either of these
60 device before suspending. If the root filesystem is on a USB device,
61 the system can't be suspended at all. (All right, it _can_ be
66 What is the solution?
69 around these issues by allowing the core USB device data structures to
72 It works like this. If the kernel sees that a USB host controller is
73 not in the expected state during resume (i.e., if the controller was
75 to 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
77 can't work once the power session is gone. Instead it issues a USB
78 port reset and then re-enumerates the device. (This is exactly the
79 same thing that happens whenever a USB device is reset.) If the
80 re-enumeration shows that the device now attached to that port has the
81 same descriptors as before, including the Vendor and Product IDs, then
82 the kernel continues to use the same device structure. In effect, the
83 kernel treats the device as though it had merely been reset instead of
86 The same thing happens if the host controller is in the expected state
90 If no device is now attached to the port, or if the descriptors are
91 different from what the kernel remembers, then the treatment is what
92 you would expect. The kernel destroys the old device structure and
93 behaves as though the old device had been unplugged and a new device
96 The end result is that the USB device remains available and usable.
97 Filesystem mounts and memory mappings are unaffected, and the world is
100 Note that the "USB-persist" feature will be applied only to those
101 devices for which it is enabled. You can enable the feature by doing
106 where the "..." should be filled in the with the device's ID. Disable
107 the feature by writing 0 instead of 1. For hubs the feature is
108 automatically and permanently enabled and the power/persist file
113 Is this the best solution?
119 with it, unplug the flash device, plug it back in later, and still
120 have the same persistent volume associated with the device. As such
123 On the other hand, writing a persistent volume manager would be a big
124 job and using it would require significant input from the user. This
128 Furthermore, the USB-persist feature applies to _all_ USB devices, not
135 When recovering an interrupted power session the kernel does its best
136 to make sure the USB device hasn't been changed; that is, the same
137 device is still plugged into the port as before. But the checks
140 If you replace one USB device with another of the same type (same
141 manufacturer, same IDs, and so on) there's an excellent chance the
142 kernel won't detect the change. The serial number string and other
143 descriptors are compared with the kernel's stored values, but this
147 Furthermore it's quite possible to leave a USB device exactly the same
148 while changing its media. If you replace the flash memory card in a
149 USB card reader while the system is asleep, the kernel will have no
151 happened and will continue to use the partition tables, inodes, and
152 memory mappings for the old card.
154 If the kernel gets fooled in this way, it's almost certain to cause
163 That having been said, most of the time there shouldn't be any trouble
164 at all. The USB-persist feature can be extremely useful. Make the