Re: [BK PATCH] SCSI updates for 2.6.6

Kurt Garloff
2004-05-17T23:07:03Z

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