[lkml]   [2012]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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?

    > 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    [W:0.052 / U:13.668 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site