On Thu, 19 Jul 2012, Andreas Mohr wrote: > 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, Do you mean "suspend" or "hibernate"? > 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). That shouldn't happen in any case, but it seems more likely to happen after hibernation than after suspend. > 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. Can you reproduce the problem? > 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 ... > 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?). Well, the dmesg log would help. If you still think the USB layer is at fault then you should enable CONFIG_USB_DEBUG. > So, again, possibly USB persistence is bug-broken? You don't have any good evidence to suggest that. None of the information you provided indicates that any USB device nodes (such as /dev/bus/usb/001/002) got mixed up. All you know is that the block-layer device nodes (such as /dev/sda2) got changed. Furthermore, if USB persist were broken then the symptoms would be different. Instead of starting with a root partition at sdb1 and then finding it at sda1, you would have found it gone completely and there would be _new_ devices labelled sdc and sdd. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
