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