lkml.org 
[lkml]   [2012]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: USB enumeration post-resume NOT persistent yet "persist" --> swapped devices nodes --> root partition reference broken
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



\
 
 \ /
  Last update: 2012-07-19 17:41    [from the cache]
©2003-2011 Jasper Spaans