All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: "Moore, Eric Dean" <Eric.Moore@lsil.com>
Cc: linux-scsi@vger.kernel.org, "Stephens, Larry" <larry.stephens@lsil.com>
Subject: Re: [SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07 update
Date: Tue, 9 Nov 2004 14:20:04 +0000	[thread overview]
Message-ID: <20041109142004.GA5565@infradead.org> (raw)
In-Reply-To: <91888D455306F94EBD4D168954A9457C2D1EB5@nacos172.co.lsil.com>

On Mon, Nov 08, 2004 at 04:35:06PM -0700, Moore, Eric Dean wrote:
> 
> On Saturday, November 06, 2004 4:03 PM, Christoph Hellwig wrote:
> > 
> >  - ioc->sasDeviceList still exists although it's not actually 
> > traversed,
> >    and quite a lot od dead code to fill it
> 
> Yes this is being used, and its not dead code.  Its filled and deleted
> in mptscsih.c when devices are added and removed.  It appears now
> that you had me removed the CSMI IOCTLs last week, this code will be
> needed in other aspects such as sas transport layer, misc future features, 
> and debugging.

Aka it's not used in the current code but may in the future.  Please keep
it around as a patch or whatever until your introduce actual users of it.

I'm pretty sure we will try to do this kind of bookkepping in the sas
transport class later on.

> >  - what's that ->last_lun thing about?
> 
> This fixes a bug sent to us by Tom Coughlan of Redhat; here
> is the description of the bug from Tom : 
> 
> "When SPARSELUN is set, the SCSI midlayer unconditionally probes LUN
> values up to max_lun in the SCSI host template.  In recent versions of
> the mpt fusion driver this is set to 256. The problem is that on
> non-U320 SCSI (non-packetized) the identify message is used, and its LUN
> field is only 6 bits, allowing only 64 LUNs. This causes
> selectio/reselection problems on the SCSI bus, resulting the
> configuration of non-existant devices, or maybe worse."

Just setting max_lun in struct Scsi_Host before calling scsi_scan_host
to either MPT_LAST_LUN or MPT_NON_IU_LAST_LUN should fix that issue.

The max_lun parameter in the host template is just the default value
set during scsi_host_alloc.

> >  - if you already changed the boot parameter syntax please move to
> >    a module_param for each individual parameter
> 
> I will consider moving saf-te and pt_clear seperate.
> However no change to the existing paramers that are dv 
> associated parameters passed on the same line with "mptscsih".

Well, you're disallowing one of the existant syntaxes anyway, right?

At least add a separate one for each of the parameters (and only
add those for the new parameter) so the old ones can spit a warning
and be removed after a longer timeframe.


  reply	other threads:[~2004-11-09 14:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-08 23:35 [SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07 update Moore, Eric Dean
2004-11-09 14:20 ` Christoph Hellwig [this message]
2004-11-09 16:18   ` Matthew Wilcox
2004-11-10 17:03     ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2004-11-10 17:16 Moore, Eric Dean
2004-11-10  0:26 Moore, Eric Dean
2004-11-10  8:12 ` Arjan van de Ven
2004-11-06  0:21  Moore, Eric Dean
2004-11-06 23:03 ` Christoph Hellwig

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=20041109142004.GA5565@infradead.org \
    --to=hch@infradead.org \
    --cc=Eric.Moore@lsil.com \
    --cc=larry.stephens@lsil.com \
    --cc=linux-scsi@vger.kernel.org \
    /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.