From owner-freebsd-usb@FreeBSD.ORG Wed Jun 27 15:42:08 2012 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 003C21065674; Wed, 27 Jun 2012 15:42:07 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.c2i.net [212.247.154.66]) by mx1.freebsd.org (Postfix) with ESMTP id 446FC8FC22; Wed, 27 Jun 2012 15:42:07 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 124523461; Wed, 27 Jun 2012 17:36:59 +0200 From: Hans Petter Selasky To: Alexander Motin Date: Wed, 27 Jun 2012 17:36:46 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <4FE9AB28.3070704@passap.ru> <201206271731.08298.hselasky@c2i.net> <4FEB27D9.9030408@FreeBSD.org> In-Reply-To: <4FEB27D9.9030408@FreeBSD.org> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201206271736.46305.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: [usb] Kingston 8Gb is not usable X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 15:42:08 -0000 On Wednesday 27 June 2012 17:33:45 Alexander Motin wrote: > On 06/27/12 18:31, Hans Petter Selasky wrote: > > On Wednesday 27 June 2012 17:28:30 Alexander Motin wrote: > >> On 06/27/12 18:17, Hans Petter Selasky wrote: > >>> On Wednesday 27 June 2012 17:08:29 Alexander Motin wrote: > >>>> umass problem > >>> > >>> Hi, > >>> > >>> Are you verifying the received data length for the SCSI commands > >>> reading out various data? > >> > >> Mentioned revision beyond others adds check for the sense data length in > >> case of error. It won't even look into the sense data if reported amount > >> (sense_len - sense_resid) is zero or less then needed. I have no idea > >> how USB calculates resid, but it may be a problem in this case. I think > >> it could be useful to get USB packets trace to see whether it is device > >> doesn't return any sense data, or umass improperly interprets them in > >> this case for some reason. > > > > Hi, > > > > The residue is part of the 13 status bytes in the SCSI BOT protocol. If > > this field is zero, the umass driver will compute the residue from the > > actual data transferred as a workaround. > > Can't there be an opposite bug -- residue field is equal to the transfer > size in which case CAM will think there is no sense data? Hi, Then you need to check using "usbdump -i usbusX -s 65536 -vvvv" what is actually going on there. Usually the USB device does not zero-pad any SCSI data. Code looks like this: residue = UGETDW(sc->csw.dCSWDataResidue); if ((!residue) || (sc->sc_quirks & IGNORE_RESIDUE)) { residue = (sc->sc_transfer.data_len - sc->sc_transfer.actlen); } if (residue > sc->sc_transfer.data_len) { DPRINTF(sc, UDMASS_BBB, "truncating residue from %d " "to %d bytes\n", residue, sc- >sc_transfer.data_len); residue = sc->sc_transfer.data_len; } --HPS