Re: [PATCH] JMicron JM20337 USB-SATA data corruption bugfix - device152d:2338

From: Robert Hancock
Date: Wed Jul 23 2008 - 19:20:46 EST

Alan Stern wrote:
The system doesn't detect the first problem for two reasons: The
scsi_eh_prep_cmnd routine fails to preserve scmd->underflow, and
usb-storage fails to check for underflow when the device returns Check
Condition status. The Bugzilla report contains fixes for both of
these, and they solve the problem.

The second problem is harder. The device is supposed to send a STALL
to cut the WRITE short -- and a USB trace under Windows seems to
indicate that it does -- but under Linux no STALL is received. I
don't know why not. But since Linux does not respond in the way the
device expects, the device crashes.

Anyway, I'll send the patch to this person so he can try it. I guess it won't fix his problem. This patch is much simpler and doesn't need any delays - I really think this is a different situation.

It isn't. And your patch is an ad-hoc correction that doesn't address
the true underlying reasons for the errors.

Tomas, you should try the patch listed in that bug report (well, except maybe the part that's actually adding the JMicron unusual devices entry) and see if that fixes the problem.

It remains an issue, though, that if there's no underflow, if the device reports an error in the CSW but doesn't provide sense data, we assume nothing bad happened and don't retry. That definitely does not seem correct. The device is not supposed to do this, but with how crappily some of these devices are designed we should be more defensive.

It's pretty gross to add random delays in without some good evidence or input from the manufacturer that it will really fix the problem. (We do have one GO_SLOW flag with a delay in there already for some Genesys chips, but I believe that was based on some actual input from Genesys.)

You should also try adding the delay mentioned in the bug report.
There's an excellent chance it will also prevent your problems.

I sometimes experience the problems described by this person, as I
noted in the first message with the patch. When these "reset high
speed USB device" messages appear, it is usually necessary to
disconnect and power off the device.

Because the device's firmware has crashed. That's why the reset fails.

Alan Stern

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at