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 <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
