Re: cvs commit: src/sys/cam cam_ccb.h src/sys/cam/scsi scsi_cd.c src/sys/dev/firewire sbp.c

On Mon, 28 Jul 2003, Kevin Oberman wrote:
> > From: Nate Lawson <nate_at_root.org>
> > This is the first step to removing many of the da(4) quirks that have
> > accumulated for USB devices.  This code should remove the message:
> > "READ(6)/WRITE(6) not supported, increasing minimum_cmd_size to 10." It
> > should also fix USB devices which fail when receiving 6 byte commands but
> > do not yet have a quirk.
> >
> > After this code is in both stable and current, current USB quirks will be
> > deprecated but can be re-enabled in a pinch with a kernel option.
> > Unfortunately, I only have contact information for the more recent quirks
> > that were committed and so the only way to find devices that have other
> > problems (i.e. NO_SYNC_CACHE) is to disable the quirks and re-enable them
> > for devices that still fail.  I'm doing this as early as possible before
> > 5.2 to get things sorted out and if your device fails at that point, it
> > can be returned to ordinary behavior with a kernel option until I remove
> > it from the deprecated section.
>
> This looks great to me. The entire quirks system is a royal pain. It
> really needs to be driven by an external file so that the kernel does
> not need a re-compile for every device that requires poking something
> odd, but eliminating all of the 6 bye/10 byte ones will greatly
> improve life. I know such things (like pccard.conf) are ugly, but it's
> better than patching the source and re-building the kernel all of the
> time.

An external file is unnecessary since true quirks are a one-time thing.
User finds device is broken and then a quirk is committed.  For the USB
case, "false" quirks were needed in that the devices weren't 100% broken,
just that they crash when receiving 6 byte cmds instead of returning "cmd
not supported."  The real problem was that we were sending 6 byte commands
to devices which we should have known might not be able to handle them
(i.e. USB).  I'm just fixing the "false" quirk case (which should be 90%
of our USB quirks).  These "false" quirks were adding tons of noise and
masking truly broken devices (which should be in the minority).
Committing such quirks should go faster once there is less chaff to deal
with.

> There must be a better way. Almost anything like this that I plug into
> Windows "just works". That means no driver installation or anything.
> (The USB devices almost always include software, but I seldom install
> it.) I just HATE it when Windows works better than FreeBSD, but
> hardware can be a tough nut to crack.

Linux still lists broken USB devices in a kernel file.

> Is there any hope of getting PR53094 to support the Nomad MuVo moved
> to current. It will still need a quirk as it requires both
> NO_SYNC_CACHE and NO_PREVENT. The pr has been around for some time but
> was just assigned to joe_at_ about 10 days ago, so it may already be on
> it's way. (I am about 250 messages behind in cvs-all, so it may
> already have been committed.)

I'll look at the PR.

-Nate