[22] in linux-scsi channel archive
Re: Probing luns > 0
daemon@ATHENA.MIT.EDU (Paul Gortmaker)
Wed Jan 25 02:59:59 1995
From: Paul Gortmaker <paul@rasty.anu.edu.au>
To: linux-activists@niksula.hut.fi
Date: Wed, 25 Jan 1995 17:19:56 +1000 (EST)
Cc: linux-scsi@vger.rutgers.edu
In-Reply-To: <95Jan25.005647eet.56568-3@niksula.hut.fi> from "Linux Activists" at Jan 25, 95 00:49:15 am
>
> From: Rik Faith <faith@cs.unc.edu>
> Subject: Re: Default, no probing of luns > 0
> Date: Tue, 24 Jan 1995 10:31:09 -0500
>
>
> On Mon 23 Jan 1995 11:17:06 MST,
> Drew Eckhardt <drew@boulder.openware.com> wrote:
>
> > There are still large numbers of broken SCSI devices out there which
> > are extremely unhappy (ie, lock the SCSI bus up, do an unexpected
> > disconnect, etc) when you attempt to talk to them at a LUN other
> > than 0.
> >
> > Since very few devices use multiple LUNs (SCSI bridge boards,
> > fan out adapters, jukeboxes, and CD changers are the only
> > ones to come to mind), I think that it might be reasonable
> > to make the default maximum LUN searched 0 instead of 7.
> >
> > We could scan for the additional LUNS only when
> > - The user used the max_scsi_luns= command line
> > option.
> > - Certain vendor & model combinations were returned
> > in result for the IDENTIFY command sent to
> > LUN 0 of a given target.
> > Comments?
>
> I think this is an excellent idea and will alleviate many of the buf
> reports and problems that LUN scanning causes.
Another thing that nobody has mentioned (yet) is that we can then throw the
huge blacklist table in the garbage, which will de-bloat scsi.c
That is a major plus IMHO. Go for it.
Paul.
