On Thu, Sep 13, 2007 at 03:13:46PM -0400, Alan Stern wrote:
quoted text > On Thu, 13 Sep 2007, Linus Torvalds wrote:
>=20
> > In general, I think the USB blacklist/whitelists are generally a sign o=
f=20
quoted text > > some deeper bug.
> >=20
> > We used to have a lot of those things due to simply incorrect SCSI=20
> > probing, causing devices to lock up because Linux probed them with bad =
or=20
quoted text > > unexpected modepages etc. I suspect we still have old blacklist entries=
=20
quoted text > > from those days that just never got cleaned up, because nobody ever dar=
ed=20
quoted text > > remove the blacklist entry.
>=20
> I don't just suspect -- I know for a fact that we do. Partly because
> of laziness and partly because of not being able to verify that an
> entry is no longer needed.
We do have some code that looks for unneeded entries. When found by an
end-user (which confirms that the entry can be removed), it asks the user
to drop us an e-mail so we can remove it.
quoted text > > We should strive to make the default behaviour be so safe that we never=
=20
quoted text > > need a black-list (or a whitelist), and basically consider blacklists t=
o=20
quoted text > > be not a way to "fix up a device", but a way to avoid some really serio=
us=20
quoted text > > AND *RARE* error.
>=20
> In general I agree. However there are some problems for which nobody=20
> has been able to come up with another solution. See below.
We generally do strive for such a thing. Over the years, we've made
several changes to the way the SCSI core works (especially in the probing
department) to allow us to remove all sorts of special-case code and quirk
entries.
quoted text > > For example, why do we have that US_FL_MAX_SECTORS_64 at all? The fact=
=20
quoted text > > that some USB device is broken with more than 64 sectors would seem to=
=20
quoted text > > indicate that Windows *never* does more than 64 sectors, and that in tu=
rn=20
quoted text > > means that pretty much *no* devices have ever been tested with anything=
=20
quoted text > > bigger.
> >=20
> > So why not make the 64 sector limit be the default? Get rid of the quir=
k:=20
quoted text > > we already allow people to override it in /sys if they really want to, =
but=20
quoted text > > realistically, it's probably not going to make any difference what-so-e=
ver=20
quoted text > > for *any* normal load. So we seem to have a quirk that really doesn't b=
uy=20
quoted text > > us anything but headache.
>=20
> That's true now, but it wasn't always. Until the last year or so,=20
> cdrecord wouldn't work properly with USB CD drives having a 64-sector=20
> limit unless the user added a particular command-line argument.
>=20
> In fact, setting max_sectors down to 64 is probably overkill -- 120
> ought to be enough. But there may have been one or two oddball devices
> that really did have a 32-KB limit, and better safe than sorry. At one
> point an engineer from Genesys said their devices did, although they do
> seem to work perfectly well with 64-KB transfers (and that's what=20
> Windows gives them).
It's worth pointing out that performance drops like a stone as this number
goes down.
quoted text > > Other quirks worth looking at (but likely unfixable) are:
> > - US_FL_IGNORE_RESIDUE:
> > Does this really matter? Can we not just always do the=20
> > US_FL_IGNORE_RESIDUE thing? Windows must not be doing what we're=20
> > doing.
>=20
> Windows does indeed ignore the residue field, as far as I can tell.
>=20
> But this is a rather tricky thing. The USB mass-storage spec
> specifically says that one way a device can signal a short transfer is
> to pad the data with 0s to the requested length and then set the
> residue to indicate how much of the data is valid. If we ignore the
> residue then we run a risk of misinterpreting the 0s as valid data.
>=20
> Now in practice this doesn't matter much because short transfers of
> block data (READ_10) generally involve other errors that would show up
> anyway, and for non-block data (MODE SENSE) the padding probably
> wouldn't matter. Still it seems like a dangerous sort of thing to do,
> which is why I have resisted it.
>=20
> (And by the way, there _definitely_ are devices which use this
> signalling method. In fact, Linux contains a driver that does it.)
I think this last point is key. I'm unwilling to sacrifice error detection
on properly working devices to enable error-prone use on clearly buggy
devices.
quoted text > > - US_FL_FIX_CAPACITY:=20
> > This is a generic SCSI issue, not a USB one, and maybe there are=20
> > better solutions to it. Are we perhaps doing something wrong? Is=20
> > there some patterns we haven't seen? Why do we need this, when=20
> > presumably Windows does not?
>=20
> This is another hard case. No, we aren't doing anything wrong. If
> there are any patterns we haven't seen, we aren't aware of them. :-) =20
> You might think that if a device claims to have an odd number of
> sectors then it must be wrong, but this turns out not to be true.
>=20
> Why doesn't Windows need this? For all we know, it does. Has anybody
> ever tried forcing Windows to read the sector beyond the end of one of
> these buggy devices?
As far as I know, Windows doesn't need this because of the way FAT and NTFS
work. They never use the end of the disk (by more than a few sectors, or
so I'm told).
quoted text > There's a straightforward solution: Never try to use the last sector --
> in effect, assume every device has the FIX_CAPACITY flag set. Doing=20
> this universally could cause data loss, however, so again I have been=20
> opposed to it.
I agree here.
quoted text > > - US_FL_SINGLE_LUN:
> > At least a few of these seem to indicate that the real problem=20
> > could be detected dynamically ("device reports Sub=3Dff") rather=20
> > than with a quirk. Quirks are unmaintainable (and change), but=20
> > noticing when devices return impossible values and going into a=20
> > "safe mode" is just defensive programming.
>=20
> This is almost certainly a case where lots of the entries are no longer=
=20
quoted text > needed. But it isn't easy to tell which ones can safely be removed.
I've been meaning to start sending e-mails to see if we can get rid of
these. Most of the devices which required it were UFI, which reports "LUN
not present" in a goofy way. We fixed the code to detect it properly, but
there are still quite a few devices out there that don't implement the
correct (if goofy) method.
Most of those entries (which are for UFI devices) can go, if we get a
volunteer to take the e-mail addresses listed in unusual_devs.h and work
the list.
Matt
--=20
Matthew Dharm Home: mdharm-usb@one-eyed-alien.=
net=20
Maintainer, Linux USB Mass Storage Driver
Sir, for the hundreth time, we do NOT carry 600-round boxes of belt-fed=20
suction darts!
-- Salesperson to Greg
User Friendly, 12/30/1997
