usb/78984: Creative MUVO umass failure

[Henrik Gulbrandsen]

The following reply was made to PR usb/78984; it has been noted by GNATS.

From: Henrik Gulbrandsen <henrik at gulbra.net>
To: bug-followup at FreeBSD.org, bofh at m-wesemeyer.de
Cc:  
Subject: Re: usb/78984: Creative MUVO umass failure
Date: Mon, 25 Sep 2006 20:27:44 +0200

 --=-XeNDd3t2QmZ2rMXzti7V
 Content-Type: text/plain
 Content-Transfer-Encoding: 7bit
 
 Since this bug is still open, I guess I'd better give an update. I seem
 to have exactly the same device as in the original bug report, and it
 gives this result on the current 6.2-PRERELEASE (basically 6.2-BETA1):
 
 umass0: Creative Tech NOMAD MuVo, rev 1.10/0.01, addr 2
 da0 at umass-sim0 bus 0 target 0 lun 0
 da0: <CREATIVE NOMAD_MUVO 0001> Removable Direct Access SCSI-4 device
 da0: 1.000MB/s transfers
 da0: 125MB (256001 512 byte sectors: 64H 32S/T 125C)
 umass0: BBB reset failed, TIMEOUT
 umass0: BBB bulk-in clear stall failed, STALLED
 umass0: BBB bulk-out clear stall failed, STALLED
 (da0:umass-sim0:0:0:0): AutoSense Failed
 umass0: BBB reset failed, STALLED
 umass0: BBB bulk-in clear stall failed, STALLED
 umass0: BBB bulk-out clear stall failed, STALLED
 
 Fortunately, this is a known problem that I analyzed back in 2004 for
 FreeBSD 5.3, but somehow I forgot to deliver the patch. Basically, the
 128 MB MuVo device incorrectly reports its capacity using the number of
 sectors instead of reporting the highest sector number as expected.
 
 This problem may be shared with other umass devices, but the attached
 patch should get rid of the bug once and for all. At least, it still
 works for me in the 6.2 branch, so I think this bug can be closed once
 the patch has been applied.
 
 /Henrik
 
 
 --=-XeNDd3t2QmZ2rMXzti7V
 Content-Disposition: attachment; filename=scsi_da.c.patch
 Content-Type: text/x-patch; name=scsi_da.c.patch; charset=ISO-8859-15
 Content-Transfer-Encoding: 7bit
 
 --- sys/cam/scsi/scsi_da.c.orig	Wed Jul 26 09:48:51 2006
 +++ sys/cam/scsi/scsi_da.c	Mon Sep 25 13:26:07 2006
 @@ -1850,6 +1850,15 @@
  	dp = &softc->params;
  	dp->secsize = block_len;
  	dp->sectors = maxsector + 1;
 +
 +	/*
 +	 * An odd sector count is most likely an off-by-one error in the
 +	 * underlying SCSI device (returning sector count instead of the
 +	 * highest sector number); Let's decrease it here to avoid access
 +	 * outside the supported sector range.
 +	 */
 +	dp->sectors &= ~1;
 +
  	/*
  	 * Have the controller provide us with a geometry
  	 * for this disk.  The only time the geometry
 
 --=-XeNDd3t2QmZ2rMXzti7V--