Re: [patch] 2.6 -- add IOI Media Bay to SCSI quirk list

From: Patrick Mansfield
Date: Thu Aug 12 2004 - 19:32:50 EST


On Thu, Aug 12, 2004 at 07:00:53PM -0400, John W. Linville wrote:
> Patrick Mansfield wrote:
>
> >We seem to be getting quite a few of these. In theory we could add a line
> >like this for every multi-lun SCSI device.
> >
> >
>
> Isn't that what the quirk list is for?

We should not add to the list for devices that behave as expected. I would
hope the number of borken BLIST_NOLUN devices is much smaller than the number
of good BLIST_FORCELUN devices.

The list is backwards compatible, so we have flags in there that are not
required, like BLIST_FORCELUN.

> >Can you instead try booting with scsi_mod.max_luns=8 (or such) or build
> >with SCSI_MULTI_LUN enabled?
> >
> >
>
> That works for my box, but what about for others? Like those who may
> have both a multi-lun device and a single-lun device that hangs on a
> non-zero lun? What about the average luser who can't be bothered to
> hack-up his startup scripts or *gasp* rebuild his kernel?

Users should first set max_luns (or use a kernel built with
SCSI_MULTI_LUN), and then if they find a device that breaks have it added
to the quirks as BLIST_NOLUN. In the meantime they can boot using the
devinfo flag with BLIST_NOLUN.

I do not recall any reports (on linux-scsi) of devices that can't handle
LUN 0 requests, there is no change in the number of SCSI_NOLUN devices
from 2.4.21 to 2.6 (but I didn't check older kernels).

I had thought it was best to build without SCSI_MULTI_LUN, but given
the lack of SCSI_NOLUN additions, most users are better off with it on.

> It seems like the quirk list is there for a reason. If we start
> rejecting certain devices, then what is the criteria for a device to
> actually make it on the list?

Only add borken devices to the list, so it is a list of bad devices rather
than a list of good ones.

-- Patrick Mansfield
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/