LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Kurt Garloff <garloff@suse.de>
To: James Bottomley <James.Bottomley@steeleye.com>
Cc: SCSI Mailing List <linux-scsi@vger.kernel.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [BK PATCH] SCSI updates for 2.6.6
Date: Mon, 17 May 2004 21:52:42 +0200	[thread overview]
Message-ID: <20040517195241.GA4747@tpkurt.garloff.de> (raw)
In-Reply-To: <1084282961.1886.8.camel@mulgrave>

[-- Attachment #1: Type: text/plain, Size: 3432 bytes --]

Hi James,

sorry for the late response.

On Tue, May 11, 2004 at 08:42:41AM -0500, James Bottomley wrote:
> On Tue, 2004-05-11 at 07:34, Kurt Garloff wrote:
> > Should I resubmit the other SCSI scanning/blacklist patches or are they
> > queued? Or rejected?
> 
> I thought' I'd put in all the necessary ones, what's missing?

(0) scsi-log-unlikely
    Add unlikely to SCSI_CHECK_LOGGING() macro
(1) scsi-scan-deprecate-forcelun
    Mark BLIST_FORCELUN as deprecated; it should not be used.
    Don't discourage CONFIG_SCSI_MULTI_LUN so strongly.
    (Actually I believe it should always be switched on and 
     people with completely broken hardware should get it 
     blacklisted rather than "black"listing perfectly working
     devices. max_luns=1 can still be used to override it, but,
     for some reason there was no agreement about this on LSML,
     so I agreed on merging the patch as is ...)
(2) scsi-scan-blist_replun
    Introduce blacklist flags BLIST_NOREPORTLUN and BLIST_REPORTLUN2,
    so the use of REPORT_LUNS can turned off by passing dev_flags
    for a device or by default_dev_flags globally. The other flag
    allows to explicitly ask the kernel to try REPORT_LUNS on SCSI-2
    devices as well (normally it only uses it for SCSI-3 devices)
    if the host adapter does support more than 8 LUNs. This is 
    mostly for RAIDs that are connected via FC (which supports more 
    than 8 LUNs unlike SPI) that report as SCSI-2, so this flag can
    often be turned on. Just look at all the devices with 
    BLIST_SPARSELUN | BLIST_LARGELUN. Could all be nuked on the long
    term ...
    The CONFIG_SCSI_REPORT_LUNS option is killed by this patch.
(3) scsi-scan-no-offl-pq-notcon
    Don't set devices to offline if the Periph Qual is non-zero.
    Instead don't connect to them from highlevel drivers except
    for sg.
(4) scsi-scan-inq-timeout
    Make the inquiry timeout configurable by boot/module parameter;
    there are some sick devices out there who need >20s to recover
    from a bus reset; we obviously don't want to bump the default
    to 25s because of that sickness.


Only patch 3 can be found in 2.6.6.


Patch 0 should be a no-brainer.
It allows vendors to enable CONFIG_SCSI_LOGGING
without incurring possibly mispredicted branches.

Patch 1 should go in; so we announce that the insanity of blacklisting
perfectly fine SCSI devices will stop at some point in the future (2.7.)

Patch 2 should go in; a config option is only useful for people
compiling their own kernels, i.e. developers. Thus there should be the
possibility to influence the use of REPORT_LUNS at boot or runtime. 
Meanwhile the conflicting BLIST_MS_192_BYTES_FOR_3F has been defined, 
which is less than optimal. The patch would need to be rediffed and 
non-conflicting constants be used.

Patch 4 should go in; it allows users to work around sick SCSI devices
without needing to create crazy defaults.


All of these patches live in the SUSE Enterprise kernel and were
introduced because there was a need for them when supporting customers.

All patches have been discussed extensively on LSML and were changed
until opposition vanished.

If wanted, I can rediff and resubmit.

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                            Cologne, DE 
SUSE LINUX AG, Nuernberg, DE                        Director SUSE Labs

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2004-05-17 23:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-10 22:59 James Bottomley
2004-05-11 12:34 ` Kurt Garloff
2004-05-11 13:42   ` James Bottomley
2004-05-17 19:52     ` Kurt Garloff [this message]
2004-05-19 18:50       ` Kurt Garloff
2004-05-11 19:29 ` Guennadi Liakhovetski
2004-05-11 19:54   ` James Bottomley
2004-05-11 20:04     ` Christoph Hellwig
2004-05-11 20:37       ` Guennadi Liakhovetski
     [not found] <20040518184527.GC4859@tpkurt.garloff.de>
2004-05-18 19:47 ` Guennadi Liakhovetski
2004-05-18 20:38   ` James Bottomley
2004-05-21  1:06     ` Chiaki
2004-05-18 22:17   ` Matthew Wilcox

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=20040517195241.GA4747@tpkurt.garloff.de \
    --to=garloff@suse.de \
    --cc=James.Bottomley@steeleye.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --subject='Re: [BK PATCH] SCSI updates for 2.6.6' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).