All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Mansfield <patmans@us.ibm.com>
To: "John W. Linville" <linville@tuxdriver.com>
Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
	James.Bottomley@SteelEye.com
Subject: Re: [patch] 2.6 -- add IOI Media Bay to SCSI quirk list
Date: Thu, 12 Aug 2004 17:27:56 -0700	[thread overview]
Message-ID: <20040813002756.GA21763@beaverton.ibm.com> (raw)
In-Reply-To: <411BF6A5.2030306@tuxdriver.com>

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

  parent reply	other threads:[~2004-08-13  0:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-12 21:37 [patch] 2.6 -- add IOI Media Bay to SCSI quirk list John W. Linville
2004-08-12 22:51 ` Patrick Mansfield
2004-08-12 23:00   ` John W. Linville
2004-08-12 23:39     ` Dave Jones
2004-08-13  0:27     ` Patrick Mansfield [this message]
2004-08-13  1:21       ` John W. Linville
2004-08-13 21:32         ` Marcelo Tosatti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040813002756.GA21763@beaverton.ibm.com \
    --to=patmans@us.ibm.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.