Re: [usb-storage] [PATCH] JMicron JM20337 USB-SATA data corruption bugfix - device 152d:2338

[Matthew Dharm <mdharm-kernel@one-eyed-alien.net>]

[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]

On Wed, Jul 30, 2008 at 01:55:25PM -0600, Robert Hancock wrote:
> Alan Stern wrote:
> > On Wed, 23 Jul 2008, Robert Hancock wrote:
> > 
> >> 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.
> > 
> > The problem is, what can you do?  The device has said that something 
> > was wrong, but it hasn't told you what.  Without knowing what went 
> > wrong, you can't know how to recover.

Yes and no.  If ASC/ASCQ is clear, then it's telling you that nothing is
wrong.  The device is contradicting itself. That doesn't really help us
here, but it's a point I like to be clear on.

> > I suppose in such cases we could simply report that the command failed
> > completely.
> 
> I think that is what we need to do. The SCSI/block layers should retry 
> the command or report a failure to userspace. Above all else we can't 
> just continue on our merry way and assume success, otherwise data will 
> get silently corrupted.

The code path to supress the reporting of an error when auto-sense shows no
ASC/ASCQ was added for a reason.  That reason has likely been lost to time,
but I worry about devices that are out there that rely on the current
behavior to function properly....

Matt

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

A:  The most ironic oxymoron wins ...
DP: "Microsoft Works"
A:  Uh, okay, you win.
					-- A.J. & Dust Puppy
User Friendly, 1/18/1998

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]