Date: Mon, 26 Feb 2007 09:15:19 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: scottl@samsco.org Cc: scsi@freebsd.org Subject: Re: Quirk for this? Message-ID: <20070226.091519.-1303465881.imp@bsdimp.com> In-Reply-To: <45E29EF9.3030306@samsco.org> References: <7579f7fb0702231017rdc246ebqeface91c9d5481e3@mail.gmail.com> <20070225.230019.1649768891.imp@bsdimp.com> <45E29EF9.3030306@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <45E29EF9.3030306@samsco.org>
Scott Long <scottl@samsco.org> writes:
: M. Warner Losh wrote:
: > In message: <7579f7fb0702231017rdc246ebqeface91c9d5481e3@mail.gmail.com>
: > "Matthew Jacob" <lydianconcepts@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070226.091519.-1303465881.imp>