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

[Alan Stern]

On Wed, 30 Jul 2008, Robert Hancock wrote:

> > 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.
> 
> It could be that's what Windows is doing, and it's just silently 
> retrying commands. Though, some people have reported corruption on these 
> chipsets on Windows too, so maybe it has the same issue.

It's probably a combination of problems.

> Is that SCSI/USB underflow fix from 
> http://bugzilla.kernel.org/show_bug.cgi?id=9638 being pushed forward by 
> anybody? If not, I can try and cook up a patch to take care of that as 
> well as the non-underflow failed CSW/no sense data issue.

The patch situation is a little confused.  The change to the SCSI stack
are already present in 2.6.27-rc1.  I am not pushing the added delay
patch; I want to do some testing of my own and hear from other people
about it before submitting it.

The USB change discussed there is written but not yet submitted.  It
also needs testing.  Would you like to try it under 2.6.27-rc1?  Here
it is.

Alan Stern


Index: usb-2.6/drivers/usb/storage/transport.c
===================================================================
--- usb-2.6.orig/drivers/usb/storage/transport.c
+++ usb-2.6/drivers/usb/storage/transport.c
@@ -663,7 +663,7 @@ void usb_stor_invoke_transport(struct sc
 	}
 
 	/* Did we transfer less than the minimum amount required? */
-	if (srb->result == SAM_STAT_GOOD &&
+	if ((srb->result == SAM_STAT_GOOD || srb->sense_buffer[2] == 0) &&
 			scsi_bufflen(srb) - scsi_get_resid(srb) < srb->underflow)
 		srb->result = (DID_ERROR << 16) | (SUGGEST_RETRY << 24);
 

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