Description of problem: Dell M4300 cannot correctly detect an ExpressCard, as it fails to be able to get to the point where hal can mount it. Version-Release number of selected component (if applicable): 2.16.18-157.el5 How reproducible: Always Steps to Reproduce: 1. Install 20090708 x86_64 tree on Dell M4300 2. Log into gnome, and tail -f /var/log/messages 3. Insert Lexar 16GB ExpressCard SSD card. Actual results: In /var/log/messages: Jul 14 20:39:10 dell-m4300-01 kernel: usb 1-1: new high speed USB device using ehci_hcd and address 22 Jul 14 20:39:12 dell-m4300-01 kernel: usb 1-1: device descriptor read/64, error -32 Jul 14 20:39:12 dell-m4300-01 kernel: usb 1-1: device descriptor read/64, error -32 Jul 14 20:39:12 dell-m4300-01 kernel: usb 1-1: new high speed USB device using ehci_hcd and address 23 Jul 14 20:39:12 dell-m4300-01 kernel: usb 1-1: device descriptor read/64, error -32 Jul 14 20:39:12 dell-m4300-01 kernel: usb 1-1: device descriptor read/64, error -32 Jul 14 20:39:12 dell-m4300-01 kernel: usb 1-1: new high speed USB device using ehci_hcd and address 24 Jul 14 20:39:13 dell-m4300-01 kernel: usb 1-1: device not accepting address 24, error -32 Jul 14 20:39:13 dell-m4300-01 kernel: usb 1-1: new high speed USB device using ehci_hcd and address 25 Jul 14 20:39:13 dell-m4300-01 kernel: usb 1-1: device not accepting address 25, error -32 Expected results: No errors in /var/log/messages, and should mount and display the contents of the card. Additional info: No clue if this is a regression. Checking with earlier tester.
This happens on Lenovo Thinkpad R400, as well, with the addresses being different - unsurprisingly - but the rest of the behavior the same. Same ExpressCard.
This is relevant to RHEL5.4. Due to the degree of not functional, moving to RHEL6.0.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion.
The -32 is STALL, which means that the device is functional (firmware did not crash), but it rejects our command. But rejecting the basic descriptor read is VERY unusual. The enumeration is rather well documented, tests exist, so device vendors rarely blow it these days. Suzanne, may I get a remote access to the system in question? I guess it must be your personal box since it's a laptop. I only need an hour at the most. BTW, does this hardware work anywhere, say in Windows?
It's not actually my personal box; Desktop QE does laptop testing. It's currently available at 10.16.3.35. I am on IRC as shillman, and can give you the login info there (not really comfortable putting it in here). The card is in the machine right now. I do not know if it works in Windows, as I do not have a Windows box to test it with. However, it appears to work fine (gets mounted; nautilus shows it) in F11, kernel-2.6.29.5-191.fc11
Created attachment 357733 [details] usbmon trace of fault, annotated
The usbmon trace from F11 makes it clear that the card takes its time processing descriptor reads after a reset: 1888e3c0 2.827968 C Ci:1:000:0 0 18 = 12010002 00000040 dc0500ea 00110102 0301 1888e3c0 2.828062 S Co:1:001:0 s 23 03 0004 0002 0000 0 <---- 1.951s turnaround time So, I think we're safe for RHEL 6, we just need to fix this in RHEL 5.
I'm setting devel-ack to + because I've already done the development, so it's almost zero cost for us to fix (unless I create a regression by fixing this).
Please test kernel 2.6.18-164.el5.bz511374.1 from here: http://people.redhat.com/zaitcev/ftp/511374/
Test kernel absolutely fixes the problem. Not clear to me if this is something of sufficient import to make it into a RHEL5 update release, and not clear to me how difficult it would be to tell if there is a regression.
Created attachment 358655 [details] Test patch 1 The fix is already tested, but I forgot to upload the patch that was tested, so here we go. I think the danger of regressions is very low. The fixed kernel merely imitates what I saw in Fedora's usbmon trace that Mark captured. The only failure scenario I envision is if some user-more program loses patience (in particular SANE-based scanning is what I'd like to see working).
Created attachment 358656 [details] usbmon trace of success, annotated Sorry, here is Mark's trace that I used to make the patch.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Created attachment 377666 [details] Test patch 2 Patch updated with the feedback from Jarod Wilson. It should be _exactly_ the same, function-wise. But I rebuilt and uploaded the kernel in case, same location. Version 2.6.18-164.el5.bz511374.2.
in kernel-2.6.18-181.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5 Please update the appropriate value in the Verified field (cf_verified) to indicate this fix has been successfully verified. Include a comment with verification details.
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 therefore 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/RHSA-2010-0178.html