About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / usb / persist.txt




Custom Search

Based on kernel version 3.13. Page generated on 2014-01-20 22:04 EST.

1			USB device persistence during system suspend
2	
3			   Alan Stern <stern@rowland.harvard.edu>
4	
5			September 2, 2006 (Updated February 25, 2008)
6	
7	
8		What is the problem?
9	
10	According to the USB specification, when a USB bus is suspended the
11	bus must continue to supply suspend current (around 1-5 mA).  This
12	is so that devices can maintain their internal state and hubs can
13	detect connect-change events (devices being plugged in or unplugged).
14	The technical term is "power session".
15	
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
20	device is still attached or perhaps it was removed and a different
21	device plugged into the port.  The system must assume the worst.
22	
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
27	"officially correct" thing to do.
28	
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
33	it.
34	
35	Unfortunately problems _can_ arise, particularly with mass-storage
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
39	filesystem is now inaccessible.  This is especially annoying if your
40	root filesystem was located on the device, since your system will
41	instantly crash.
42	
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!).
52	
53	On many systems the USB host controllers will get reset after a
54	suspend-to-RAM.  On almost all systems, no suspend current is
55	available during hibernation (also known as swsusp or suspend-to-disk).
56	You can check the kernel log after resuming to see if either of these
57	has happened; look for lines saying "root hub lost power or was reset".
58	
59	In practice, people are forced to unmount any filesystems on a USB
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
62	suspended -- but it will crash as soon as it wakes up, which isn't
63	much better.)
64	
65	
66		What is the solution?
67	
68	The kernel includes a feature called USB-persist.  It tries to work
69	around these issues by allowing the core USB device data structures to
70	persist across a power-session disruption.
71	
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
74	reset or otherwise had lost power) then it applies a persistence check
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
84	unplugged.
85	
86	The same thing happens if the host controller is in the expected state
87	but a USB device was unplugged and then replugged, or if a USB device
88	fails to carry out a normal resume.
89	
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
94	plugged in.
95	
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
98	now a good and happy place.
99	
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
102	(as root):
103	
104		echo 1 >/sys/bus/usb/devices/.../power/persist
105	
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
109	doesn't even exist, so you only have to worry about setting it for
110	devices where it really matters.
111	
112	
113		Is this the best solution?
114	
115	Perhaps not.  Arguably, keeping track of mounted filesystems and
116	memory mappings across device disconnects should be handled by a
117	centralized Logical Volume Manager.  Such a solution would allow you
118	to plug in a USB flash device, create a persistent volume associated
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
121	it would be more far-reaching than USB-persist.
122	
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
125	solution is much quicker and easier -- and it exists now, a giant
126	point in its favor!
127	
128	Furthermore, the USB-persist feature applies to _all_ USB devices, not
129	just mass-storage devices.  It might turn out to be equally useful for
130	other device types, such as network interfaces.
131	
132	
133		WARNING: USB-persist can be dangerous!!
134	
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
138	aren't guaranteed to be 100% accurate.
139	
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
144	might not help since manufacturers frequently omit serial numbers
145	entirely in their devices.
146	
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
150	way to know you did it.  The kernel will assume that nothing has
151	happened and will continue to use the partition tables, inodes, and
152	memory mappings for the old card.
153	
154	If the kernel gets fooled in this way, it's almost certain to cause
155	data corruption and to crash your system.  You'll have no one to blame
156	but yourself.
157	
158	For those devices with avoid_reset_quirk attribute being set, persist
159	maybe fail because they may morph after reset.
160	
161	YOU HAVE BEEN WARNED!  USE AT YOUR OWN RISK!
162	
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
165	most of it.
Hide Line Numbers
About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.