Date: 19 Dec 2002 12:08:27 +0100 From: Frode Nordahl <frode@nordahl.net> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-current@FreeBSD.ORG Subject: Re: UMASS USB bug? (getting the Sony disk-on-key device working). Message-ID: <1040296107.2012.23.camel@ws24.ns5.powertech.no> In-Reply-To: <200212191032.gBJAWNj0039522@apollo.backplane.com> References: <200212191032.gBJAWNj0039522@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hey, Matt While you're at it, could you have a look at PR kern/46176 ? =) At least would you tell me if you have the same problem with your device(s) On Thu, 2002-12-19 at 11:32, Matthew Dillon wrote: > It took a hellofalong time pulling my hair out trying to figure out > why the Sony disk-on-key I just bought didn't work. > > First I added a Quirk entry for the standard 6-byte problem, but it > didn't solve the problem. > > Finally, after slogging through an insane amount of debugging (I mean, > it really generates a lot of debugging if you turn it all on!) I came > up with the following patch. It appears that when an error occurs > and the umass device tries to read the sense data that it fails > comparing: > > sc->transfer_datalen - sc->transfer_actlen != UGETDW(sc->csw.dCSWDataResidue). > > As far as I can sc->transfer_actlen is NEVER updated. It is always 0, so > I don't quite see how the calculation could ever possibly be correct > if DataResidue is what I think it is (a count-down of the number of > unused bytes after a transfer). > > Note that my other UMASS device, a compact flash reader, has always > worked fine with just the Quirk entry. I really need a USB expert to > tell me what is going on :-) > > With the patch below my Sony diskkey works. Note that the junk at the > end of the patch is debugging. I noticed that the CAM layer thought > the READCAPACITY command succeeded when it didn't, and it was generating > weird sector-size errors due to the malloc'd return buffer containing > garbage. I had to put real values in the buffer to catch the problem > consistently. I don't know why the UMASS layer was returning a > success code to CAM for failed READCAPACITY commands but it took an > hour just to figure that CAM was using garbage in the return buffer. > > USB Experts gravitate here! Tell me I'm right or explain to me why I'm > wrong, because this stuff is incredibly complex and I'm having problems > thinking straight at 2:30 a.m. :-) > > -Matt > -- Frode Nordahl <frode@nordahl.net> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1040296107.2012.23.camel>