RE: [SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07 update

RE: [SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07 update

[Moore, Eric Dean]

On Tuesday, November 09, 2004 7:20 AM, Christoph Hellwig wrote:
> 
> 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.
> 

This sas device list is being used in the driver, and we do
have actual users of it; and they are HP, DELL, SUN, and others. 
The CSMI IOCTLs are temporarily removed from the driver as you have 
rejected it even though I know of nobody else so far that has complained
about this.
We are in talks with HP, so lets let them decide how to proceed
on this API.  Meanwhile this sas device list is required by LSI. Besides, I 
wonder why your so strong in having this removed?  This is really small
code compared with would be required if we have to scan the topology for
each and every ioctl.


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

Ok - when will the sas transport layer be available?
CSMI is avialable today.

> 
> > >  - 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.

Ok - your suggestion is not going to work.  We only know whether IU is
enabled or not through domain validation, which is done in the context
of scsi_scan_host.  Our SCSI firmware only supports packetized at U320
speeds, and the issue came about when some device with SPARSELUN set
negotiated at Fast 80.  This implementions solves the issue reported 
by Redhat and their customers, and will be avaliable in RHEL3 Update 4.  
Its not clear to me why your wanting to break this?

RE: [SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07 update

[Arjan van de Ven]

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

On Tue, 2004-11-09 at 17:26 -0700, Moore, Eric Dean wrote:
> This sas device list is being used in the driver, and we do
> have actual users of it; and they are HP, DELL, SUN, and others. 
> The CSMI IOCTLs are temporarily removed from the driver as you have 
> rejected it even though I know of nobody else so far that has complained
> about this.

then let me jump in and say that I consider such an ioctl solution
disgusting as well.

> Ok - your suggestion is not going to work.  We only know whether IU is
> enabled or not through domain validation, which is done in the context
> of scsi_scan_host.  Our SCSI firmware only supports packetized at U320
> speeds, and the issue came about when some device with SPARSELUN set
> negotiated at Fast 80.  This implementions solves the issue reported 
> by Redhat and their customers, and will be avaliable in RHEL3 Update 4.  
> Its not clear to me why your wanting to break this?

It's "Red Hat" not "Redhat".

Also while it may be ok for a vendor to put a hack in, Christoph is
right in wanting a real solution for the kernel.org kernel. In addition
you are talking about 2.4 kernels (RHEL3) while this is about the 2.6
scsi mid layer; if the midlayer has some behavior that would cause this
to go wrong we have to fix/extend the mid layer; putting hacks in
drivers almost never is the right answer.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: [SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07 update

[Moore, Eric Dean]

Christoph - I'm working on this command line implementation right now.

I'm proposing to my co-workers to dump entirely the current 
implementation, in favor of the new one. 

Questions:
(1) MODULE_PARM is now depreciated in 2.6.10-rc.  What has replaced it?
(2) Will this new method work for command line parameters being passed
thru loading of the driver from ramdisk(initrd) image?


Here is my proposal:

# insmod mptscsih.ko dv=1 width=1 factor=0x8 saf_te=0 pt_clear=0
# modinfo mptscsih.ko

The output will be:

author:         LSI Logic Corporation
description:    Fusion MPT SCSI Host driver
license:        GPL
parm:           dv:DV Algorithm: enhanced = 1, basic = 0
(default=MPTSCSIH_DOMAIN_VALIDATION=1)
parm:           width:Max Bus Width: wide = 1, narrow = 0
(default=MPTSCSIH_MAX_WIDTH=1)
parm:           factor:Min Sync Factor: (default=MPTSCSIH_MIN_SYNC=0x08)
parm:           saf_te:Force enabling SEP Processor:
(default=MPTSCSIH_SAF_TE=0)
parm:           pt_clear:Clear persistency table:
(default=MPTSCSIH_PT_CLEAR=0)
vermagic:       2.6.10-rc1-bk18 SMP PENTIUMII REGPARM gcc-3.3
depends:        mptbase,scsi_mod,mptbase



> -----Original Message-----
> From: Christoph Hellwig [mailto:hch@infradead.org]
> Sent: Wednesday, November 10, 2004 10:04 AM
> To: Matthew Wilcox
> Cc: Christoph Hellwig; Moore, Eric Dean; linux-scsi@vger.kernel.org;
> Stephens, Larry
> Subject: Re: [SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07 update
> 
> 
> On Tue, Nov 09, 2004 at 04:18:59PM +0000, Matthew Wilcox wrote:
> > On Tue, Nov 09, 2004 at 02:20:04PM +0000, Christoph Hellwig wrote:
> > > 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.
> > 
> > This may not be possible.  It wasn't with sym2 -- the 
> module code said
> > "Oh, I found both old and new style parameters, I'm going to disable
> > the new ones".  Rusty refused to fix it, claiming he was 
> going to remove
> > the old code within a couple of minor releases.
> 
> Well, both could be module_param.
> 

Re: [SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07 update

[Christoph Hellwig]

On Tue, Nov 09, 2004 at 04:18:59PM +0000, Matthew Wilcox wrote:
> On Tue, Nov 09, 2004 at 02:20:04PM +0000, Christoph Hellwig wrote:
> > 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.
> 
> This may not be possible.  It wasn't with sym2 -- the module code said
> "Oh, I found both old and new style parameters, I'm going to disable
> the new ones".  Rusty refused to fix it, claiming he was going to remove
> the old code within a couple of minor releases.

Well, both could be module_param.

Re: [SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07 update

[Matthew Wilcox]

On Tue, Nov 09, 2004 at 02:20:04PM +0000, Christoph Hellwig wrote:
> 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.

This may not be possible.  It wasn't with sym2 -- the module code said
"Oh, I found both old and new style parameters, I'm going to disable
the new ones".  Rusty refused to fix it, claiming he was going to remove
the old code within a couple of minor releases.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: [SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07 update

[Christoph Hellwig]

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.

RE: [SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07 update

[Moore, Eric Dean]

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.

>  - the mptctl_hba_pciinfo() ioctl call is vetoed, this information
>    can be easily retrived from sysfs, and we aboslutely don't 
> want this
>    duplicated in every LLDD

fine

>  - please don't add TRUE/FALSE defines - Linux codingstyle prefers 0/1

fine

>  - 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."


>  - your forgot to kill one MPTSCSIH_DBG_TIMEOUT in ->queuecommand

fine

>  - mptscsih_slave_destroy still has the vdev != NULL check - if this
>    case still happens now that the hotremoval is fixed you're in
>    much deeper problems than this check could solve

Your correct, deleting the hotremoval stuff last week solved this.

>  - 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".

Eric

 

Re: [SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07 update

[Christoph Hellwig]

On Fri, Nov 05, 2004 at 05:21:06PM -0700,  Moore, Eric Dean wrote:
> We are pleased to announce the MPT Fusion release candidate for lk 2.6
> 
> Highlights of this release:
> ·	SAS Support - 1064, 1066, 1068
> ·	mpi headers v1.5.2
> 
> ·	Also included are hch@ suggestions from previous 3.02.06 release
> - 	remove ioc->chip_type checks, using the new bus_type member
> -	removing SAS CSMI Ioctls
> -	using scsi_remove_device and scsi_add_device => for hot swap support
> 
> This patch applied against bk://linux-scsi.bkbits.net/scsi-misc-2.6

It's still a big patch mixing various features and fixes and whitespace
changes.  Also:

 - ioc->sasDeviceList still exists although it's not actually traversed,
   and quite a lot od dead code to fill it
 - the mptctl_hba_pciinfo() ioctl call is vetoed, this information
   can be easily retrived from sysfs, and we aboslutely don't want this
   duplicated in every LLDD
 - please don't add TRUE/FALSE defines - Linux codingstyle prefers 0/1
 - what's that ->last_lun thing about?
 - your forgot to kill one MPTSCSIH_DBG_TIMEOUT in ->queuecommand
 - mptscsih_slave_destroy still has the vdev != NULL check - if this
   case still happens now that the hotremoval is fixed you're in
   much deeper problems than this check could solve
 - if you already changed the boot parameter syntax please move to
   a module_param for each individual parameter

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07 update

[Moore, Eric Dean]

We are pleased to announce the MPT Fusion release candidate for lk 2.6

Highlights of this release:
·	SAS Support - 1064, 1066, 1068
·	mpi headers v1.5.2

·	Also included are hch@ suggestions from previous 3.02.06 release
- 	remove ioc->chip_type checks, using the new bus_type member
-	removing SAS CSMI Ioctls
-	using scsi_remove_device and scsi_add_device => for hot swap support

This patch applied against bk://linux-scsi.bkbits.net/scsi-misc-2.6

Here is a link to this patch:
ftp://ftp.lsil.com/HostAdapterDrivers/linux/Fusion-MPT/2.6-kernel/3.02.07/mp
tlinux-3.02.07.patch
Full source are also provided at link above.

Eric Moore
Standard Storage Products Division
LSI Logic Corporation
Web: http://www.lsilogic.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html