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