Total I/O meltdown under Linux

2011-08-18
2013-05-30
  • Alexander Thomas

    I have been doing some tests with USB/IP, not only with this open source project but also with a commercial variant. I have stumbled upon a very annoying bug that occurs on Linux clients, both with the usbip from this project and the commercial product. This can either mean that the commercial product is based on the same code as this project and contains a similar bug, or it can be a more fundamental problem with USB/IP and the Linux kernel. I am inclined to believe it is the latter.

    The problem manifests itself as a total crash of everything I/O related in Linux: disk, network, peripherals etc. It is not a kernel panic and sometimes processes that do not try to access the disk or network will keep on running, but in most cases the whole screen just freezes and pressing the power button is the only way out. System logs do not show anything helpful, sometimes they contain messages about SATA being reset but nothing that points to the actual cause of the crash.

    I have a pretty surefire recipe for triggering the crash:
    1. Share a device on the server that can send a continuous stream of data. An USB microphone is ideal but you could also mount an USB drive and continuously copy data from it.
    2. On the Linux client, connect to this device and start streaming data from it.
    3. At the same time, keep using a locally connected USB device on the client. A simple USB mouse will do: just keep moving the cursor.
    4. The risk that the crash will happen seems to be greatly increased when the client system is stressed. Compiling something will generally trigger the crash within a few seconds.

    This is a particularly nasty problem because:
    1. It is one of those completely random ones. It is possible that in the above scenario, you will be moving your mouse for ten minutes while nothing happens. I've also had it happen within one second.
    2. All I/O dies. Communication with the crashed machine becomes impossible. This makes debugging particularly difficult.

    If anyone has a clue as to what could be causing this or how it could be debugged, it would be very welcome.

     
  • Gaurav Nigam

    Gaurav Nigam - 2011-08-19

    Facing the similar issue….In my case system freezes while detaching the device or sometimes when attaching the device.I have tried with different versions and different operating systems.In case of windows it causes blue screen crash.

    Searching for a way out :(

     
  • Anonymous - 2012-07-24

    Hi!
    Any Solutions ?
    My System(Ubuntu 12.04) freeze, too.
    With Debian , Kernel 2.6 it's running!
    Here are the Kernelmessages:

     
  • Bernard B

    Bernard B - 2012-09-06

    I tracked down the cause of the detach crash - see here for a patch: http://thread.gmane.org/gmane.linux.usb.general/70548
    If you're suffering from these hangs, please try building a kernel with this patch and let me know if it fixes things for you.

     
  • Anonymous - 2012-09-22

    Hello
    i have a kernel panic like RoooNY
    I also use Ubuntu 12.04 LTS
    My System
    Xen 4.1
    Dom0 use as IPUSB Server is working
    and a domU as client is not working.
    I already compile a new kernel with this patch http://thread.gmane.org/gmane.linux.usb.general/70548
    but the only change is if i load the vhci-hcd moduls i became a kernel panic, without this patch the kernel panic came after i add a device too the domU

    sorry for my poor English
    thanks in advance

    Dom0 is 3.2.0-30-generic
    DomU is 3.5.3

     
  • Bernard B

    Bernard B - 2012-09-22

    Hmm. It looks like there are several places in the current staging code that can lead to deadlocks and/or crashes. The code needs a good look over.

    I'm still getting random hangs within an hour when trying to watch a DVB-T stream from a USB dongle. I won't have any time soon to look at it though. Maybe somebody else will?

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks