Bug 8920

Created attachment 12482 [details]
dmesg

attached dmesg

Created attachment 12483 [details]
usbmon

attached USBmon

Reply-To: akpm@linux-foundation.org

On Wed, 22 Aug 2007 02:04:14 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=8920
> 
>            Summary: The USB 2.0 flash disk can not be detected with EHCI is
>                     loaded
>            Product: Drivers
>            Version: 2.5
>      KernelVersion: 2.6.23-rc2-mm2
>           Platform: All
>         OS/Version: Linux
>               Tree: -mm
>             Status: NEW
>           Severity: high
>           Priority: P1
>          Component: USB
>         AssignedTo: greg@kroah.com
>         ReportedBy: henry.su@amd.com
>                 CC: stern@rowland.harvard.edu
> 
> 
> Most recent kernel where this bug did not occur:N/A
> Distribution: FC7
> Hardware Environment:ATI SB700
> Software Environment:
> Problem Description:
> The plugged-in USB flash disk cannot be detected if EHCI module is loead,this
> disk works well in windows or the EHCI module is removed.
> 
> Steps to reproduce:
> 1.boot Federa core 7,
> 2.plug in the USB 2.0 flash disk
> 
> 
> -- 
> Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.

I don't understand.  Your dmesg attachment shows the flash disk working perfectly with ehci-hcd, apart from one error which was recovered.  The usbmon log doesn't show any errors at all.

So what's the problem?

Hi Alan,
Normally,if the USB flash disk is detected, there are two devices in the /dev directory(/dev/sdb and /dev/sdb1), so that I can mount the /dev/sdb1 device manually. Actually I can find the /dev/sdb, no /dev/sdb1 exists in /dev directory. 

Sometimes the flash disk can be detected successfully, but it takes a long time to mount this disk.

I noticed that it takes a long time in the READ_10 command, there are about 30 seconds between "usb_stor_bulk_transfer_sglist ..." and "---transfer complete".

usb-storage: Command READ_10 (10 bytes)
usb-storage:  28 00 00 3b 8e 71 00 00 07 00
usb-storage: Bulk Command S 0x43425355 T 0x23 L 3584 F 128 Trg 0 LUN 0 CL 10
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_sglist: xfer 3584 bytes, 1 entries
<<<<<<<<<<<<<<<<< about 30 seconds
usb-storage: Status code 0; transferred 4096/4096
usb-storage: -- transfer complete

Reply-To: david-b@pacbell.net

On Wednesday 22 August 2007, bugme-daemon@bugzilla.kernel.org wrote:
> usb-storage: usb_stor_bulk_transfer_sglist: xfer 3584 bytes, 1 entries
> <<<<<<<<<<<<<<<<< about 30 seconds
> usb-storage: Status code 0; transferred 4096/4096

Where does the extra 512 bytes come from??
(4096 - 3584) == 512 ... fishy?

sorry for the mistake,should be:
usb-storage: Status code 0; transferred 3584/3584
usb-storage: -- transfer complete

Finally, there are some errors in the console,such as:
end_request: I/O error, dev sdb, sector 24
Buffer I/O error on device sdb1, Logical block 8
Buffer I/O error on device sdb1, Logical block 9
Buffer I/O error on device sdb1, Logical block 10
Buffer I/O error on device sdb1, Logical block 11
Buffer I/O error on device sdb1, Logical block 12
Buffer I/O error on device sdb1, Logical block 13
Buffer I/O error on device sdb1, Logical block 14
Buffer I/O error on device sdb1, Logical block 15
...

> I noticed that it takes a long time in the READ_10 command, there are about
> 30
> seconds between "usb_stor_bulk_transfer_sglist ..." and "---transfer
> complete".

This may sound silly, but how do you know there were 30 seconds between them?  The log file doesn't include any timestamps.

Your flash disk has the same behavior as lots of other USB storage devices: They get occasional errors when running at high speed.  Nobody knows why or how to fix it, and nobody knows what Windows does differently from Linux.  Sometimes using a better USB cable can help; sometimes the hardware on the computer or the device is bad (like the capacitance is wrong); sometimes there's no obvious reason.

In the dmesg log you attached there was an example of such an error.  In that case the system was able to recover and keep working.  Quite often when one of these errors occurs the device simply dies and fails to respond to any futher communication until you power-cycle it.

Hi Alan,
This Flash runs well with ATI SB600 chipset which has 5 OHCIs and one EHCI, and the SB700 chipset adds one more EHCI.
I compared the registers value with these two chipsets after plugged in the flash disk, but got no cue.
Ideally,it takes a long time to mount the disk if it was detected,but normally the disk cannot be detected at all.
I attached another dmesg in which the command_abort comes up many times,maybe that is why  there were 30 seconds delay.

Created attachment 12589 [details]
dmesg with command_abort

Created attachment 12590 [details]
usbmon with command_abort

Hi Alan,
Could you please tell me what is likely to cause the command_delay?
Thank you very much!

The delay happens because the computer is waiting for the flash disk to send a reply, but the reply never comes.  After 30 seconds the computer stops waiting and resets the flash disk.

Why doesn't the reply arrive?  I don't know.  It could be a problem with your USB connections or cables.  It could even be a problem with the USB connections inside the computer's case.  Try using different ports and different cables.

This issue has been fixed by disable the enhancement features of SB700.