Bug 175125 - "lsusb -v" causes annoying messages with HID devices
"lsusb -v" causes annoying messages with HID devices
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: usbutils (Show other bugs)
All Linux
high Severity medium
: ---
: ---
Assigned To: Thomas Woerner
Depends On:
Blocks: 189992
  Show dependency treegraph
Reported: 2005-12-06 14:48 EST by Stuart Hayes
Modified: 2007-11-30 17:07 EST (History)
5 users (show)

See Also:
Fixed In Version: RHBA-2006-0683
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-03-29 15:28:35 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-hid-err-msg-fix.patch (1.00 KB, patch)
2006-01-11 12:12 EST, Samuel Benjamin
no flags Details | Diff
original patch, not "wrapped" (1023 bytes, patch)
2006-01-13 11:22 EST, Stuart Hayes
no flags Details | Diff
lsusb_claim_interface.patch (1023 bytes, patch)
2006-01-16 13:51 EST, Samuel Benjamin
no flags Details | Diff

  None (edit)
Description Stuart Hayes 2005-12-06 14:48:21 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)

Description of problem:
Running "lsusb -v" when USB HID devices are connected to the system results in error messages like this:

usb 3-1: usbfs: process 6857 (lsusb) did not claim interface 0 before use

This is happening because lsusb is not claiming the HID interfaces before trying to get the report descriptors from them.  This is fixed in the latest version of usbutils (version 0.71) -- see:


Or it could be with a simple patch--I'll post one as soon as I can test it.

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

How reproducible:

Steps to Reproduce:
1. Connect a USB HID device (keyboard or mouse)
2. Run "lsusb -v >x" (put output into file just so errors are easier to spot)
3. Observe error messages

Actual Results:  Each time lsusb got to a USB HID, I got a message similar to this:

usb 3-1: usbfs: process 6857 (lsusb) did not claim interface 0 before use

(This message is also occurring when other programs call lsusb--our server management software, for one).

Expected Results:  No error messages.  Lsusb shouldn't have tried to read the report descriptors if it couldn't claim the interface.

Additional info:
Comment 1 Stuart Hayes 2005-12-06 15:03:38 EST
Here's a patch that seems to work:

--- lsusb.c.orig	2005-12-06 14:32:26.000000000 -0500
+++ lsusb.c	2005-12-06 14:37:22.000000000 -0500
@@ -1223,12 +1223,21 @@ static void dump_hid_device(int fd, unsi
 			printf("report descriptor too long\n");
-		if ((n = usb_control_msg(fd, 0x81 , 0x06, 0x22<<8, 
interface_number, len, dbuf)) < 0) {
-			if (open_mode == O_RDWR)
-			printf("cannot get report descriptor\n");
-			continue;
+		if (ioctl(fd, USBDEVFS_CLAIMINTERFACE, &interface_number) >=0) 
+			if ((n = usb_control_msg(fd, 0x81 , 0x06, 0x22<<8, 
interface_number, len, dbuf)) < 0) {
+				if (open_mode == O_RDWR)
+				printf("cannot get report descriptor\n");
+				continue;
+			}
+			dump_report_desc(dbuf, n);
+		} else {
+			/* recent Linuxes require claim() for RECIP_INTERFACE,
+			 * so "rmmod hid" will often make these available.
+			 */
+			printf( "         Report Descriptors: \n"
+				"           ** UNAVAILABLE **\n");
-		dump_report_desc(dbuf, n);
Comment 5 Samuel Benjamin 2006-01-11 12:12:30 EST
Created attachment 123058 [details]

Cut & Paste of patch from inline text to file attachment to make sure it does
not get missed in the comments.

Stuart, can you confirm that the patch did not lose anything during this

Thomas, please review the patch and add the bug to U4proposed if it looks good
to go.
Comment 6 Stuart Hayes 2006-01-13 11:22:14 EST
Created attachment 123169 [details]
original patch, not "wrapped"

This is the original patch that was posted inline, but the original post had
some lines broken up because they were long.  This attachment should be the
same without the broken lines.
Comment 7 Samuel Benjamin 2006-01-16 13:51:51 EST
Created attachment 123247 [details]

Patch attachment submitted by Stuart@Dell. 
RH engineering, please review patch and mark bug as U4Proposed.
Comment 9 Samuel Benjamin 2006-02-09 14:36:12 EST
Raising priority to high based on Dell's U4 consideration.
Comment 14 Stuart Hayes 2006-07-14 10:56:22 EDT
Did this get into RHEL4 U4?  It looks like the same version of the usbutils 
RPM is in u4 as was in u3.
Comment 17 Issue Tracker 2006-09-06 14:04:21 EDT
I see the bug in MODIFIED state which is a good sign of progress.

Can we push this out to get an errata so the QA team can schedule this for
the next fasttrack release. Dell would like to know the estimated release
date so they can advise their management who have inquired about this

This event sent from IssueTracker by sbenjamin 
 issue 84392
Comment 18 Samuel Benjamin 2006-09-14 16:43:04 EDT
Per comment #16 this item was ACKED to rhel 4.5 fastrack, then the flags changed
 and that ACK reference was lost. PM/DEV/QE acks have been received. Please put
it back on the fasttrack + ACK per its original state. 

Dell has been asking for this important fix since U4 as they have test/customer
support groups asking for this fix. 

Please process this bug ASAP and provide an ETA for this bug so Dell Engineering
can commuincate this to the groups that are waiting on this fix.

Thank you.

Communication from Dell : Dale Kaisner wrote :
IT84392 has been marked High Priority from Dell since 2/9/06!  How do we
get this one done?
Comment 22 Red Hat Bugzilla 2006-09-27 02:21:38 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

Comment 26 Ed Voncken 2007-03-20 04:39:35 EDT
This problem is still showing on Dell PE2950, running RHEL4 U4 with all updates


The URL for the ERRATA (http://rhn.redhat.com/errata/RHBA-2006-0683.html)
returns 404. The ERRATA does not exist; the packages above have been unchanged
since RHEL4 U4.

Since this problem has been a High Priority for over half a year now, I'm
guessing that this patch got lost in the process.

Please re-open this bug, since the issue is NOT resolved.

Comment 27 Pete Graner 2007-03-29 15:28:35 EDT
The errata in comment #26 is live in the Fastrack channel. It will be rolled up
in the U5 update. If you wish to recieve it now you much subscribe to the
Fastrack channel in RHN. Closing as current release.
Comment 28 John Feeney 2007-03-29 15:35:34 EDT
So the Errata url of comment #22 is a dead link by design? When an Errata
migrates to Fastrack, the Errata url is just deleted? I guess I don't understand
the Errata/Fastrack procedure. Is this documented somewhere for the customer
to access (or for me for that matter). 
Comment 29 Pete Graner 2007-03-29 15:40:41 EDT
Unintentional side effect of adding the fastrack stream. The link will become
live once the package gets rolled up in the forthcoming update, the tooling
writes out its url but until the package gets moved into the update its dead.
This was the first time we realized that and its being addressed now. Not sure
what the resolution will be.

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