Bug 190464 - lsusb fails to list device
lsusb fails to list device
Product: Fedora
Classification: Fedora
Component: hwdata (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Karsten Hopp
Depends On:
  Show dependency treegraph
Reported: 2006-05-02 13:03 EDT by Bob Arendt
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: hwdata-0.200-1.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-24 04:42:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
lsusb and /proc/bus/usb/devices output (30.95 KB, text/plain)
2006-05-02 13:03 EDT, Bob Arendt
no flags Details
Adds iriver T10 signature to usb.ids. (403 bytes, patch)
2006-05-09 06:34 EDT, Jindrich Novy
no flags Details | Diff
applied diff (570 bytes, text/plain)
2006-05-10 10:06 EDT, Bob Arendt
no flags Details

  None (edit)
Description Bob Arendt 2006-05-02 13:03:04 EDT
Description of problem:
An iRiver T10 usb device is no longer listed by lsusb, or recognized
by gphoto2 (did work with FC4, until upgrading to FC5).  Booting to
a Knoppix CD, lsusb works - indicating that the device and computer
hardware still function.

The device *does* show up in /proc/bus/usb/devices, but shown by lsusb.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  Plug in, turn on iRiver T10 device
2.  lsusb
    It lists other devices, but not the iRiver
3.  Before conversion to UMS firmware, the T10 was not recognized by
    gphoto2 (used for PTP2 xfer capability).  D
Actual results:
    No corresponding device entry in lsusb
    gphoto2 returns "device not found"

Expected results:
    lsusb entry
    gphoto2 finds device, and (when MTP) would list contents and
    upload files.

Additional info:
    attached output of lsusb -v with USB_DEBUG=255 asserted, and
    contents of /proc/bus/usb/devices for FC5 (failure) and Knoppix (OK).

    It looks like the principle difference is that the device is now
    handled by the ehci_hcd driver in FC5, while it looks like it
    was handled by the uhci_hcd in earlier kernels (Knoppix / FC4).

    After switching the device to UMS, it's functional using the
    usb-storage driver (gphoto2 no longer required), but it still
    doesn't show in the lsusb output.

    Note that the USB mouse shows up in all output.

    The motherboard is an ASUS P4P800
Comment 1 Bob Arendt 2006-05-02 13:03:04 EDT
Created attachment 128500 [details]
lsusb and /proc/bus/usb/devices output
Comment 2 Jindrich Novy 2006-05-09 06:34:28 EDT
Created attachment 128774 [details]
Adds iriver T10 signature to usb.ids.

Your mp3 player is not detected by lsusb because there's no corresponding entry
for the VendorID/ProductID in usb.ids in usbutils. This patch adds it there.
Comment 3 Bob Arendt 2006-05-10 10:06:14 EDT
Created attachment 128851 [details]
applied diff

I applied these changes to /usr/share/hwdata/usb.ids
The device still doesn't show up via lsusb, though the kernel-side
activities (mounting UMS device, posting to /proc/bus/usb/devices)
work fine.  Now using kernel 2.6.16-1.2111_FC5smp.
Comment 4 Bob Arendt 2007-01-24 23:48:41 EST
Same behaviour with FC6 + latest updates as of today
Linux host 2.6.19-1.2895.fc6 #1 SMP Wed Jan 10 19:28:18 EST 2007 i686 i686 i386
Comment 5 Thomas Woerner 2007-05-31 08:14:32 EDT
Assigning to hwdata. usbutils only contains the lsusb utility, which uses the
usb.ids database from hwdata.

Assigning to hwdata.
Comment 6 Bob Arendt 2007-07-23 21:28:04 EDT
lsusb now works for this device with the latest kernel update:


Even though this device is NOT listed in /usr/share/hwdata/usb.ids,
it still (properly) shows up:

Bus 002 Device 005: ID 4102:1013 iRiver, Ltd. 

Please feel free to close this Bug.  Though it would be interesting to get a
postmortem as to what was really broken.  I suspect it had something to with
high-speed USB devices not getting reported in in /proc properly?  This broke
the same time the xfer rate suddenly jumped up.  Perhaps the new kernel fixed it?
Comment 7 Karsten Hopp 2007-07-24 04:42:48 EDT
most probably the kernel, but I'm wondering why noone else reported this   
problem. Maybe a case where your bios settings and the kernel didn't work
together as expected.

Note You need to log in before you can comment on or make changes to this bug.