Re: where is kern.ca.da.no_6_byte?

On Sun, Jul 20, 2003 at 19:40:58 +0200, Harald Schmalzbauer wrote:
> Andre Guibert de Bruet wrote:
> > On Sun, 20 Jul 2003, Harald Schmalzbauer wrote:
> >
> > > Kenneth D. Merry wrote:
> > > > > seems that this sysctl doesn't exist any more!
> > > > > Is there anything similar?
> > > >
> > > > It has been renamed:
> > > > kern.cam.da.%d.minimum_cmd_size
> > > >
> > > > Where %d is the unit number for the da(4) device.
> > >
> > > Thaks a lot! Where can I find such info? I looked via cvsweb
> > for scsi_da.c
> > > but couldn't find anything. Is it possible to list all kernel tunables?
> >
> > sysctl -a. You'll probably want to pipe it's output to your favorite
> > pager. "sysctl kern" will list just the entries in the kern MIB.
> 
> OIC. It's not available until the device is pluged in, which makes it
> absolutely useless.
> When I plug it in the machine behaves abnormal, so I need to set it BEFORE
> connecting USB devices.

Then you can set it in your loader.conf file instead.  It's a loader
tunable as well as a sysctl variable.  The da(4) driver will read that
tunable value and set the variable correctly before your drive is probed.

> Why has this tunable by default a value which makes the machine unstable by
> every umass I plug in which has no "qirk" entry? And if I look how many
> quirks there are I assume that almost every device needs no_6byte set.
> Why not make it default? Perhaps this would prevent criminal people from
> intentionally crashing servers when intruding my serverroom armed with
> dozends of USB devices;)

The problem is that some devices can't handle 6 byte commands, and some
devices can't handle 10 byte commands.  If we "fix" things for one set of
devices we'll break things for another.

You're correct that many USB devices need 10 byte CDBs from the outset,
because they're so broken that if they get a CDB they don't recognize, they
hang up.

We have code in the da(4) driver now that detects errors from a device
in response to a 6 byte command and tries a 10 byte command instead, but
that doesn't help if the device hangs the first time it gets a 6 byte
command.

We've got plans to basically quirk all USB devices (and perhaps ATAPI and
firewire if necessary, but USB is the one that causes the most trouble) so
that no 6 byte commands get sent.  So, hopefully this won't be an issue for
too much longer.

Ken
-- 
Kenneth Merry
ken_at_kdm.org