Date: Wed, 23 Jul 2008 23:42:12 -0400 (EDT)
From: Alan Stern <stern@rowland.harvard.edu>
To: Robert Hancock <hancockr@shaw.ca>
cc: Tomas Styblo <tripie@cpan.org>, <linux-kernel@vger.kernel.org>,
       <linux-usb@vger.kernel.org>, <usb-storage@lists.one-eyed-alien.net>
Subject: Re: [PATCH] JMicron JM20337 USB-SATA data corruption bugfix - device
 152d:2338
In-Reply-To: <4887BCB9.2000103@shaw.ca>
Message-ID: <Pine.LNX.4.44L0.0807232337110.25883-100000@netrider.rowland.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1234
Lines: 29

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.

I suppose in such cases we could simply report that the command failed
completely.

> 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.)

That's right.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/