Date: Mon, 26 Feb 2007 01:48:57 -0700 From: Scott Long <scottl@samsco.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: scsi@freebsd.org Subject: Re: Quirk for this? Message-ID: <45E29EF9.3030306@samsco.org> In-Reply-To: <20070225.230019.1649768891.imp@bsdimp.com> References: <45DE6C64.8020400@samsco.org> <20070223.100839.112608684.imp@bsdimp.com> <7579f7fb0702231017rdc246ebqeface91c9d5481e3@mail.gmail.com> <20070225.230019.1649768891.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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? Secondly, is it only a problem with USB devices? 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? Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45E29EF9.3030306>