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

Kenneth D. Merry wrote:
> > 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.

Ok, I didn't know that there is a difference between loader set tunables and
tunables set with sysctl -w!

>
> > 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.

Thanky you very much for that explanation. It's always good to know why
things are not working as expected. This expanded my limited knowledge.

Thank you,

-Harry

>
> 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
>