USB enumeration post-resume NOT persistent yet "persist" --> swappeddevices nodes --> root partition reference broken

[Andreas Mohr]

Hi,

Yesterday I was surprised to see that with *another* external USB disk
happening to be connected before boot,
the system booted with root partition device sdb1 assigned rather than sda1.
Not thinking much, I then proceeded putting the system into suspend,
only to be even more surprised to then end up with swapped device nodes
post-resume and the system killed
(I *know* that device nodes ended up jumbled since the root device contains
"root" plus "swap" partition device node, whereas the "other" USB device
contains one partition only,
and the set of partition device nodes as still successfully looked up via
ls -l /dev/sd*
ended up exactly reversed after system resume).
I attempted to get dmesg off this system, however not even plain sector writing
of my /tmp/dmesg.log to a new USB device worked since "dd" segfaulted.
Also, no network access of course.

http://lists.linux-foundation.org/pipermail/linux-pm/2009-November/023101.html
talks about this case, and mentions Documentation/usb/persist.txt
as the most authoritative document.

The thing is, /sys persist nodes *are* all set to 1 for any affected
device (at least as observed after the subsequent fresh boot).

The plausibility of the previous killed boot having had "persist"
attribute set as well for all devices is VERY high
(there were no changes/updates in system software configuration done,
thus settings should have been identical).

Thus I'm highly puzzled as to why with USB persistence *activated*
it still decided to jumble device nodes on this system resume.
Content of the pathological dmesg log didn't contain any mentioning
of any "persistence" mechanism activity, BTW, AFAIR.

Device identification *is* as unique as it gets:

# lsusb 
Bus 001 Device 005: ID 174c:55aa ASMedia Technology Inc. 
Bus 001 Device 002: ID 152d:0601 JMicron Technology Corp. / JMicron USA Technology Corp. 
Bus 001 Device 004: ID 064e:d101 Suyin Corp. Acer CrystalEye Webcam
Bus 003 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

andinet sys # find . -name "*persist*"
./devices/pci0000:00/0000:00:1c.2/0000:03:00.0/ieee80211/phy0/rfkill1/persistent
./devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/bluetooth/hci0/rfkill0/persistent
./devices/pci0000:00/0000:00:1d.1/usb3/3-2/power/persist
./devices/pci0000:00/0000:00:1d.7/usb1/1-1/power/persist
./devices/pci0000:00/0000:00:1d.7/usb1/1-2/power/persist
./devices/pci0000:00/0000:00:1d.7/usb1/1-5/power/persist
andinet sys # cat ./devices/pci0000:00/0000:00:1d.7/usb1/1-2/product
TS32GSSD18M-M
andinet sys # cat ./devices/pci0000:00/0000:00:1d.7/usb1/1-2/power/persist
1
andinet sys # cat ./devices/pci0000:00/0000:00:1d.7/usb1/1-5/product
Acer Crystal Eye webcam
andinet sys # cat ./devices/pci0000:00/0000:00:1d.7/usb1/1-5/power/persist
1
andinet sys # cat ./devices/pci0000:00/0000:00:1d.7/usb1/1-1/product
MEDION HDDrive-n-GO
andinet sys # cat ./devices/pci0000:00/0000:00:1d.7/usb1/1-1/power/persist
1

(TS32GSSD18M-M is USB-connected root partition SSD)


Netbook Acer Aspire One A110L.
Running 3.5.0-rc7+ here (yes ma'am, bleeding edge tester :).
Was the first time to attempt resume with an additional device remaining
connected, IIRC - that -rc7 thing likely doesn't play much of a role here.
A bit hesitant to (dis-)prove the bug's "regression flag" with another version
since random possibly succeeding I/O accesses to incompatible devices
are not necessarily my thing (or is this safe to attempt again? Any more
specific session info one would need?).

So, again, possibly USB persistence is bug-broken?

Posted to linux-usb (discussion) and lkml (kernel bug?).

Thanks,

Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/