From owner-freebsd-usb@FreeBSD.ORG Tue Jan 11 14:07:59 2005 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B32D516A4CE for ; Tue, 11 Jan 2005 14:07:59 +0000 (GMT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (84-72-26-34.dclient.hispeed.ch [84.72.26.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2043C43D2D for ; Tue, 11 Jan 2005 14:07:58 +0000 (GMT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [IPv6:2002:5448:1a22:0:2c0:49ff:fef2:85dc]) (8.13.2/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id j0BE7mXf063021NO) for ; Tue, 11 Jan 2005 15:07:55 +0100 (CET) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.13.2/FNORD) id j0BE7kqd063020; Tue, 11 Jan 2005 15:07:47 +0100 (CET) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Tue, 11 Jan 2005 15:07:47 +0100 (CET) Message-Id: <200501111407.j0BE7kqd063020@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL From: Barry Bouwsma To: freebsd-usb@freebsd.org Mail-Followup-To: freebsd-usb@freebsd.org 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> Subject: Re: [USB] JetFlash TS1GJF2B 2.00 Attempt to query devicesizefailed: UNIT ATTENTION X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Barry Bouwsma List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 14:07:59 -0000 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