Date: Wed, 30 Jul 2008 13:00:33 -0700
From: Matthew Dharm <mdharm-kernel@one-eyed-alien.net>
To: Robert Hancock <hancockr@shaw.ca>
Cc: Alan Stern <stern@rowland.harvard.edu>,
       usb-storage@lists.one-eyed-alien.net, Tomas Styblo <tripie@cpan.org>,
       linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [usb-storage] [PATCH] JMicron JM20337 USB-SATA data corruption bugfix - device 152d:2338
Message-ID: <20080730200033.GD7578@one-eyed-alien.net>
Mail-Followup-To: Robert Hancock <hancockr@shaw.ca>,
	Alan Stern <stern@rowland.harvard.edu>,
	usb-storage@lists.one-eyed-alien.net,
	Tomas Styblo <tripie@cpan.org>, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org
References: <Pine.LNX.4.44L0.0807232337110.25883-100000@netrider.rowland.org> <4890C72D.7040604@shaw.ca>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99"
Content-Disposition: inline
In-Reply-To: <4890C72D.7040604@shaw.ca>
User-Agent: Mutt/1.4.2.3i
Organization: One Eyed Alien Networks
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2479
Lines: 71


--5vNYLRcllDrimb99
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 30, 2008 at 01:55:25PM -0600, Robert Hancock wrote:
> Alan Stern wrote:
> > On Wed, 23 Jul 2008, Robert Hancock wrote:
> >=20
> >> It remains an issue, though, that if there's no underflow, if the devi=
ce=20
> >> reports an error in the CSW but doesn't provide sense data, we assume=
=20
> >> nothing bad happened and don't retry. That definitely does not seem=20
> >> correct. The device is not supposed to do this, but with how crappily=
=20
> >> some of these devices are designed we should be more defensive.
> >=20
> > The problem is, what can you do?  The device has said that something=20
> > was wrong, but it hasn't told you what.  Without knowing what went=20
> > 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.
>=20
> I think that is what we need to do. The SCSI/block layers should retry=20
> the command or report a failure to userspace. Above all else we can't=20
> just continue on our merry way and assume success, otherwise data will=20
> 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

--=20
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.=
net=20
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

--5vNYLRcllDrimb99
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFIkMhhHL9iwnUZqnkRAhupAKCaoSoLn6vlwakvkODfvnHP3iynbACgkSyO
xXOV9y4/nOQoW1BW6MrhG6c=
=8g2Z
-----END PGP SIGNATURE-----

--5vNYLRcllDrimb99--
--
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/