Re: USB enumeration post-resume NOT persistent yet "persist" -->swapped devices nodes --> root partition reference broken

[Alan Stern]

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-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/