Menu

#20 OWW hangs with USB

open
nobody
x86_64 (2)
5
2013-01-09
2011-12-22
No

I've been using oww for over a year now with no problems, but after an upgrade to Ubuntu 11.10, I can't seem to connect to my one-wire network via USB. It seems to connect for a short period of time, and then timeout after a few reads of a thermometer, and then the usb stalls and I can't read anything on the one-wire network. I've upgrade to the latest oww, but will try downgrading to my last previous version just to check. Any hints?

Discussion

  • Scott Dylewski

    Scott Dylewski - 2012-01-05

    I compiled oww with libusb 0.1.12, but my system has libusb-0.1-4 installed on Ubuntu 11.04. It also has libusb-1.0-0 installed.

    Every time the system hangs, I get this output in my dmesg output:

    [34200.790480] INFO: task owwnogui:2816 blocked for more than 120 seconds.
    [34200.790487] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [34200.790493] owwnogui D 0000000000000001 0 2816 2815 0x00000000
    [34200.790503] ffff88009fb9fde8 0000000000000086 ffff88009fb9ffd8 ffff88009fb9e000
    [34200.790511] 0000000000013d00 ffff88009ff03178 ffff88009fb9ffd8 0000000000013d00
    [34200.790518] ffff880086688000 ffff88009ff02dc0 0000000000000000 ffff8800860dd780
    [34200.790528] Call Trace:
    [34200.790541] [<ffffffff81439aed>] usb_kill_urb+0x8d/0xd0
    [34200.790551] [<ffffffff81087fb0>] ? autoremove_wake_function+0x0/0x40
    [34200.790560] [<ffffffff8144519b>] usbdev_do_ioctl+0xb6b/0xfb0
    [34200.790570] [<ffffffff8108bd92>] ? hrtimer_cancel+0x22/0x30
    [34200.790578] [<ffffffff81013859>] ? read_tsc+0x9/0x20
    [34200.790585] [<ffffffff81092ee1>] ? ktime_get_ts+0xb1/0xf0
    [34200.790591] [<ffffffff8144560e>] usbdev_ioctl+0xe/0x20
    [34200.790598] [<ffffffff811764ef>] do_vfs_ioctl+0x8f/0x360
    [34200.790604] [<ffffffff81176851>] sys_ioctl+0x91/0xa0
    [34200.790610] [<ffffffff8100c002>] system_call_fastpath+0x16/0x1b

     
  • Scott Dylewski

    Scott Dylewski - 2012-01-05

    There's also a new libusb-compat library that "should" allow back-compatible libusb-0.1 use with the newer libusb-1.0. I downloaded this libusb-compat library, and the readme included in the package contains this:

    libusb-compat-0.1

    A compatibility layer allowing applications written for libusb-0.1 to work
    with libusb-1.0. libusb-compat-0.1 attempts to look, feel, smell and walk
    like libusb-0.1.

    Do not attempt to install libusb-0.1 and libusb-compat-0.1 on the same system.

    Known quirks/differences from libusb-0.1:
    1. usb_resetep(), a previously deprecated function, is implemented as
    equivalent to calling usb_clear_halt().
    2. libusb-0.1 allowed you to open a device which you did not have permission
    to do anything useful with (all I/O requests would immediately fail).
    libusb-compat-0.1 does not allow you to open such devices. You can still
    read descriptor info without opening a device.
    3. usb_device's "num_children" attribute is hardcoded to 0, and "children"
    is hardcoded to NULL. Do you need this information in your software? Let
    us know on the mailing list, and we'll add it.
    4. Some libusb-0.1 users may have implemented I/O cancellation by running
    transfers in their own threads and simply killing the thread when they
    don't want to do the transfer any more. This is bad programming practice
    for obvious reasons, and this lack of functionality was one of the primary
    drivers for libusb-1.0 development. With libusb-1.0 or libusb-compat-0.1
    backed by libusb-1.0, forcefully killing threads in this way is likely
    to cause all libusb I/O to halt. Instead, port your application to use
    libusb-1.0's asynchronous transfer API, which supports transfer
    cancellation.
    5. Error codes returned on certain events may not exactly match the error
    codes returned by libusb-0.1. Patches accepted to bring us closer to the
    behaviour of libusb-0.1 on Linux.

    libusb homepage:
    http://libusb.sourceforge.net