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>