Date: Wed, 28 Feb 2007 03:10:00 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: phk@phk.freebsd.dk Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/usb umass.c Message-ID: <20070228.031000.1649769988.imp@bsdimp.com> In-Reply-To: <42088.1172642925@critter.freebsd.dk> References: <200702272233.l1RMXocb004983@repoman.freebsd.org> <42088.1172642925@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <42088.1172642925@critter.freebsd.dk> "Poul-Henning Kamp" <phk@phk.freebsd.dk> writes: : In message <200702272233.l1RMXocb004983@repoman.freebsd.org>, Warner Losh write : s: : : > Some USB mass storage devices return the number of sectors in response : > to a READ_CAPACITY request rather than the maximum sector (off by one : > problem). This causes a huge cascade of errors as the geom tasting : > code tries to read the last sector (which isn't really there in the : > face of this error). automated tools that manipulate disk labels and : > such also have issues. : > : > Create a new quirk READ_CAPACITY_OFFBY1 : : A better idea would be to have scsi_da.c try to read the : last sector and chop it if it fails. Why is that a better idea? There are only a few known bad bridges out there that do this (Linux has about a dozen in its quirk list). CAM errors are rather verbose, and in this case there are 4 retries each giving about 5 lines of output (I know this because something in the geom tasting reads the last sector, or tries). After careful consideration on scsi@, this was agreed to be the least painful solution to the broken bridges. There's already a lot of code in umass to cope with the quirky umass devices, and a little more wouldn't hurt. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070228.031000.1649769988.imp>