Date: Tue, 11 Jan 2005 15:07:47 +0100 (CET) From: Barry Bouwsma <freebsd-misuser@remove-NOSPAM-to-reply.NOSPAM.dyndns.dk> To: freebsd-usb@freebsd.org Subject: Re: [USB] JetFlash TS1GJF2B 2.00 Attempt to query devicesizefailed: UNIT ATTENTION Message-ID: <200501111407.j0BE7kqd063020@Mail.NOSPAM.DynDNS.dK> References: <20050107064748.GE18554@squash.dsto.defence.gov.au> <41DE4E52.2040301@elischer.org> <20050111000956.GB32601@squash.dsto.defence.gov.au> <20050111013925.GD32601@squash.dsto.defence.gov.au> <200501111116.j0BBGOOx008367@Mail.NOSPAM.DynDNS.dK> <20050111112337.GA35255@squash.dsto.defence.gov.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 11 Jan 2005 21:53:40 +1030, "Wilkinson, Alex" wrote:
> >This is an unscientific trial-and-error thing, but if it's gotten me
> >results, it can't be all bad, given that I have no clue what I'm doing,
> >no? (Three of my devices have gotten quirks this way)
> Okay, well then where do I find out how to add a quirk that skips the
> 'READ CAPACITY' command ?
Use the existing quirk entries in umass.c as a reference. Simply
copy one of them, change the product to match your device, and
adjust to fit.
Here's an example of what I've added to add a new quirks entry for
an external drive, that speeds up boots by not waiting until one
particular command fails:
/* XXX HACK */
{ USB_VENDOR_MAXTOR, USB_PRODUCT_MAXTOR_5000, RID_WILDCARD,
UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
NO_GETMAXLUN
},
If your product and vendor IDs are already in usbdevs(*.h), then
it's a matter of tweaking the quirks (NO_GETMAXLUN in the above
example); alternatively your protocol could be wrong, in which
case you might see results by tweaking the PROTO strings given.
Look at the other products in this area for a feel of how it's
done.
If your product isn't in usbdevs, then you can either add it to
your usbdevs and regenerate the .h files if needed, and submit
your addition up to the developers if it's necessary for your
quirk, or more quickly, you can use the ID values directly,
values that you see either in dmesg or via usbdevs or another
usb utility.
For exmaple, without the vendor/product IDs in usbdevs, I'd need
to use a line like
{ 0x0d49, 0x5000, RID_WILDCARD,
and then later, after figuring out which quirks work, adding
a suitable description to usbdevs.
Then go through the various quirks, or cut'n'paste those from
other similar-sounding devices, and for speed, build a module
of umass.ko for each change you make, try it out, and see if
there's any difference.
Julian quoted from cam/scsi quirks, I'm not sure if you would
need to go that far, as there are already some quirks in
sys/dev/usb/umass.c which I've used. Though in one case, I'd
still see a warning thrown up by CAM that probably could be
ignored or quieted within CAM, where the USB layer returned
the error to CAM rather than letting the device return the
error (and then throw up further errors).
I hope this is what you're asking. Unfortunately, you'll need
to contact a wizard to learn which quirks affect what errors.
barry bouwsma
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200501111407.j0BE7kqd063020>