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: http://sourceforge.net/project/showfiles.php?group_id=3581&package_id=142529 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): usbutils-0.11-6.1 How reproducible: Always 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:
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"); continue; } - 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); + ioctl(fd, USBDEVFS_RELEASEINTERFACE, &interface_number); + } 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); } }
Created attachment 123058 [details] lsusb-hid-err-msg-fix.patch 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 transport. Thomas, please review the patch and add the bug to U4proposed if it looks good to go.
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.
Created attachment 123247 [details] lsusb_claim_interface.patch Patch attachment submitted by Stuart@Dell. RH engineering, please review patch and mark bug as U4Proposed.
Raising priority to high based on Dell's U4 consideration.
Did this get into RHEL4 U4? It looks like the same version of the usbutils RPM is in u4 as was in u3.
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 fix. This event sent from IssueTracker by sbenjamin issue 84392
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 : Sammy- IT84392 has been marked High Priority from Dell since 2/9/06! How do we get this one done? dlk
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. http://rhn.redhat.com/errata/RHBA-2006-0683.html
This problem is still showing on Dell PE2950, running RHEL4 U4 with all updates applied: usbutils-0.11-6.1 libusb-0.1.8-3 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. Greetings, Ed.
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.
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).
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.