From owner-freebsd-scsi@FreeBSD.ORG Mon Feb 26 16:16:39 2007 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 46C3D16A401 for ; Mon, 26 Feb 2007 16:16:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E6CD913C47E for ; Mon, 26 Feb 2007 16:16:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id l1QGFGoK034458; Mon, 26 Feb 2007 09:15:16 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 26 Feb 2007 09:15:19 -0700 (MST) Message-Id: <20070226.091519.-1303465881.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <45E29EF9.3030306@samsco.org> References: <7579f7fb0702231017rdc246ebqeface91c9d5481e3@mail.gmail.com> <20070225.230019.1649768891.imp@bsdimp.com> <45E29EF9.3030306@samsco.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 26 Feb 2007 09:15:17 -0700 (MST) Cc: scsi@freebsd.org Subject: Re: Quirk for this? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 16:16:39 -0000 In message: <45E29EF9.3030306@samsco.org> Scott Long writes: : M. Warner Losh wrote: : > In message: <7579f7fb0702231017rdc246ebqeface91c9d5481e3@mail.gmail.com> : > "Matthew Jacob" writes: : > : > The question is: Given that I know that the first USB/CF adapter : > : > always reports one too big, is there a way this can be fixed? : > : : > : There are two problems here that I see: : > : : > : a) The GEOM taste code cannot be overridden. : > : : > : b) How do we accomodate/detect broken h/w? : > : : > : I'm inclined to think that GEOM stuff cannot/should not be "fixed". : > : The second question is the harder one. : > : : > : You personally can fix this for yourself by doing your own specialized : > : quirk matching and just adjusting the READ CAPACITY results : > : accordingly. We have to ask whether this particular breakage is both : > : widespread enough and the devices important enough to try and : > : generalize some solution for. : > : > I took a look at Linux, and they have a quirk for this. A bunch of : > cameras have this bug, as do iPods and a few media readers... : > : > Warner : : So is it an off-by-one issue for all of these devices, or do we need to : have a mechanism for encoding a variable fudge factor? Strictly off-by-one. The capacity reported is the number of sectors, not the highest sector number. At least that's the Linux quirk. : Secondly, is it : only a problem with USB devices? As far as I know yes. This problem happens when the usb to mass storage device bridge chip does something wrong. This isn't a problem in the actual mass storage device. : Third, do we want only the : READ_CAPACITY that is done during probe+attach to be fudged, or do we : want to intercept every READ_CAPACITY attempt from every source and : fudge them all? I suspect all of them. I've been reading umass sources, and it looks like we're already dealing with some READ_CAPACITY issues in umass_cam_sense_cb: } else if ((sc->quirks & RS_NO_CLEAR_UA) && (csio->cdb_io.cdb_bytes[0] == READ_CAPACITY) && ((csio->sense_data.flags & SSD_KEY) == SSD_KEY_UNIT_ATTENTION)) { /* * Some devices do not clear the unit attention error * on request sense. We insert a test unit ready * command to make sure we clear the unit attention * condition, then allow the retry to proceed as * usual. */ It looks like there are two other callbacks (umass_cam_cb and umass_cam_quirk_cb). Judging from the comments, I can ignore umass_cam_quirk_cb. I'm guessing the 'Third' question would translate to 'do we have to do it both places, or just in the umass_cam_sense_cb?' To be honest, I'm unsure. Lemme play around with my device that does this and I'll get back to you. I might be able to snag my step-son's ipod nano as well to see if it really does what the linux driver says or not. This could also be autoprobed if you don't mind the usual cam error message on failed transfer, since I know everybody's love for quirks and quirk tables. Now that I think about it, this may have been what Matthew was getting at earlier in this thread. Warner