USB device just moves - Linux

This is a discussion on USB device just moves - Linux ; I had a case today where an external disk drive connected via USB just up and moved to a new device location. The dmesg log looks like it came loose on its own and reconnected immediately. But it seems the ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: USB device just moves

  1. USB device just moves

    I had a case today where an external disk drive connected via USB just up
    and moved to a new device location. The dmesg log looks like it came loose
    on its own and reconnected immediately. But it seems the device name it
    had before was not re-usabled and it got a new one. It was a mounted disk
    so you can imagine the mess that caused.

    This is a good example of how that legacy unix principle of assigning device
    names in probe order is still a bad idea. I've complained about it before
    Linux even existed. The whole unix principle does so many things right.
    But this is one that is not.

    Today it is so much more complicated because now things run on the most
    chaotic computer architecture ever devised: the PC. So I don't think a
    clean solution is likely. I sure don't want to propose a dirty one. So
    all I can suggest is to replace the PC itself. And you can just imagine
    how hard even that chore would be.

    A new clean architecture would have finite and small (but plenty large
    enough for the biggest possible machine we cannot yet even imagine) scope
    of device addressing. It also needs to be static and consistent. If a
    device is plugged in at some given physical location, it will have some
    absolute physical hardware address that stays the same as long as it is
    in that location. That would be in addition to a permanent fixed logical
    address the device itself keeps (like a serial number or like ethernet
    has in the form of MAC addresses).

    Perhaps the most painful aspect, and illustation of greatest stupidity in
    the PC architecture, and one that seems to have been copied in a few other
    architectures since then, is the chaos of interrupts that do not have any
    association with exactly where they came from. A sane architecture will
    always track (in an interrupt controller perhaps) exactly which device(s)
    have presented interrupts using the very same absolute device address that
    is used to initiate I/O operations. There must not be ambiguity as to
    where an interrupt comes from.

    It is perhaps better to just eliminate, for the majority of devices, any
    sort of device register control and interrupt operation as a design of a
    new architecture. Instead, I suggest a message bus based system that is
    designed with the new architecture. Anything attached to the architecture
    must use that message bus format (all the way from device to OS driver),
    even if that means it is translating everything to some external type of
    interface. It needs to be a new, clean, and of course open, design.

    Maybe our great grandchildren might start actually doing such a design.
    Maybe their great grandchildren might enjoy the benefits of it. Clearly
    such changes would be a daunting task, especially considering so many of
    the special interests devoted to maintaining chaos in the PC architecture
    and some others modeled after it.

    This whole post should have been on a blog. But I don't have one which
    would be where people would expect to see it. Maybe I should create one.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-02-10-0735@ipal.net |
    |------------------------------------/-------------------------------------|

  2. Re: USB device just moves

    On Feb 10, 1:59 pm, phil-news-nos...@ipal.net wrote:

    > This is a good example of how that legacy unix principle of assigning device
    > names in probe order is still a bad idea.


    But, if I understand correctly, is it not supposed to be possible to
    chain USB devices together somehow, using only one computer USB port?

    -Mike

  3. Re: USB device just moves

    On Mon, 11 Feb 2008 10:38:13 -0800 (PST) Mike wrote:

    | On Feb 10, 1:59 pm, phil-news-nos...@ipal.net wrote:
    |
    |> This is a good example of how that legacy unix principle of assigning device
    |> names in probe order is still a bad idea.
    |
    | But, if I understand correctly, is it not supposed to be possible to
    | chain USB devices together somehow, using only one computer USB port?

    USB hubs exist. Plug a hub into a computer USB port. You get multiple USB
    ports. I have one that has 3 USB ports plus 4 memory card slots in the same
    device. I've plugged external drives and USB keys in all three at the same
    time. Of course that is now sharing the bandwidth of the one connection to
    the computer. Otherwise I can get full speed on each USB port my computer
    has (4 in back, 2 in front) concurrently (tested with the 4 in back at the
    same time).

    When this kind of "fan out" is done, there should be a _physical_ address
    that also fans out, with a new range of numbers appended to the address of
    the hub itself (maybe starting at .1 so the hub itself can be accessed at
    the .0 subaddress). Maybe USB is doing this kind of thing behind the scenes.
    But there is no indication of that at the OS level. It seems USB addresses
    are dyanmically assigned. So I would guess the computer has no idea where
    a USB device is plugged in, beyond the ports it has on itself, and either
    the messages are broadcast over hubs, or the hub is smart enough to track
    the dynamic addresses and send things the right way.

    I'm sure someone will say I should read the USB standards docs. But I do
    not want the mental pollution. I'd rather design my own.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-02-11-1645@ipal.net |
    |------------------------------------/-------------------------------------|

  4. Re: USB device just moves

    phil-news-nospam@ipal.net wrote:
    >
    >I had a case today where an external disk drive connected via USB just up
    >and moved to a new device location. The dmesg log looks like it came loose
    >on its own and reconnected immediately. But it seems the device name it
    >had before was not re-usabled and it got a new one. It was a mounted disk
    >so you can imagine the mess that caused.


    The "udev" subsystem seems to go a very long way towards solving this
    problem. I believe it would have prevented the issue you describe. Is
    your kernel new enough to support it?
    --
    Tim Roberts, timr@probo.com
    Providenza & Boekelheide, Inc.

  5. Re: USB device just moves

    On Tue, 12 Feb 2008 07:19:31 GMT Tim Roberts wrote:
    | phil-news-nospam@ipal.net wrote:
    |>
    |>I had a case today where an external disk drive connected via USB just up
    |>and moved to a new device location. The dmesg log looks like it came loose
    |>on its own and reconnected immediately. But it seems the device name it
    |>had before was not re-usabled and it got a new one. It was a mounted disk
    |>so you can imagine the mess that caused.
    |
    | The "udev" subsystem seems to go a very long way towards solving this
    | problem. I believe it would have prevented the issue you describe. Is
    | your kernel new enough to support it?

    The kernel is new enough ... 2.6.24 (no worry over vmsplice here).

    So tell me how it is that "udev" can do better than the kernel itself to
    make sure that when the USB device is re-attached that it will always get
    exactly the same major/minor device number? I thought that what "udev"
    did was automatically make a device node in the name space to refer to
    the new major/minor. Remember, this involves an already mounted filesystem
    with files still open.

    The real culprit in this is the poor design of USB, which follows the poor
    design of PC. There should be a hardware layer consistency of addresses
    based on where something is plugged in (bus number, controller number, port
    number, hub port number, hubbed hub port number, etc). Then on top of that
    there should be consistent device ID numbers much like ethernet MAC (but at
    least 64 bits). If the same device is plugged back into the same port, no
    address should change. Nothing should need to be run to "change it back"
    as it should just _be_ the same. If I move a drive from one port to another
    that should be handled inside the kernel simply by having an association from
    devices as the kernel sees them (major/minor number) to the consistent device
    address (the one built into the device, not the port itself).

    But since we have a poor hardware design, we have to bend over backwards in
    the software to make things work at least reasonably most of the time.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-02-12-0843@ipal.net |
    |------------------------------------/-------------------------------------|

  6. Re: USB device just moves

    phil-news-nospam@ipal.net wrote:
    >
    >So tell me how it is that "udev" can do better than the kernel itself to
    >make sure that when the USB device is re-attached that it will always get
    >exactly the same major/minor device number? I thought that what "udev"
    >did was automatically make a device node in the name space to refer to
    >the new major/minor. Remember, this involves an already mounted filesystem
    >with files still open.


    Well, perhaps I misunderstood (or underestimated) the issue. Your
    description of udev is correct. If the major/minor number is critical,
    than perhaps udev doesn't help.

    >The real culprit in this is the poor design of USB, which follows the poor
    >design of PC. There should be a hardware layer consistency of addresses
    >based on where something is plugged in (bus number, controller number, port
    >number, hub port number, hubbed hub port number, etc). Then on top of that
    >there should be consistent device ID numbers much like ethernet MAC (but at
    >least 64 bits). If the same device is plugged back into the same port, no
    >address should change. Nothing should need to be run to "change it back"
    >as it should just _be_ the same.


    There's nothing wrong with the design of USB. As long as the device has a
    serial number, the combination of VID, PID, and serial number is unique,
    and Windows (at least) will recognize it as the same device no matter what
    port of which hub it is plugged into.
    --
    Tim Roberts, timr@probo.com
    Providenza & Boekelheide, Inc.

  7. Re: USB device just moves

    phil-news-nospam@ipal.net wrote:

    > On Mon, 11 Feb 2008 10:38:13 -0800 (PST) Mike
    > wrote:
    >
    > | On Feb 10, 1:59 pm, phil-news-nos...@ipal.net wrote:
    > |
    > |> This is a good example of how that legacy unix principle of assigning
    > |> device names in probe order is still a bad idea.
    > |
    > | But, if I understand correctly, is it not supposed to be possible to
    > | chain USB devices together somehow, using only one computer USB port?
    >
    > USB hubs exist. Plug a hub into a computer USB port. You get multiple USB
    > ports. I have one that has 3 USB ports plus 4 memory card slots in the same
    > device. I've plugged external drives and USB keys in all three at the same
    > time. Of course that is now sharing the bandwidth of the one connection to
    > the computer. Otherwise I can get full speed on each USB port my computer
    > has (4 in back, 2 in front) concurrently (tested with the 4 in back at the
    > same time).
    >
    > When this kind of "fan out" is done, there should be a _physical_ address
    > that also fans out, with a new range of numbers appended to the address of
    > the hub itself (maybe starting at .1 so the hub itself can be accessed at
    > the .0 subaddress). Maybe USB is doing this kind of thing behind the
    > scenes.
    > But there is no indication of that at the OS level. It seems USB addresses
    > are dyanmically assigned. So I would guess the computer has no idea where
    > a USB device is plugged in, beyond the ports it has on itself, and either
    > the messages are broadcast over hubs, or the hub is smart enough to track
    > the dynamic addresses and send things the right way.
    >
    > I'm sure someone will say I should read the USB standards docs. But I do
    > not want the mental pollution. I'd rather design my own.
    >

    USB is a really terrible architecture, lowers performance of the computer in
    general, and hopefully someday it will be replaced with something interrupt
    driven. USB addresses are assigned as the system finds them the device itself
    doesnt care a wit what address it gets as long as it gets on.
    USB must be polled at regular intervals, if a so called interrupt packet is
    received (after it was polled for) then an SMI handler is invoked, and while
    that handler is running **ALL** other code execution stops dead! This can
    happen many times a second depending on whats connected and the system
    design.
    The usb keyboard is the worst offender with a transaction going something like
    this:
    pc formats and sends packet to keyboard -> do you have a key for me?
    pc formats and sends packet to keyboard -> do you have a key for me?
    pc formats and sends packet to keyboard -> do you have a key for me?
    pc formats and sends packet to keyboard -> do you have a key for me?
    pc formats and sends packet to keyboard -> do you have a key for me?
    pc formats and sends packet to keyboard -> do you have a key for me?
    -- repeated 50 - 100 times a second --
    keyboard sends data back with keystroke to pc
    USB controller invokes SMM (system management mode). Entire PC (all cores)
    stops executing code or interrupts and starts executing SMI handler
    SMI handler stuffs key data into 8249 keyboard controller.
    SMI handler ends
    An interrupt is generated either by or on behalf of the keyboard controller
    8249 keyboard.
    PC reads 8249 and retrieves key data

    Is this insane or what?
    Eric

  8. Re: USB device just moves

    Eric writes:

    [...]

    > USB is a really terrible architecture, lowers performance of the computer in
    > general, and hopefully someday it will be replaced with something interrupt
    > driven.


    USB is basically a polled LAN-technology where the host passes a token
    to each device one after another, and the device currently owning the
    token may then send or receive data over the USB. While this is the
    typical brain damage hardware people come up with and nobody is using
    these approach on actual LANs anymore, the implementation is not as
    bad as you believe it to be. The polling-nonsense is completely
    implemented in hardware (that's what the host controller does) and the
    interface to system software is an 'ordinary', shared-interrupt driven
    one.

    [...]

    > USB must be polled at regular intervals, if a so called interrupt packet is
    > received (after it was polled for) then an SMI handler is invoked, and while
    > that handler is running **ALL** other code execution stops dead!
    > This can happen many times a second depending on whats connected and the system
    > design. The usb keyboard is the worst offender with a transaction going something like
    > this:


    > pc formats and sends packet to keyboard -> do you have a key for me?


    [...]

    > -- repeated 50 - 100 times a second --


    A so-called 'USB interrupt endpoint' is supposed to be polled by the
    host controller at a certain frequency. The USB-keyboard I am using
    specifies 10ms, meaning, it is polled every tenth USB frame interval
    (1ms), 100 times per second in total, BUT (as I wrote above), this is
    done by the host controller independently of what the other parts of
    the PC are doing. Assuming the host controller receives a reply
    instead of a NAK-handshake, it causes an interrupt to the hcd (host
    controller driver), which will then call the completion handler of the
    URB (USB request block) the keyboard driver had submitted for its
    particular endpoint. The (USB) keyboard driver then extracts
    information about key presses from the data payload of the URB and
    forwards it to the appropiate kernel subsystem (this is heavily
    simplified, but generally correct).

  9. Re: USB device just moves

    On Thu, 14 Feb 2008 05:22:55 GMT Tim Roberts wrote:
    | phil-news-nospam@ipal.net wrote:
    |>
    |>So tell me how it is that "udev" can do better than the kernel itself to
    |>make sure that when the USB device is re-attached that it will always get
    |>exactly the same major/minor device number? I thought that what "udev"
    |>did was automatically make a device node in the name space to refer to
    |>the new major/minor. Remember, this involves an already mounted filesystem
    |>with files still open.
    |
    | Well, perhaps I misunderstood (or underestimated) the issue. Your
    | description of udev is correct. If the major/minor number is critical,
    | than perhaps udev doesn't help.

    Would it not be critical if that major/minor is a block device that is
    currently mounted?


    |>The real culprit in this is the poor design of USB, which follows the poor
    |>design of PC. There should be a hardware layer consistency of addresses
    |>based on where something is plugged in (bus number, controller number, port
    |>number, hub port number, hubbed hub port number, etc). Then on top of that
    |>there should be consistent device ID numbers much like ethernet MAC (but at
    |>least 64 bits). If the same device is plugged back into the same port, no
    |>address should change. Nothing should need to be run to "change it back"
    |>as it should just _be_ the same.
    |
    | There's nothing wrong with the design of USB. As long as the device has a
    | serial number, the combination of VID, PID, and serial number is unique,
    | and Windows (at least) will recognize it as the same device no matter what
    | port of which hub it is plugged into.

    So are you saying the Linux USB driver design is all wrong?

    If I had designed these things, I would have started at the computer bus
    level and made as many things as possible message based, with the only
    polling to be as a result of a timeout (expected a message but none has
    arrived, so ask in case it sent it and somehow it was lost, much like
    TCP does).

    People whose first experience in computer architecture is the PC are doomed
    to create bad designs, unless they learn from the beginning that the PC is
    a terrible architecture.

    The bad design of USB extends all the way to a PoS connector, too.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-02-14-1133@ipal.net |
    |------------------------------------/-------------------------------------|

  10. Re: USB device just moves

    Eric wrote:
    >
    >USB must be polled at regular intervals,...


    Interrupt and isochronous pipes must be polled at regular intervals. Other
    pipe types do not.

    >...if a so called interrupt packet is
    >received (after it was polled for) then an SMI handler is invoked, and while
    >that handler is running **ALL** other code execution stops dead!


    Oh, come on. Who told you that? Once an operating system is running, a
    USB host controller is just a standard PCI device with a standard
    interrupt-based DMA transfer scheme. SMI is not involved.

    >This can happen many times a second depending on whats connected and the
    >system design.
    >The usb keyboard is the worst offender with a transaction going something like
    >this:
    >pc formats and sends packet to keyboard -> do you have a key for me?
    >...
    >pc formats and sends packet to keyboard -> do you have a key for me?
    >-- repeated 50 - 100 times a second --
    >keyboard sends data back with keystroke to pc
    >USB controller invokes SMM (system management mode). Entire PC (all cores)
    >stops executing code or interrupts and starts executing SMI handler
    >SMI handler stuffs key data into 8249 keyboard controller.
    >SMI handler ends
    >An interrupt is generated either by or on behalf of the keyboard controller
    >8249 keyboard.
    >PC reads 8249 and retrieves key data
    >
    >Is this insane or what?


    That kind of BIOS magic might be needed to simulate the 8249 keyboard
    controller at boot time, but once an operating system loads, all of that
    goes out the window. It's just a standard PCI device using standard PCI
    interrupts. No SMI.

    There is nothing inherently wrong with a polled, dedicated master/slave bus
    design. It avoids all the problems of assigning a bus master or handling
    collisions among multiple senders.
    --
    Tim Roberts, timr@probo.com
    Providenza & Boekelheide, Inc.

  11. Re: USB device just moves

    phil-news-nospam@ipal.net wrote:
    >
    >On Thu, 14 Feb 2008 05:22:55 GMT Tim Roberts wrote:
    >|
    >| There's nothing wrong with the design of USB. As long as the device has a
    >| serial number, the combination of VID, PID, and serial number is unique,
    >| and Windows (at least) will recognize it as the same device no matter what
    >| port of which hub it is plugged into.
    >
    >So are you saying the Linux USB driver design is all wrong?


    From your description, it sounds to me like it's the major/minor number
    scheme that is the root of your trouble.
    --
    Tim Roberts, timr@probo.com
    Providenza & Boekelheide, Inc.

  12. Re: USB device just moves

    On Sun, 17 Feb 2008 01:01:02 GMT Tim Roberts wrote:
    | phil-news-nospam@ipal.net wrote:
    |>
    |>On Thu, 14 Feb 2008 05:22:55 GMT Tim Roberts wrote:
    |>|
    |>| There's nothing wrong with the design of USB. As long as the device has a
    |>| serial number, the combination of VID, PID, and serial number is unique,
    |>| and Windows (at least) will recognize it as the same device no matter what
    |>| port of which hub it is plugged into.
    |>
    |>So are you saying the Linux USB driver design is all wrong?
    |
    | From your description, it sounds to me like it's the major/minor number
    | scheme that is the root of your trouble.

    It's a factor. Looking at the design, it appears that major/minor changes
    when the hardware appears to be a new device. The USB design allows that
    to take place. Both need to be fixed. Problems will persist if not.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-02-16-2127@ipal.net |
    |------------------------------------/-------------------------------------|

  13. Re: USB device just moves

    Tim Roberts writes:
    > Eric wrote:
    >>USB must be polled at regular intervals,...

    >
    > Interrupt and isochronous pipes must be polled at regular intervals. Other
    > pipe types do not.


    Your first statements means nothing more than 'USB must be polled at
    regular intervals'. Assuming there are neither interrupt (unlikely)
    nor isosychronous endpoints active on any device connected to some
    USB, what is left would basically be bulk in- out out-pipes, which
    only need to be 'polled at regular intervals' if one actually wants to
    receive or transmit data over the USB. Therefore, the only USB not
    being 'polled at regular intervals' is one without used devices
    connected to ti.

    [...]

    > There is nothing inherently wrong with a polled, dedicated master/slave bus
    > design.


    There was nothing wrong with the various token-passing based LAN
    technologies people considered to be a good idea (more than) twenty
    years ago, either. But for some mysterious reason, they have basically
    completely disappeared from the market.

    > It avoids all the problems of assigning a bus master or handling
    > collisions among multiple senders.


    And there were lots and lots of wrongs inherent in CSMA/CD networks,
    but again, for some mysterious reasons, they were cheap and worked
    well in practice. But they were invented at a time when putting all of
    the practically stupid 'intelligent design' into mass-produced and
    therefore cheap ICs wasn't even possible. That's why it took some
    twenty years of technical progress until the 'intelligent design'
    finally became the chance to again rise from its well-deserved grave,
    where it rather should have been rested until kingdom come.

    The PS/2-mouse connected to my computer at work is a true real-time
    capable device, ie it 'works' whenever I move it. The USB-mouse I have
    at home cannot do that: If it has been inactive for some time, there
    is a noticable delay between the time I try to use it again and the
    time it actually reacts.

    A design which needs lots of high-developed components which are
    literally busy doing nothing almost all of the time is stupid.

    That it can be produced cheaply, given that the right proponents are
    pushing it and works 'good enough' doesn't make it any less stupid.


  14. Re: USB device just moves

    On Sun, 17 Feb 2008 13:32:29 +0100 Rainer Weikusat wrote:
    | Tim Roberts writes:
    |> Eric wrote:
    |>>USB must be polled at regular intervals,...
    |>
    |> Interrupt and isochronous pipes must be polled at regular intervals. Other
    |> pipe types do not.
    |
    | Your first statements means nothing more than 'USB must be polled at
    | regular intervals'. Assuming there are neither interrupt (unlikely)
    | nor isosychronous endpoints active on any device connected to some
    | USB, what is left would basically be bulk in- out out-pipes, which
    | only need to be 'polled at regular intervals' if one actually wants to
    | receive or transmit data over the USB. Therefore, the only USB not
    | being 'polled at regular intervals' is one without used devices
    | connected to ti.
    |
    | [...]
    |
    |> There is nothing inherently wrong with a polled, dedicated master/slave bus
    |> design.
    |
    | There was nothing wrong with the various token-passing based LAN
    | technologies people considered to be a good idea (more than) twenty
    | years ago, either. But for some mysterious reason, they have basically
    | completely disappeared from the market.

    There were some things wrong. While they basically worked, they just did
    not work quite as well as the collision avoidance method that won out.
    And even it has progressed to being a star system (switched fabric).


    |> It avoids all the problems of assigning a bus master or handling
    |> collisions among multiple senders.
    |
    | And there were lots and lots of wrongs inherent in CSMA/CD networks,
    | but again, for some mysterious reasons, they were cheap and worked
    | well in practice. But they were invented at a time when putting all of
    | the practically stupid 'intelligent design' into mass-produced and
    | therefore cheap ICs wasn't even possible. That's why it took some
    | twenty years of technical progress until the 'intelligent design'
    | finally became the chance to again rise from its well-deserved grave,
    | where it rather should have been rested until kingdom come.

    Worked well in practice was the key. Sure, it was imperfect in design.
    So was token passing. But so much LAN infrastructure now is switched
    communications. The only "collisions" are trying to send to a switch
    that has filled all its buffers.


    | The PS/2-mouse connected to my computer at work is a true real-time
    | capable device, ie it 'works' whenever I move it. The USB-mouse I have
    | at home cannot do that: If it has been inactive for some time, there
    | is a noticable delay between the time I try to use it again and the
    | time it actually reacts.
    |
    | A design which needs lots of high-developed components which are
    | literally busy doing nothing almost all of the time is stupid.

    Yes.


    | That it can be produced cheaply, given that the right proponents are
    | pushing it and works 'good enough' doesn't make it any less stupid.

    Almost anything can be made into a chip. So anything can eventually be
    cheap to mass produce.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-02-18-0852@ipal.net |
    |------------------------------------/-------------------------------------|

+ Reply to Thread