linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
@ 2003-11-05  1:15 Andrew Vasquez
  2003-11-05  9:17 ` Mike Anderson
                   ` (4 more replies)
  0 siblings, 5 replies; 44+ messages in thread
From: Andrew Vasquez @ 2003-11-05  1:15 UTC (permalink / raw)
  To: Linux-Kernel, Linux-SCSI

All,

A new version of the 8.x series driver for Linux 2.6.x kernels has
been uploaded to SourceForge:

	http://sourceforge.net/projects/linux-qla2xxx/

Changes from previous release (8.00.00b5) include:

	o Intelligent RSCN handling.
	o Slab cache allocations for driver SRBs.
	o Support larger numbers of targets.
	o Initial rework of debug logging facilities.

Review the revision notes for further details of the changes in
8.00.00b6.

Beginning with this beta, distributions of the driver will only be in
the source-type tarball format.  It's not worth the extra effort of
building a separate drop-in kernel tarball, given the varying release
periods of the driver.  Similar drop-in-kernel-tarball results can be
had by:

	driver source in /tmp/qla8_b6

	# cd <kernel source>
	# patch -p1 < /tmp/qla8_b6/add_to_kernel.diff
	# mkdir drivers/scsi/qla2xxx
	# cp /tmp/qla8_b6/* drivers/scsi/qla2xxx
	# make ...

Failover functionality is present in this distribution, at this time I
do not foresee a policy change regarding its presence in the 8.x
series driver.  The next beta release of 8.x will be failover-feature
resync'd with our latest 6.x beta (6.07.xx).

Regards,
Andrew Vasquez

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-05  1:15 [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6) Andrew Vasquez
@ 2003-11-05  9:17 ` Mike Anderson
  2003-11-06  9:36 ` Christoph Hellwig
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 44+ messages in thread
From: Mike Anderson @ 2003-11-05  9:17 UTC (permalink / raw)
  To: Andrew Vasquez; +Cc: Linux-Kernel, Linux-SCSI

Andrew Vasquez [andrew.vasquez@qlogic.com] wrote:
> All,
> 
> A new version of the 8.x series driver for Linux 2.6.x kernels has
> been uploaded to SourceForge:

Thanks for the update.

Can you give more information on why clustering was turned off starting
in b5?

-andmike
--
Michael Anderson
andmike@us.ibm.com

^ permalink raw reply	[flat|nested] 44+ messages in thread

* RE: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
@ 2003-11-05 18:39 Andrew Vasquez
  2003-11-06  9:17 ` Jens Axboe
  0 siblings, 1 reply; 44+ messages in thread
From: Andrew Vasquez @ 2003-11-05 18:39 UTC (permalink / raw)
  To: Mike Anderson; +Cc: Linux-Kernel, Linux-SCSI

Mike,

> > A new version of the 8.x series driver for Linux 2.6.x kernels has
> > been uploaded to SourceForge:
> 
> Thanks for the update.
> 
> Can you give more information on why clustering was turned off
> starting in b5?
> 

This change was part of a relatively large performance-patch that was
originally against the 6.x series driver.  There were two main reasons
for disabling clustering support:

	o Given the ability of the ISP to efficiently DMA to and from
	  a significant number of data segment descriptors (via
	  command/continuation type IOCBs), there were some questions
	  regarding the benefits that clustering provided given the
	  overhead incurred by the mid-layer attempting merge the
	  requests.

	o Given the ISPs inability to handle data segments that cross
	  32-bit page boundaries, and the overhead in defensive logic
	  within the driver to prevent these cases (compare the 6.x
	  code to the 8.x code and you will see what I mean), by
	  disabling clustering we guarantee that a single SG element
	  never crosses a 4GB boundary.

Now, in 2.6 there are some significant changes.  For one, with the
block layer rewrite and the ability to limit segment boundaries of a
block queue request with the blk_queue_segment_boundary() call, a LLDD
need not concern itself with any defensive fast-path logic to handle
the 4GB cross.

So, we're left with the benefits of the overhead of this merge process
done by the block layer.  I'm certainly receptive to the notion of
reexamining the use of clustering given some solid data points showing
an (significant -- this is subjective) increase in performance and/or a
resounding 'yeah, enable it!' from those in the block-layer 'know.'

Regards,
Andrew Vasquez

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-05 18:39 Andrew Vasquez
@ 2003-11-06  9:17 ` Jens Axboe
  0 siblings, 0 replies; 44+ messages in thread
From: Jens Axboe @ 2003-11-06  9:17 UTC (permalink / raw)
  To: Andrew Vasquez; +Cc: Mike Anderson, Linux-Kernel, Linux-SCSI

On Wed, Nov 05 2003, Andrew Vasquez wrote:
> Mike,
> 
> > > A new version of the 8.x series driver for Linux 2.6.x kernels has
> > > been uploaded to SourceForge:
> > 
> > Thanks for the update.
> > 
> > Can you give more information on why clustering was turned off
> > starting in b5?
> > 
> 
> This change was part of a relatively large performance-patch that was
> originally against the 6.x series driver.  There were two main reasons
> for disabling clustering support:
> 
> 	o Given the ability of the ISP to efficiently DMA to and from
> 	  a significant number of data segment descriptors (via
> 	  command/continuation type IOCBs), there were some questions
> 	  regarding the benefits that clustering provided given the
> 	  overhead incurred by the mid-layer attempting merge the
> 	  requests.

That is valid.

> 	o Given the ISPs inability to handle data segments that cross
> 	  32-bit page boundaries, and the overhead in defensive logic
> 	  within the driver to prevent these cases (compare the 6.x
> 	  code to the 8.x code and you will see what I mean), by
> 	  disabling clustering we guarantee that a single SG element
> 	  never crosses a 4GB boundary.

That is not, however. Linux will never give you a segment crossing a 4GB
boundary, exactly because most hardware cannot handle this.

> Now, in 2.6 there are some significant changes.  For one, with the
> block layer rewrite and the ability to limit segment boundaries of a
> block queue request with the blk_queue_segment_boundary() call, a LLDD
> need not concern itself with any defensive fast-path logic to handle
> the 4GB cross.

Ditto 2.4. See BH_PHYS_4G().

> So, we're left with the benefits of the overhead of this merge process
> done by the block layer.  I'm certainly receptive to the notion of
> reexamining the use of clustering given some solid data points showing
> an (significant -- this is subjective) increase in performance and/or a
> resounding 'yeah, enable it!' from those in the block-layer 'know.'

In 2.6 clustering comes for free, so it would be silly not to enable it.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-05  1:15 [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6) Andrew Vasquez
  2003-11-05  9:17 ` Mike Anderson
@ 2003-11-06  9:36 ` Christoph Hellwig
  2003-11-06 10:51 ` Christoph Hellwig
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 44+ messages in thread
From: Christoph Hellwig @ 2003-11-06  9:36 UTC (permalink / raw)
  To: Andrew Vasquez; +Cc: Linux-Kernel, Linux-SCSI

> 	o Slab cache allocations for driver SRBs.

this one is broken.  You kall kmem_cache_alloc and kmem_cache_free
under a spinlock which is not wrong (at least with GFP_ATOMIC) but useless.
You don't have a mempool so you will deadlock under load.
You have a kmem_cache_t per host which is unessecary, one in the driver is
enough.

> the source-type tarball format.  It's not worth the extra effort of
> building a separate drop-in kernel tarball, given the varying release
> periods of the driver.  Similar drop-in-kernel-tarball results can be
> had by:


Would be nice to unpack into a directory instead of CWD, like almost any
tarball does..

> Failover functionality is present in this distribution, at this time I
> do not foresee a policy change regarding its presence in the 8.x
> series driver.  The next beta release of 8.x will be failover-feature
> resync'd with our latest 6.x beta (6.07.xx).

So it won't get merged into 2.6.x.  Not that it would be likely given your
complete ignorance of the other TODO items.  Sometimes I really wish to
get some funding to work on a mergeable qla2xxx driver as it seems impossible
to get one from qlogic..

--
Christoph Hellwig <hch@lst.de>		-	Freelance Hacker
Contact me for driver hacking and kernel development consulting

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-05  1:15 [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6) Andrew Vasquez
  2003-11-05  9:17 ` Mike Anderson
  2003-11-06  9:36 ` Christoph Hellwig
@ 2003-11-06 10:51 ` Christoph Hellwig
  2003-11-10 14:00 ` Jes Sorensen
       [not found] ` <20031114115847.GA32664@lst.de>
  4 siblings, 0 replies; 44+ messages in thread
From: Christoph Hellwig @ 2003-11-06 10:51 UTC (permalink / raw)
  To: Andrew Vasquez; +Cc: Linux-Kernel, Linux-SCSI

More comments:

 - qla_vendor.c is still unused and should be killed
 - your ioctl API gets worse and worse.  You don't expect this huge
   dungpile of ioctls all marked _BAD to be merged, do you?
   Also having different ioctl values for different plattforms is
   not an option for Linux.

^ permalink raw reply	[flat|nested] 44+ messages in thread

* RE: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
@ 2003-11-06 17:02 Andrew Vasquez
  2003-11-06 17:53 ` Matthew Wilcox
  2003-11-07  9:33 ` Christoph Hellwig
  0 siblings, 2 replies; 44+ messages in thread
From: Andrew Vasquez @ 2003-11-06 17:02 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Linux-Kernel, Linux-SCSI

Christoph,

> > 	o Slab cache allocations for driver SRBs.
> 
> this one is broken.  You kall kmem_cache_alloc and kmem_cache_free
> under a spinlock which is not wrong (at least with GFP_ATOMIC) but
> useless.  You don't have a mempool so you will deadlock under load.
> You have a kmem_cache_t per host which is unessecary, one in the
> driver is enough.
> 

Thanks, I'll take a look at this.

> > the source-type tarball format.  It's not worth the extra effort
> > of building a separate drop-in kernel tarball, given the varying
> > release periods of the driver.  Similar drop-in-kernel-tarball
> > results can be had by:
> 
> Would be nice to unpack into a directory instead of CWD, like almost
> any tarball does..
> 

Ok.

> > Failover functionality is present in this distribution, at this
> > time I do not foresee a policy change regarding its presence in
> > the 8.x series driver.  The next beta release of 8.x will be
> > failover-feature resync'd with our latest 6.x beta (6.07.xx).
> 
> So it won't get merged into 2.6.x.  Not that it would be likely
> given your complete ignorance of the other TODO items.
>

Hmm, looking through your email from July 18th, I note three main
objections that have not been addressed:

	o Build process -- (three module interface for the ISPs), I
	  personally like the idea of a shared library module used
	  between the different ISP drivers.  Many others have voiced
	  their frustrations with the single driver-binary for each
	  ISP type that the directive from management is to have a
	  single binary for all *future* products including the 
	  ISP23xx (ISP2300/ISP2310/ISP2312/ISP2322) chips.

	  That unfortunately leaves ISP2100 and ISP2200 on the
	  periphery of development efforts.

	o Failover -- DM and the fastfail infrastructure appear to be
	  in the early stages of adoption (implementation?).  There's
	  no question that QLogic will support the interfaces once
	  they mature.  Let's just agree to disagree...

	o Structure and Form -- we're slowly chipping away at much of
	  the cruft.

Thank for the feedback.

> Sometimes I really wish to get some funding to work on a mergeable
> qla2xxx driver as it seems impossible to get one from qlogic..
> 

Regards,
Andrew Vasquez
Es wird nichts so heiß gegessen, wie es gekocht wird.

^ permalink raw reply	[flat|nested] 44+ messages in thread

* RE: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
@ 2003-11-06 17:11 Andrew Vasquez
  2003-11-06 17:14 ` Jens Axboe
  0 siblings, 1 reply; 44+ messages in thread
From: Andrew Vasquez @ 2003-11-06 17:11 UTC (permalink / raw)
  To: Jens Axboe; +Cc: Mike Anderson, Linux-Kernel, Linux-SCSI

Jens,

> > 	o Given the ISPs inability to handle data segments that cross
> > 	  32-bit page boundaries, and the overhead in defensive logic
> > 	  within the driver to prevent these cases (compare the 6.x
> > 	  code to the 8.x code and you will see what I mean), by
> > 	  disabling clustering we guarantee that a single SG element
> > 	  never crosses a 4GB boundary.
> 
> That is not, however. Linux will never give you a segment crossing a
> 4GB boundary, exactly because most hardware cannot handle this.
> 
> > Now, in 2.6 there are some significant changes.  For one, with the
> > block layer rewrite and the ability to limit segment boundaries of a
> > block queue request with the blk_queue_segment_boundary() call, a LLDD
> > need not concern itself with any defensive fast-path logic to handle
> > the 4GB cross.
> 
> Ditto 2.4. See BH_PHYS_4G().
> 

Yes, but if I recall, these checks did not enter until late in the 2.4
branch.  The original (engineering) intent of the 6.x series branch
was to support all 2.4 kernels, though we are slowly (formally) moving
away from the restrictions.

> > So, we're left with the benefits of the overhead of this merge
> > process done by the block layer.  I'm certainly receptive to the
> > notion of reexamining the use of clustering given some solid data
> > points showing an (significant -- this is subjective) increase in
> > performance and/or a resounding 'yeah, enable it!' from those in
> > the block-layer 'know.'
> 
> In 2.6 clustering comes for free, so it would be silly not to enable
> it.
> 

Thanks for the clarification, I'll add the parameter back into the
template for the 8.x series driver.

Regards,
Andrew Vasquez

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-06 17:11 Andrew Vasquez
@ 2003-11-06 17:14 ` Jens Axboe
  2003-11-06 17:43   ` Arjan van de Ven
  0 siblings, 1 reply; 44+ messages in thread
From: Jens Axboe @ 2003-11-06 17:14 UTC (permalink / raw)
  To: Andrew Vasquez; +Cc: Mike Anderson, Linux-Kernel, Linux-SCSI

On Thu, Nov 06 2003, Andrew Vasquez wrote:
> Jens,
> 
> > > 	o Given the ISPs inability to handle data segments that cross
> > > 	  32-bit page boundaries, and the overhead in defensive logic
> > > 	  within the driver to prevent these cases (compare the 6.x
> > > 	  code to the 8.x code and you will see what I mean), by
> > > 	  disabling clustering we guarantee that a single SG element
> > > 	  never crosses a 4GB boundary.
> > 
> > That is not, however. Linux will never give you a segment crossing a
> > 4GB boundary, exactly because most hardware cannot handle this.
> > 
> > > Now, in 2.6 there are some significant changes.  For one, with the
> > > block layer rewrite and the ability to limit segment boundaries of a
> > > block queue request with the blk_queue_segment_boundary() call, a LLDD
> > > need not concern itself with any defensive fast-path logic to handle
> > > the 4GB cross.
> > 
> > Ditto 2.4. See BH_PHYS_4G().
> > 
> 
> Yes, but if I recall, these checks did not enter until late in the 2.4
> branch.  The original (engineering) intent of the 6.x series branch
> was to support all 2.4 kernels, though we are slowly (formally) moving
> away from the restrictions.

They were there at the same time as Linux supported > 1GB IO at all. So
that is incorrect, it's been there all along.

> > > So, we're left with the benefits of the overhead of this merge
> > > process done by the block layer.  I'm certainly receptive to the
> > > notion of reexamining the use of clustering given some solid data
> > > points showing an (significant -- this is subjective) increase in
> > > performance and/or a resounding 'yeah, enable it!' from those in
> > > the block-layer 'know.'
> > 
> > In 2.6 clustering comes for free, so it would be silly not to enable
> > it.
> > 
> 
> Thanks for the clarification, I'll add the parameter back into the
> template for the 8.x series driver.

Cool, thanks.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-06 17:14 ` Jens Axboe
@ 2003-11-06 17:43   ` Arjan van de Ven
  2003-11-06 17:50     ` Jens Axboe
  0 siblings, 1 reply; 44+ messages in thread
From: Arjan van de Ven @ 2003-11-06 17:43 UTC (permalink / raw)
  To: Jens Axboe; +Cc: Andrew Vasquez, Mike Anderson, Linux-Kernel, Linux-SCSI

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

On Thu, 2003-11-06 at 18:14, Jens Axboe wrote:

> They were there at the same time as Linux supported > 1GB IO at all. So
> that is incorrect, it's been there all along.

.... ia64


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

^ permalink raw reply	[flat|nested] 44+ messages in thread

* RE: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
@ 2003-11-06 17:45 Andrew Vasquez
  2003-11-06 17:59 ` Arjan van de Ven
  2003-11-07  9:37 ` Christoph Hellwig
  0 siblings, 2 replies; 44+ messages in thread
From: Andrew Vasquez @ 2003-11-06 17:45 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Linux-Kernel, Linux-SCSI

Christoph,

> More comments:
> 
>  - qla_vendor.c is still unused and should be killed
>

Yes, more baggage from old failover code, we should be able to kill it.

>  - your ioctl API gets worse and worse.  You don't expect this huge
>  dungpile of ioctls all marked _BAD to be merged, do you?  
>

No.  We've had this IOWR problem since the inception of 5.x series
driver.  Software (SMS 3.0) has been built on top of the this IOCTL
interface.  We painfully discovered this problem when we began to look
at other non-x86 platforms (ppc64).

>  Also having different ioctl values for different plattforms is not
>  an option for Linux.
> 

The better (right) fix would be to push this interface change onto the
caller of the IOCTLs where they can manage the differences there, and
the driver could once and for all shed itself of this nagging problem.
That is the consensus here.  The _BAD conversion was only done so the
driver would compile.

Regards,
Andrew Vasquez

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-06 17:43   ` Arjan van de Ven
@ 2003-11-06 17:50     ` Jens Axboe
  2003-11-06 17:55       ` Arjan van de Ven
  0 siblings, 1 reply; 44+ messages in thread
From: Jens Axboe @ 2003-11-06 17:50 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: Andrew Vasquez, Mike Anderson, Linux-Kernel, Linux-SCSI

On Thu, Nov 06 2003, Arjan van de Ven wrote:
> On Thu, 2003-11-06 at 18:14, Jens Axboe wrote:
> 
> > They were there at the same time as Linux supported > 1GB IO at all. So
> > that is incorrect, it's been there all along.
> 
> .... ia64

Yeah you are right, on 64-bit platforms that could have happened. I
actually thought that CONTIGUOUS_BUFFERS took care of 4GB, but on
checking it does not.

So clustering should have been disabled then (which in the in-kernel
drive it is not). Now both 2.4 and 2.6 make that guarentee. The only
argument for disabling clustering would be for 2.4 for CPU cycle
reasons.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-06 17:02 Andrew Vasquez
@ 2003-11-06 17:53 ` Matthew Wilcox
  2003-11-07  9:58   ` Christoph Hellwig
  2003-11-07  9:33 ` Christoph Hellwig
  1 sibling, 1 reply; 44+ messages in thread
From: Matthew Wilcox @ 2003-11-06 17:53 UTC (permalink / raw)
  To: Andrew Vasquez; +Cc: Christoph Hellwig, Linux-Kernel, Linux-SCSI

On Thu, Nov 06, 2003 at 09:02:28AM -0800, Andrew Vasquez wrote:
> Hmm, looking through your email from July 18th, I note three main
> objections that have not been addressed:
> 
> 	o Build process -- (three module interface for the ISPs), I
> 	  personally like the idea of a shared library module used
> 	  between the different ISP drivers.  Many others have voiced
> 	  their frustrations with the single driver-binary for each
> 	  ISP type that the directive from management is to have a
> 	  single binary for all *future* products including the 
> 	  ISP23xx (ISP2300/ISP2310/ISP2312/ISP2322) chips.
> 
> 	  That unfortunately leaves ISP2100 and ISP2200 on the
> 	  periphery of development efforts.

I wouldn't see a problem with having a structure like this:

ql2100.c
ql2200.c
ql23xx.c
qllib.c

and linking in whichever files are selected.  But you definitely only want
to build qllib.c once.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-06 17:50     ` Jens Axboe
@ 2003-11-06 17:55       ` Arjan van de Ven
  2003-11-06 17:58         ` Jens Axboe
  0 siblings, 1 reply; 44+ messages in thread
From: Arjan van de Ven @ 2003-11-06 17:55 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Arjan van de Ven, Andrew Vasquez, Mike Anderson, Linux-Kernel,
	Linux-SCSI


On Thu, Nov 06, 2003 at 06:50:32PM +0100, Jens Axboe wrote:
> drive it is not). Now both 2.4 and 2.6 make that guarentee. The only
> argument for disabling clustering would be for 2.4 for CPU cycle
> reasons.

yep; on 2.4 it's rather visible in the profiles during some benchmark
test I did (like 5% of total CPU cycles)

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-06 17:55       ` Arjan van de Ven
@ 2003-11-06 17:58         ` Jens Axboe
  0 siblings, 0 replies; 44+ messages in thread
From: Jens Axboe @ 2003-11-06 17:58 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: Andrew Vasquez, Mike Anderson, Linux-Kernel, Linux-SCSI

On Thu, Nov 06 2003, Arjan van de Ven wrote:
> 
> On Thu, Nov 06, 2003 at 06:50:32PM +0100, Jens Axboe wrote:
> > drive it is not). Now both 2.4 and 2.6 make that guarentee. The only
> > argument for disabling clustering would be for 2.4 for CPU cycle
> > reasons.
> 
> yep; on 2.4 it's rather visible in the profiles during some benchmark
> test I did (like 5% of total CPU cycles)

yeah so I gather, although 5% seems extremely excessive (512-byte raw
io, on tons of disks?).

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 44+ messages in thread

* RE: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-06 17:45 Andrew Vasquez
@ 2003-11-06 17:59 ` Arjan van de Ven
  2003-11-07  9:37 ` Christoph Hellwig
  1 sibling, 0 replies; 44+ messages in thread
From: Arjan van de Ven @ 2003-11-06 17:59 UTC (permalink / raw)
  To: Andrew Vasquez; +Cc: Christoph Hellwig, Linux-Kernel, Linux-SCSI

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

On Thu, 2003-11-06 at 18:45, Andrew Vasquez wrote:

> No.  We've had this IOWR problem since the inception of 5.x series
> driver.  Software (SMS 3.0) has been built on top of the this IOCTL

how about removing most if not all of these ioctls ?
The scsi layer has a *generic* "send passthrough" mechanism already for
example.



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

^ permalink raw reply	[flat|nested] 44+ messages in thread

* RE: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
@ 2003-11-06 19:33 Andrew Vasquez
  2003-11-07  9:39 ` Christoph Hellwig
  0 siblings, 1 reply; 44+ messages in thread
From: Andrew Vasquez @ 2003-11-06 19:33 UTC (permalink / raw)
  To: arjanv; +Cc: Christoph Hellwig, Linux-Kernel, Linux-SCSI

Arjan,

> > No.  We've had this IOWR problem since the inception of 5.x series
> > driver.  Software (SMS 3.0) has been built on top of the this
> > IOCTL
> 
> how about removing most if not all of these ioctls ?  The scsi layer
> has a *generic* "send passthrough" mechanism already for example.
> 

I'm not entirely clear on what you are alluding to here, are you
referring to SCSI_IOCTL_SEND_COMMAND?  There's significantly more
functionality embedded within the IOCTLs than simply sending passthrus
to devices.  Also, all of QLogic's drivers (linux, solaris, windows)
implement to this 'external ioctl' spec, making changes to Linux alone
would difficult.

Regards,
Andrew Vasquez

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-06 17:02 Andrew Vasquez
  2003-11-06 17:53 ` Matthew Wilcox
@ 2003-11-07  9:33 ` Christoph Hellwig
  1 sibling, 0 replies; 44+ messages in thread
From: Christoph Hellwig @ 2003-11-07  9:33 UTC (permalink / raw)
  To: Andrew Vasquez; +Cc: Linux-Kernel, Linux-SCSI

> 	o Failover -- DM and the fastfail infrastructure appear to be
> 	  in the early stages of adoption (implementation?).  There's
> 	  no question that QLogic will support the interfaces once
> 	  they mature.  Let's just agree to disagree...

Hey, there's no one saying you have to kill all your failover stuff.  Just
make it clearly optional and don't include it if_/when you submit the driver
for inclusion.  We just can't have a failover implementation for each vendor.
Not to mention that the LLDD really is the wrong place for it..


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-06 17:45 Andrew Vasquez
  2003-11-06 17:59 ` Arjan van de Ven
@ 2003-11-07  9:37 ` Christoph Hellwig
  1 sibling, 0 replies; 44+ messages in thread
From: Christoph Hellwig @ 2003-11-07  9:37 UTC (permalink / raw)
  To: Andrew Vasquez; +Cc: Linux-Kernel, Linux-SCSI

On Thu, Nov 06, 2003 at 09:45:50AM -0800, Andrew Vasquez wrote:
> No.  We've had this IOWR problem since the inception of 5.x series
> driver.  Software (SMS 3.0) has been built on top of the this IOCTL
> interface.  We painfully discovered this problem when we began to look
> at other non-x86 platforms (ppc64).

I don't know what SMS is, but Linux provides a stable ABI for stable
kernel series and only those.  We already have anough garbage from mistakes
in older kernel releases that we won't accept more with new driver
submission.  If SMS didn't use a abstraction library it would have a problem,
yes.

> >  Also having different ioctl values for different plattforms is not
> >  an option for Linux.
> > 
> 
> The better (right) fix would be to push this interface change onto the
> caller of the IOCTLs where they can manage the differences there, and
> the driver could once and for all shed itself of this nagging problem.
> That is the consensus here.  The _BAD conversion was only done so the
> driver would compile.

Sorry, I don't parse that.  There's no reason different architectures
should have differences in the ioctl calling convention, so there shouldn't
be anything to deal with in the caller either.

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-06 19:33 Andrew Vasquez
@ 2003-11-07  9:39 ` Christoph Hellwig
  0 siblings, 0 replies; 44+ messages in thread
From: Christoph Hellwig @ 2003-11-07  9:39 UTC (permalink / raw)
  To: Andrew Vasquez; +Cc: arjanv, Linux-Kernel, Linux-SCSI

On Thu, Nov 06, 2003 at 11:33:28AM -0800, Andrew Vasquez wrote:
> I'm not entirely clear on what you are alluding to here, are you
> referring to SCSI_IOCTL_SEND_COMMAND?  There's significantly more
> functionality embedded within the IOCTLs than simply sending passthrus
> to devices.  Also, all of QLogic's drivers (linux, solaris, windows)
> implement to this 'external ioctl' spec, making changes to Linux alone
> would difficult.

I thought you had a hba lib to abstract the difference away?  Once again
the proper solution would be to just exclude all the ioctl mess for a
kernel build, if your HSV IHV and other three letter acronym partners
need the broken API they can patch it in again.


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-06 17:53 ` Matthew Wilcox
@ 2003-11-07  9:58   ` Christoph Hellwig
  0 siblings, 0 replies; 44+ messages in thread
From: Christoph Hellwig @ 2003-11-07  9:58 UTC (permalink / raw)
  To: Matthew Wilcox; +Cc: Andrew Vasquez, Linux-Kernel, Linux-SCSI

On Thu, Nov 06, 2003 at 05:53:06PM +0000, Matthew Wilcox wrote:
> > 
> > 	o Build process -- (three module interface for the ISPs), I
> > 	  personally like the idea of a shared library module used
> > 	  between the different ISP drivers.  Many others have voiced
> > 	  their frustrations with the single driver-binary for each
> > 	  ISP type that the directive from management is to have a
> > 	  single binary for all *future* products including the 
> > 	  ISP23xx (ISP2300/ISP2310/ISP2312/ISP2322) chips.
> > 
> > 	  That unfortunately leaves ISP2100 and ISP2200 on the
> > 	  periphery of development efforts.
> 
> I wouldn't see a problem with having a structure like this:
> 
> ql2100.c
> ql2200.c
> ql23xx.c
> qllib.c
> 
> and linking in whichever files are selected.  But you definitely only want
> to build qllib.c once.

Well, if you look at the driver you'll need all files except the firmware
anyway.  And now that we have the request_firmware interface anyway I'd
bebetter to move that out of the module, at least once initramfs settles down
a bit.

The issue is more lots of tiny ifdefs - those in the C source could be easily
hidden using pdev->device comparisms (and I think I'm gonna submit a patch
for that soon, the driver already does that for ISP23XX variants without
a proper abstraction).  Those in the headers are a bit more difficult as the
register layout is a bit different sometimes.  But with doing these as unions
instead of ifdefs and splitted subroutines this should be managæble as well,
the feral driver already does this nicely.

-- 
Christoph Hellwig <hch@lst.de>		-	Freelance Hacker
Contact me for driver hacking and kernel development consulting
-
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

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-05  1:15 [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6) Andrew Vasquez
                   ` (2 preceding siblings ...)
  2003-11-06 10:51 ` Christoph Hellwig
@ 2003-11-10 14:00 ` Jes Sorensen
       [not found] ` <20031114115847.GA32664@lst.de>
  4 siblings, 0 replies; 44+ messages in thread
From: Jes Sorensen @ 2003-11-10 14:00 UTC (permalink / raw)
  To: Andrew Vasquez; +Cc: Linux-SCSI, jeremy, jbarnes

>>>>> "Andrew" == Andrew Vasquez <andrew.vasquez@qlogic.com> writes:

Andrew> All, A new version of the 8.x series driver for Linux 2.6.x
Andrew> kernels has been uploaded to SourceForge:

Andrew> Changes from previous release (8.00.00b5) include:

Andrew> 	o Intelligent RSCN handling.  o Slab cache allocations
Andrew> for driver SRBs.  o Support larger numbers of targets.  o
Andrew> Initial rework of debug logging facilities.

Hi Andrew,

More changes that really needs to go into the driver:
 - Call qla2x00_config_dma_addressing() before performing any
   consistent allocations. This is required since the dma mask
   settings will affect the memory pci_alloc_consistent() will return.
 - Call pci_set_consistent_dma_mask() to allow for 64 bit consistent
   allocations, required on some platforms such as the SN2.
 - Wait 20 usecs (not sure how long is really necessary, but this
   seems safe) after setting CSR_ISP_SOFT_RESET in the ctrl_status
   register as the card doesn't respond to PCI reads while in reset
   state. This causes a machine check on some architectures.
 - Flush PCI writes before calling udelay() to ensure the write is not
   sitting idle in-flight for a while before hitting the hardware.
 - Use auto-negotiate link speed when using default parameters rather
   than NVRAM settings. Disable NVRAM reading on SN2 since it's
   not possible to execute the HBA's BIOS on an SN2. I suggest doing
   something similar for all architectures that do not provide x86
   BIOS emulation.
 - Include linux/vmalloc.h in qla_os.c since it uses vmalloc()

And a quick recommendation: there's a lot of global variables in the
driver which are explicitly being initialized to zero/NULL. Please
don't do that as it forces them into the DATA segment rather than the
BSS segment. Just declaring them 'static int foo;' is sufficient.

Cheers,
Jes


diff -urN -X /usr/people/jes/exclude-linux drivers/scsi/qla2xxx-orig/qla_def.h drivers/scsi/qla2xxx/qla_def.h
--- drivers/scsi/qla2xxx-orig/qla_def.h	Tue Nov  4 15:48:29 2003
+++ drivers/scsi/qla2xxx/qla_def.h	Wed Nov  5 06:44:49 2003
@@ -727,6 +727,47 @@
 #define PD_STATE_WAIT_PORT_LOGOUT_ACK		11
 
 
+struct qla2x00_special_options
+{
+#if defined(__BIG_ENDIAN)
+	uint8_t	data_rate			:2;
+	uint8_t	enable_50_ohm_termination	:1;
+	uint8_t	unused_12			:1;
+
+	uint8_t	unused_11			:1;
+	uint8_t	unused_10			:1;
+	uint8_t	unused_9			:1;
+	uint8_t	unused_8			:1;
+
+	uint8_t	disable_auto_plogi_local_loop	:1;
+	uint8_t	enable_ooo_frame_handling	:1;
+	uint8_t	fcp_rsp_payload			:2;
+
+	uint8_t	unused_3			:1;
+	uint8_t	unused_2			:1;
+	uint8_t	soft_id_only			:1;
+	uint8_t	enable_read_xfr_rdy		:1;
+#else
+	uint8_t	enable_read_xfr_rdy		:1;
+	uint8_t	soft_id_only			:1;
+	uint8_t	unused_2			:1;
+	uint8_t	unused_3			:1;
+
+	uint8_t	fcp_rsp_payload			:2;
+	uint8_t	enable_ooo_frame_handling	:1;
+	uint8_t	disable_auto_plogi_local_loop	:1;
+
+	uint8_t	unused_8			:1;
+	uint8_t	unused_9			:1;
+	uint8_t	unused_10			:1;
+	uint8_t	unused_11			:1;
+
+	uint8_t	unused_12			:1;
+	uint8_t	enable_50_ohm_termination	:1;
+	uint8_t	data_rate			:2;
+#endif
+};
+
 /*
  * ISP Initialization Control Block.
  */
@@ -954,7 +995,7 @@
 	 * MSB BIT 6 = Data Rate (2300 only)
 	 * MSB BIT 7 = Data Rate (2300 only)
 	 */
-	uint8_t	 special_options[2];
+	struct qla2x00_special_options special_options;
 
 	/* Reserved for expanded RISC parameter block */
 	uint8_t reserved_2[24];
diff -urN -X /usr/people/jes/exclude-linux drivers/scsi/qla2xxx-orig/qla_init.c drivers/scsi/qla2xxx/qla_init.c
--- drivers/scsi/qla2xxx-orig/qla_init.c	Tue Nov  4 15:48:29 2003
+++ drivers/scsi/qla2xxx/qla_init.c	Thu Nov  6 03:23:48 2003
@@ -162,7 +162,7 @@
 		isp_init = 0;
 
 		/* If firmware needs to be loaded */
-		if (qla2x00_isp_firmware(ha) != QLA_SUCCESS) {
+		if ((rval = qla2x00_isp_firmware(ha)) != QLA_SUCCESS) {
 			if ((rval = qla2x00_chip_diag(ha)) == QLA_SUCCESS) {
 				rval = qla2x00_setup_chip(ha);
 			}
@@ -470,6 +470,12 @@
 	    ha->pdev->device == QLA2322_DEVICE_ID) {
 		udelay(10);
 	} else {
+		/*
+		 * It is necessary to for a delay here since the card 
+		 * doesn't respond to PCI reads during a reset. On some
+		 * architectures this will result in an MCA.
+		 */
+		udelay(20);
 		for (cnt = 30000; cnt; cnt--) {
 			if ((RD_REG_WORD(&reg->ctrl_status) &
 			    CSR_ISP_SOFT_RESET) == 0)
@@ -485,6 +491,10 @@
 
 	/* Release RISC processor. */
 	WRT_REG_WORD(&reg->hccr, HCCR_RELEASE_RISC);
+	/*
+	 * Flush the write so the udelay count below will be reliable
+	 */
+	RD_REG_WORD(&reg->hccr);
 
 	if (ha->pdev->device == QLA2312_DEVICE_ID ||
 	    ha->pdev->device == QLA2322_DEVICE_ID) {
@@ -546,6 +556,11 @@
 
 	/* Reset ISP chip. */
 	WRT_REG_WORD(&reg->ctrl_status, CSR_ISP_SOFT_RESET);
+	/*
+	 * We need to have a delay here since the card will not respond
+	 * while in reset causing an MCA on some architectures.
+	 */
+	udelay(20);
 	data = qla2x00_debounce_register(&reg->ctrl_status);
 	for (cnt = 6000000 ; cnt && (data & CSR_ISP_SOFT_RESET); cnt--) {
 		udelay(5);
@@ -821,6 +836,7 @@
 	WRT_REG_WORD(ISP_REQ_Q_OUT(reg), 0);
 	WRT_REG_WORD(ISP_RSP_Q_IN(reg), 0);
 	WRT_REG_WORD(ISP_RSP_Q_OUT(reg), 0);
+	RD_REG_WORD(ISP_RSP_Q_OUT(reg));
 
 	spin_unlock_irqrestore(&ha->hardware_lock, flags);
 
@@ -1162,6 +1178,16 @@
 	DEBUG5(qla2x00_dump_buffer((uint8_t *)ha->request_ring,
 	    sizeof(nvram_t)));
 
+#if defined(CONFIG_IA64_GENERIC) || defined(CONFIG_IA64_SGI_SN2)
+	/*
+	 * The SN2 does not provide BIOS emulation which means you can't
+	 * change potentially bogus BIOS settings. Force the use of
+	 * default settings.
+	 */
+	if (ia64_platform_is("sn2"))
+		chksum = 1;
+#endif
+
 	/* Bad NVRAM data, set defaults parameters. */
 	if (chksum || nv->id[0] != 'I' || nv->id[1] != 'S' ||
 	    nv->id[2] != 'P' || nv->id[3] != ' ' || nv->nvram_version < 1) {
@@ -1184,6 +1210,7 @@
 		nv->add_firmware_options[0] = BIT_5;
 		nv->add_firmware_options[1] = BIT_5 | BIT_4;
 		nv->frame_payload_size  = __constant_cpu_to_le16(2048);
+		nv->special_options.data_rate = SO_DATA_RATE_AUTO;
 #elif defined(ISP2200)
 		nv->firmware_options[0] = BIT_2 | BIT_1;
 		nv->firmware_options[1] = BIT_7 | BIT_5;
@@ -1319,8 +1346,6 @@
 	ha->operating_mode =
 	    (icb->add_firmware_options[0] & (BIT_6 | BIT_5 | BIT_4)) >> 4;
 
-	qla2x00_config_dma_addressing(ha);
-
 	ha->fw_seriallink_options[0] = nv->seriallink_options[0];
 	ha->fw_seriallink_options[1] = nv->seriallink_options[1];
 
diff -urN -X /usr/people/jes/exclude-linux drivers/scsi/qla2xxx-orig/qla_inline.h drivers/scsi/qla2xxx/qla_inline.h
--- drivers/scsi/qla2xxx-orig/qla_inline.h	Tue Nov  4 15:48:29 2003
+++ drivers/scsi/qla2xxx/qla_inline.h	Wed Nov  5 02:50:51 2003
@@ -73,6 +73,12 @@
 			ha->calc_request_entries = qla2x00_calc_iocbs_64;
 			ha->build_scsi_iocbs = qla2x00_build_scsi_iocbs_64;
 			ha->host->sg_tablesize = SG_SEGMENTS_64;
+			if (pci_set_consistent_dma_mask(ha->pdev, 0xffffffffffffffffULL)) {
+				printk(KERN_DEBUG "scsi(%ld): Failed to set 64 bit PCI"
+						" consistent mask; using 32 bit.\n",
+						ha->host_no);
+				pci_set_consistent_dma_mask(ha->pdev, 0xffffffffULL);
+			}
 		} else {
 			printk(KERN_DEBUG
 			    "scsi(%ld): Failed to set 64 bit PCI DMA mask, "
diff -urN -X /usr/people/jes/exclude-linux drivers/scsi/qla2xxx-orig/qla_os.c drivers/scsi/qla2xxx/qla_os.c
--- drivers/scsi/qla2xxx-orig/qla_os.c	Tue Nov  4 15:48:29 2003
+++ drivers/scsi/qla2xxx/qla_os.c	Thu Nov  6 03:23:52 2003
@@ -20,6 +20,7 @@
 #include "qla_os.h"
 
 #include "qla_def.h"
+#include <linux/vmalloc.h>
 
 /*
  * Driver version
@@ -2492,6 +2493,7 @@
 	    "scsi(%ld): Scatter/Gather Entries (0x%x).\n",
 	    ha->host_no, ha->host->sg_tablesize));
 
+	qla2x00_config_dma_addressing(ha);
 	if (qla2x00_mem_alloc(ha)) {
 		qla_printk(KERN_WARNING, ha,
 		    "[ERROR] Failed to allocate memory for adapter\n");

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
       [not found] ` <20031114115847.GA32664@lst.de>
@ 2003-11-17 12:18   ` Christoph Hellwig
  0 siblings, 0 replies; 44+ messages in thread
From: Christoph Hellwig @ 2003-11-17 12:18 UTC (permalink / raw)
  To: Andrew Vasquez; +Cc: linux-scsi

On Fri, Nov 14, 2003 at 12:58:47PM +0100, Christoph Hellwig wrote:
> Here's a patch to split the driver into a common qla2xxx.ko and a
> qla2?00.ko for each HBA type - the latter modules are only very small
> wrappers, mostly for the firmware images, all the meat is in the common
> qla2xxx.ko.
> 
> WARNING: the patch is only compile-tested due to lack of hardware, use
> at your own risk.

And here's another one to make the failover code optional.  It's ontop
of the previous patch

diff -uNr qla6hch/Makefile qla6nofo/Makefile
--- qla6hch/Makefile	2003-11-13 22:53:28.000000000 +0100
+++ qla6nofo/Makefile	2003-11-15 16:41:45.050000000 +0100
@@ -2,8 +2,12 @@
 EXTRA_CFLAGS += -Idrivers/scsi -DUNIQUE_FW_NAME
 
 qla2xxx-y := qla_os.o qla_init.o qla_mbx.o qla_iocb.o qla_isr.o qla_gs.o \
-	     qla_dbg.o qla_sup.o qla_rscn.o qla_xioct.o qla_inioct.o \
-	     qla_fo.o qla_cfg.o qla_cfgln.o
+	     qla_dbg.o qla_sup.o qla_rscn.o qla_xioct.o qla_inioct.o
+
+# failover code, optional
+#EXTRA_CFLAGS += -DHAVE_FAILOVER
+#qla2xxx-y += qla_fo.o qla_foln.o qla_cfg.o qla_cfgln.o
+
 qla2100-y := ql2100.o ql2100_fw.o
 qla2200-y := ql2200.o ql2200_fw.o
 qla2300-y := ql2300.o ql2300_fw.o
diff -uNr qla6hch/qla_cfg.c qla6nofo/qla_cfg.c
--- qla6hch/qla_cfg.c	2003-11-15 16:13:01.950000000 +0100
+++ qla6nofo/qla_cfg.c	2003-11-15 16:33:46.700000000 +0100
@@ -107,6 +107,11 @@
 {
 	int	rval;
 
+	if (ConfigRequired > 0)
+		mp_config_required = 1;
+	else
+		mp_config_required = 0;
+
 	ENTER("qla2x00_cfg_init");
 	set_bit(CFG_ACTIVE, &ha->cfg_flags);
 	if (!mp_initialized) {
@@ -386,7 +391,7 @@
 	DEBUG9(printk("%s(%ld): found matching ha inst %d.\n",
 	    __func__, ha->host_no, bp->HbaInstance);)
 
-	if (ha->flags.failover_enabled)
+	if (qla2x00_failover_enabled(ha)) {
 		if ((host = qla2x00_cfg_find_host(ha)) == NULL) {
 			cmd->Status = EXT_STATUS_DEV_NOT_FOUND;
 			cmd->DetailStatus = EXT_DSTATUS_HBA_INST;
@@ -397,6 +402,7 @@
 
 			return rval;
 		}
+	}
 
 	paths = (FO_PATHS_INFO *)qla2x00_kmem_zalloc(
 	    sizeof(FO_PATHS_INFO), GFP_ATOMIC, 20);
@@ -413,7 +419,7 @@
 	DEBUG9(printk("%s(%ld): found matching ha inst %d.\n",
 	    __func__, ha->host_no, bp->HbaInstance);)
 
-	if (!ha->flags.failover_enabled) {
+	if (!qla2x00_failover_enabled(ha)) {
 		/* non-fo case. There's only one path. */
 
 		mp_path_list_t	*ptmp_plist;
@@ -716,7 +722,7 @@
 		return (rval);
 	}
 
-	if (!ha->flags.failover_enabled) {
+	if (!qla2x00_failover_enabled(ha)) {
 		/* non-failover mode. nothing to be done. */
 		DEBUG9_10(printk("%s(%ld): non-failover driver mode.\n",
 		    __func__, ha->host_no);)
@@ -3017,7 +3023,7 @@
 
 	vis_host = vis_path->host;
 	if ((lq = qla2x00_lun_alloc(vis_host->ha, dp->dev_id, lun)) != NULL) {
-		qla2x00_delay_lun(vis_host->ha, lq, recoveryTime);
+		qla2x00_delay_lun(vis_host->ha, lq, ql2xrecoveryTime);
 		qla2x00_flush_failover_q(vis_host->ha, lq);
 		qla2x00_reset_lun_fo_counts(vis_host->ha, lq);
 	}
@@ -3323,48 +3329,40 @@
 }
 
 int
-qla2x00_is_fcport_in_config(scsi_qla_host_t *ha, fc_port_t *fcport)
+__qla2x00_is_fcport_in_config(scsi_qla_host_t *ha, fc_port_t *fcport)
 {
-	if (!ha->flags.failover_enabled) {
-		if (fcport->flags & FCF_PERSISTENT_BOUND)
-			return(TRUE);
-	} else {
-		mp_device_t	*dp;
-		mp_host_t	*host;
-		mp_path_t	*path;
-		mp_path_list_t	*pathlist;
-		uint16_t	dev_no;
+	mp_device_t	*dp;
+	mp_host_t	*host;
+	mp_path_t	*path;
+	mp_path_list_t	*pathlist;
+	uint16_t	dev_no;
 
-		if ((host = qla2x00_cfg_find_host(ha)) == NULL) {
-			/* no configured devices */
-			return (FALSE);
-		}
+	/* no configured devices */
+	host = qla2x00_cfg_find_host(ha);
+	if (!host)
+		return (FALSE);
 
-		for (dev_no = 0; dev_no < MAX_MP_DEVICES; dev_no++) {
-			dp = host->mp_devs[dev_no];
+	for (dev_no = 0; dev_no < MAX_MP_DEVICES; dev_no++) {
+		dp = host->mp_devs[dev_no];
 
-			if (dp == NULL)
-				continue;
+		if (dp == NULL)
+			continue;
 
-			/* Sanity check */
-			if (qla2x00_is_wwn_zero(dp->nodename))
-				continue;
+		/* Sanity check */
+		if (qla2x00_is_wwn_zero(dp->nodename))
+			continue;
 
-			if ((pathlist = dp->path_list) == NULL)
-				continue;
+		if ((pathlist = dp->path_list) == NULL)
+			continue;
 
-			path = qla2x00_find_path_by_name(host, dp->path_list,
-			    fcport->port_name);
-			if (path != NULL) {
-				/* found path for port */
-				if (path->config == TRUE) {
-					return (TRUE);
-				} else {
-					break;
-				}
-			}
+		path = qla2x00_find_path_by_name(host, dp->path_list,
+		    fcport->port_name);
+		if (path != NULL) {
+			/* found path for port */
+			if (path->config == TRUE)
+				return (TRUE);
+			break;
 		}
-
 	}
 
 	return (FALSE);
diff -uNr qla6hch/qla_def.h qla6nofo/qla_def.h
--- qla6hch/qla_def.h	2003-11-13 22:21:17.000000000 +0100
+++ qla6nofo/qla_def.h	2003-11-15 16:26:38.330000000 +0100
@@ -2229,7 +2229,6 @@
 		// UNUSED and UNASSIGNED
 		uint32_t     port_name_used          :1;   /* 4 */
 
-		uint32_t     failover_enabled        :1;   /* 5 */
 		uint32_t     watchdog_enabled        :1;   /* 6 */
 		uint32_t     cfg_suspended   	     :1;   /* 7 */
 
@@ -2501,8 +2500,7 @@
  */
 #define FLASH_IMAGE_SIZE	131072
 
-#include "qla_fo.h"
-#include "qla_cfg.h"
+#include "qla_foln.h"
 #include "qla_gbl.h"
 #include "qla_dbg.h"
 #include "qla_inline.h"
diff -uNr qla6hch/qla_fo.c qla6nofo/qla_fo.c
--- qla6hch/qla_fo.c	2003-11-13 22:19:46.000000000 +0100
+++ qla6nofo/qla_fo.c	2003-11-15 16:27:39.830000000 +0100
@@ -230,7 +230,7 @@
 	DEBUG4(printk("%s: hba %p, buff %p bp->HbaInstance(%x).\n",
 	    __func__, ha, bp, (int)bp->HbaInstance));
 
-	if (ha->flags.failover_enabled) {
+	if (qla2x00_failover_enabled(ha)) {
 		if ((host = qla2x00_cfg_find_host(ha)) == NULL) {
 			if (list_empty(&ha->fcports)) {
 				DEBUG2_9_10(printk(
@@ -353,7 +353,7 @@
 	u_entry = &u_list->DataEntry[0];
 
 	/* find the correct fcport list */
-	if (!ha->flags.failover_enabled)
+	if (!qla2x00_failover_enabled(ha))
 		fcports = &ha->fcports;
 	else
 		fcports = host->fcports;
@@ -428,7 +428,7 @@
 			continue;
 		}
 
-		if (!ha->flags.failover_enabled) {
+		if (!qla2x00_failover_enabled(ha)) {
 			/*
 			 * Failover disabled. Just return LUN mask info
 			 * in lun data entry of this port.
@@ -684,13 +684,14 @@
 	DEBUG9(printk("%s: ha inst %ld, buff %p.\n",
 	    __func__, ha->instance, bp);)
 
-	if (ha->flags.failover_enabled)
+	if (qla2x00_failover_enabled(ha)) {
 		if ((host = qla2x00_cfg_find_host(ha)) == NULL) {
 			DEBUG2_9_10(printk("%s: no HOST for ha inst %ld.\n",
 			    __func__, ha->instance);)
 			pext->Status = EXT_STATUS_DEV_NOT_FOUND;
 			return (ret);
 		}
+	}
 
 	list = (FO_LUN_DATA_LIST *)qla2x00_kmem_zalloc(
 	    sizeof(FO_LUN_DATA_LIST), GFP_ATOMIC, 13);
@@ -757,7 +758,7 @@
 			break;
 		}
 
-		if (!ha->flags.failover_enabled) {
+		if (!qla2x00_failover_enabled(ha)) {
 			/*
 			 * Failover disabled. Just find the port and set
 			 * LUN mask values in lun_mask field of this port.
@@ -876,7 +877,7 @@
 	DEBUG9(printk("%s: ha inst %ld, buff %p.\n",
 	    __func__, ha->instance, bp);)
 
-	if (ha->flags.failover_enabled)
+	if (qla2x00_failover_enabled(ha)) {
 		if ((host = qla2x00_cfg_find_host(ha)) == NULL &&
 		    list_empty(&ha->fcports)) {
 			DEBUG2_9_10(printk("%s: no HOST for ha inst %ld.\n",
@@ -884,6 +885,7 @@
 			pext->Status = EXT_STATUS_DEV_NOT_FOUND;
 			return (ret);
 		}
+	}
 
 	if ((entry = (FO_DEVICE_DATA *)kmalloc(sizeof(FO_DEVICE_DATA),
 	    GFP_ATOMIC)) == NULL) {
@@ -894,7 +896,7 @@
 	}
 
 	/* Return data accordingly. */
-	if (!ha->flags.failover_enabled)
+	if (!qla2x00_failover_enabled(ha))
 		ret = qla2x00_std_get_tgt(ha, pext, entry);
 	else
 		ret = qla2x00_fo_get_tgt(host, ha, pext, entry);
@@ -1464,7 +1466,7 @@
 	DEBUG9(printk("%s: ha inst %ld, buff %p.\n",
 	    __func__, ha->instance, bp);)
 
-	if (!ha->flags.failover_enabled)
+	if (!qla2x00_failover_enabled(ha))
 		/* non-failover mode. nothing to be done. */
 		return 0;
 
@@ -2318,12 +2320,7 @@
 uint8_t
 qla2x00_fo_enabled(scsi_qla_host_t *ha, int instance)
 {
-	uint8_t enable = FALSE;
-
-	if (ha->flags.failover_enabled)
-		enable = TRUE;
-
-	return enable;
+	return qla2x00_failover_enabled(ha);
 }
 
 /*
diff -uNr qla6hch/qla_foln.c qla6nofo/qla_foln.c
--- qla6hch/qla_foln.c	1970-01-01 01:00:00.000000000 +0100
+++ qla6nofo/qla_foln.c	2003-11-15 16:39:16.560000000 +0100
@@ -0,0 +1,294 @@
+/********************************************************************************
+*                  QLOGIC LINUX SOFTWARE
+*
+* QLogic ISP2x00 device driver for Linux 2.6.x
+* Copyright (C) 2003 QLogic Corporation
+* (www.qlogic.com)
+*
+* This program is free software; you can redistribute it and/or modify it
+* under the terms of the GNU General Public License as published by the
+* Free Software Foundation; either version 2, or (at your option) any
+* later version.
+*
+* This program is distributed in the hope that it will be useful, but
+* WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+* General Public License for more details.
+*
+******************************************************************************/
+
+#include "qla_os.h"
+#include "qla_def.h"
+
+
+int ql2xfailover = 0;
+module_param(ql2xfailover, int, 0);
+MODULE_PARM_DESC(ql2xfailover,
+		"Driver failover support: 0 to disable; 1 to enable.");
+
+int ql2xrecoveryTime = MAX_RECOVERYTIME;
+module_param_named(recoveryTime, ql2xrecoveryTime, int, 0);
+MODULE_PARM_DESC(recoveryTime,
+		"Recovery time in seconds before a target device is sent I/O "
+		"after a failback is performed.");
+
+int ql2xfailbackTime = MAX_FAILBACKTIME;
+module_param_named(failbackTime, ql2xfailbackTime, int, 0);
+MODULE_PARM_DESC(failbackTime,
+		"Delay in seconds before a failback is performed.");
+
+
+/*
+ * qla2x00_check_for_devices_online
+ *
+ *	Check fcport state of all devices to make sure online.
+ *
+ * Input:
+ *	ha = adapter block pointer.
+ *
+ * Return:
+ *	None.
+ *
+ * Context:
+ */
+static uint8_t
+qla2x00_check_for_devices_online(scsi_qla_host_t *ha) 
+{
+	fc_port_t	*fcport;
+
+	list_for_each_entry(fcport, &ha->fcports, list) {
+		if ((atomic_read(&fcport->state) == FCS_ONLINE) ||
+		    (atomic_read(&fcport->state) == FCS_DEVICE_DEAD))
+			continue;
+		return 0;
+	}
+
+	return 1;
+}
+
+/*
+ *  qla2x00_failover_cleanup
+ *	Cleanup queues after a failover.
+ *
+ * Input:
+ *	sp = command pointer
+ *
+ * Context:
+ *	Interrupt context.
+ */
+static void
+qla2x00_failover_cleanup(srb_t *sp) 
+{
+	sp->cmd->result = DID_BUS_BUSY << 16;
+	sp->cmd->host_scribble = (unsigned char *) NULL;
+
+	/* turn-off all failover flags */
+	sp->flags = sp->flags & ~(SRB_RETRY|SRB_FAILOVER|SRB_FO_CANCEL);
+}
+
+
+/*
+ *  qla2x00_process_failover
+ *	Process any command on the failover queue.
+ *
+ * Input:
+ *	ha = adapter block pointer.
+ *
+ * Context:
+ *	Interrupt context.
+ */
+static void
+qla2x00_process_failover(scsi_qla_host_t *ha) 
+{
+
+	os_tgt_t	*tq;
+	os_lun_t	*lq;
+	srb_t       *sp;
+	fc_port_t *fcport;
+	struct list_head *list, *temp;
+	unsigned long flags;
+	unsigned int	t, l;
+	scsi_qla_host_t *vis_ha = NULL;
+
+	DEBUG(printk("scsi(%ld): Processing failover for hba.\n", ha->host_no));
+
+	/*
+	 * Process all the commands in the failover queue. Attempt to failover
+	 * then either complete the command as is or requeue for retry.
+	 */
+
+	/* Prevent or allow acceptance of new I/O requests. */
+	spin_lock_irqsave(&ha->list_lock, flags);
+
+	/*
+	 * Get first entry to find our visible adapter.  We could never get
+	 * here if the list is empty
+	 */
+	list = ha->failover_queue.next;
+	sp = list_entry(list, srb_t, list);
+	vis_ha = (scsi_qla_host_t *) sp->cmd->device->host->hostdata;
+	list_for_each_safe(list, temp, &ha->failover_queue) {
+		sp = list_entry(list, srb_t, list);
+
+		tq = sp->tgt_queue;
+		lq = sp->lun_queue;
+		fcport = lq->fclun->fcport;
+
+		/* Remove srb from failover queue. */
+		__del_from_failover_queue(ha, sp);
+
+		DEBUG2(printk("%s(): pid %ld retrycnt=%d\n",
+		    __func__, sp->cmd->serial_number, sp->cmd->retries));
+
+		/*** Select an alternate path ***/
+		/* 
+		 * If the path has already been change by a previous request
+		 * sp->fclun != lq->fclun
+		 */
+		if (sp->fclun != lq->fclun ||
+		    atomic_read(&fcport->state) != FCS_DEVICE_DEAD) {
+
+			qla2x00_failover_cleanup(sp);
+
+		} else if (qla2x00_cfg_failover(ha, lq->fclun, tq, sp) ==
+		    NULL) {
+			/*
+			 * We ran out of paths, so just post the status which
+			 * is already set in the cmd.
+			 */
+			printk(KERN_INFO
+			    "scsi(%ld): Ran out of paths - pid %ld\n",
+			    ha->host_no, sp->cmd->serial_number);
+		} else {
+			qla2x00_failover_cleanup(sp);
+
+		}
+		__add_to_done_queue(ha, sp);
+	} /* list_for_each_safe */
+	spin_unlock_irqrestore(&ha->list_lock, flags);
+
+	for (t = 0; t < vis_ha->max_targets; t++) {
+		if ((tq = vis_ha->otgt[t]) == NULL)
+			continue;
+		for (l = 0; l < vis_ha->max_luns; l++) {
+			if ((lq = (os_lun_t *) tq->olun[l]) == NULL)
+				continue;
+
+			if( test_and_clear_bit(LUN_MPIO_BUSY, &lq->q_flag) ) {
+				/* EMPTY */
+				DEBUG(printk("scsi(%ld): remove suspend for "
+				    "lun %d\n", ha->host_no, lq->fclun->lun));
+			}
+		}
+	}
+
+	//qla2x00_restart_queues(ha,TRUE);
+	qla2x00_restart_queues(ha, FALSE);
+
+	DEBUG(printk("%s() - done", __func__));
+}
+
+int
+qla2x00_search_failover_queue(scsi_qla_host_t *ha, struct scsi_cmnd *cmd)
+{
+	struct list_head *list, *temp;
+	unsigned long flags;
+	srb_t *sp;
+
+	DEBUG3(printk("qla2xxx_eh_abort: searching sp %p in "
+				"failover queue.\n", sp);)
+
+	spin_lock_irqsave(&ha->list_lock, flags);
+	list_for_each_safe(list, temp, &ha->failover_queue) {
+		sp = list_entry(list, srb_t, list);
+
+		if (cmd == sp->cmd)
+			goto found;
+
+	}
+	spin_unlock_irqrestore(&ha->list_lock, flags);
+
+	return 0;
+
+ found:
+	/* Remove srb from failover queue. */
+	__del_from_failover_queue(ha, sp);
+	cmd->result = DID_ABORT << 16;
+	__add_to_done_queue(ha, sp);
+
+	spin_unlock_irqrestore(&ha->list_lock, flags);
+	return 1;
+}
+
+/*
+ * If we are not processing a ioctl or one of
+ * the ports are still MISSING or need a resync
+ * then process the failover event.
+ */  
+void
+qla2x00_process_failover_event(scsi_qla_host_t *ha)
+{
+	if (test_bit(CFG_ACTIVE, &ha->cfg_flags))
+		return;
+	if (qla2x00_check_for_devices_online(ha)) {
+		if (test_and_clear_bit(FAILOVER_EVENT, &ha->dpc_flags)) {
+			if (ha->flags.online)
+				qla2x00_cfg_event_notify(ha, ha->failover_type);
+		}
+	}
+
+	/*
+	 * Get any requests from failover queue
+	 */
+	if (test_and_clear_bit(FAILOVER_NEEDED, &ha->dpc_flags))
+		qla2x00_process_failover(ha);
+}
+
+int
+qla2x00_do_fo_check(scsi_qla_host_t *ha, srb_t *sp, scsi_qla_host_t *vis_ha)
+{
+	/*
+	 * This routine checks for DID_NO_CONNECT to decide
+	 * whether to failover to another path or not. We only
+	 * failover on that status.
+	 */
+	if (!qla2x00_fo_check(ha, sp))
+		return 0;
+
+	if ((sp->state != SRB_FAILOVER_STATE)) {
+		/*
+		 * Retry the command on this path
+		 * several times before selecting a new
+		 * path.
+		 */
+		add_to_pending_queue_head(vis_ha, sp);
+		qla2x00_next(vis_ha);
+	} else
+		qla2x00_extend_timeout(sp->cmd, EXTEND_CMD_TIMEOUT);
+
+	return 1;
+}
+
+void
+qla2xxx_start_all_adapters(scsi_qla_host_t *ha)
+{
+	struct list_head *hal;
+	scsi_qla_host_t *vis_ha;
+
+	/* Try and start all visible adapters */
+	read_lock(&qla_hostlist_lock);
+	list_for_each(hal, &qla_hostlist) {
+		vis_ha = list_entry(hal, scsi_qla_host_t, list);
+
+		if (!list_empty(&vis_ha->pending_queue))
+			qla2x00_next(vis_ha);
+
+		DEBUG2(printk("host(%ld):Commands busy=%d "
+				"failed=%d\neh_active=%d\n ",
+				vis_ha->host_no,
+				vis_ha->host->host_busy,
+				vis_ha->host->host_failed,
+				vis_ha->host->eh_active);)	
+	}
+	read_unlock(&qla_hostlist_lock);
+}
diff -uNr qla6hch/qla_foln.h qla6nofo/qla_foln.h
--- qla6hch/qla_foln.h	1970-01-01 01:00:00.000000000 +0100
+++ qla6nofo/qla_foln.h	2003-11-15 16:37:00.800000000 +0100
@@ -0,0 +1,119 @@
+/******************************************************************************
+ *                  QLOGIC LINUX SOFTWARE
+ *
+ * QLogic ISP2x00 device driver for Linux 2.6.x
+ * Copyright (C) 2003 QLogic Corporation
+ * (www.qlogic.com)
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ ******************************************************************************/
+
+#ifndef __QLA_FOLN_H
+#define	__QLA_FOLN_H
+
+#ifdef HAVE_FAILOVER
+
+#include "qla_fo.h"
+#include "qla_cfg.h"
+
+/*
+ * Global Data in qla_fo.c source file.
+ */
+extern SysFoParams_t qla_fo_params;
+
+/*
+ * Global Function Prototypes in qla_fo.c source file.
+ */
+extern scsi_qla_host_t *qla2x00_get_hba(unsigned long);
+extern uint32_t qla2x00_send_fo_notification(fc_lun_t *fclun_p, fc_lun_t *olun_p);
+extern void qla2x00_fo_init_params(scsi_qla_host_t *ha);
+extern uint8_t qla2x00_fo_enabled(scsi_qla_host_t *ha, int instance);
+extern int qla2x00_fo_ioctl(scsi_qla_host_t *, int, EXT_IOCTL *, int);
+
+extern int qla2x00_fo_missing_port_summary(scsi_qla_host_t *,
+    EXT_DEVICEDATAENTRY *, void *, uint32_t, uint32_t *, uint32_t *);
+
+/*
+ * Global Data in qla_cfg.c source file.
+ */
+extern mp_host_t  *mp_hosts_base;
+extern uint8_t   mp_config_required;
+/*
+ * Global Function Prototypes in qla_cfg.c source file.
+ */
+extern mp_host_t * qla2x00_cfg_find_host(scsi_qla_host_t *);
+extern uint8_t qla2x00_is_portname_in_device(mp_device_t *, uint8_t *);
+extern int qla2x00_cfg_path_discovery(scsi_qla_host_t *ha);
+extern int qla2x00_cfg_event_notify(scsi_qla_host_t *ha, uint32_t i_type);
+extern fc_lun_t *qla2x00_cfg_failover(scsi_qla_host_t *ha, fc_lun_t *fp,
+					      os_tgt_t *tgt, srb_t *sp);
+extern int qla2x00_cfg_get_paths( EXT_IOCTL *, FO_GET_PATHS *, int);
+extern int qla2x00_cfg_set_current_path( EXT_IOCTL *,
+			FO_SET_CURRENT_PATH *, int);
+extern void qla2x00_fo_properties(scsi_qla_host_t *ha);
+extern mp_host_t * qla2x00_add_mp_host(uint8_t *);
+extern mp_host_t * qla2x00_alloc_host(scsi_qla_host_t *);
+extern uint8_t qla2x00_fo_check(scsi_qla_host_t *ha, srb_t *sp);
+extern mp_path_t *qla2x00_find_path_by_name(mp_host_t *, mp_path_list_t *,
+			uint8_t *name);
+
+extern int __qla2x00_is_fcport_in_config(scsi_qla_host_t *, fc_port_t *);
+extern int qla2x00_cfg_init(scsi_qla_host_t *ha);
+extern void qla2x00_cfg_mem_free(scsi_qla_host_t *ha);
+
+/*
+ * Global Function Prototypes in qla_cfgln.c source file.
+ */
+extern void qla2x00_cfg_build_path_tree( scsi_qla_host_t *ha);
+extern uint8_t qla2x00_update_mp_device(mp_host_t *,
+    fc_port_t  *, uint16_t, uint16_t);
+extern void qla2x00_cfg_display_devices(void);
+
+
+/*
+ * Global Function Prototypes in qla_foln.c source file.
+ */
+extern int qla2x00_search_failover_queue(scsi_qla_host_t *, struct scsi_cmnd *);
+extern void qla2x00_process_failover_event(scsi_qla_host_t *);
+extern int qla2x00_do_fo_check(scsi_qla_host_t *, srb_t *, scsi_qla_host_t *);
+extern void qla2xxx_start_all_adapters(scsi_qla_host_t *);
+
+extern int ql2xrecoveryTime;
+extern int ql2xfailbackTime;
+extern int ql2xfailover;
+#define qla2x00_failover_enabled(ha)				(ql2xfailover)
+
+#else
+#define __qla2x00_is_fcport_in_config(ha, fcport)		(0)
+#define qla2x00_fo_missing_port_summary(ha, e, s, m, c, r)	(0)
+/* qla2x00_cfg_init() is declared int but the retval isn't checked.. */
+#define qla2x00_cfg_init(ha)					do { } while (0)
+#define qla2x00_cfg_mem_free(ha)				do { } while (0)
+#define qla2x00_cfg_display_devices()				do { } while (0)
+#define qla2x00_process_failover_event(ha)			do { } while (0)
+#define qla2xxx_start_all_adapters(ha)				do { } while (0)
+#define qla2x00_search_failover_queue(ha, cmd)			(0)
+#define qla2x00_do_fo_check(ha, sp, vis_ha)			(0)
+#define qla2x00_failover_enabled(ha)				(0)
+#endif /* HAVE_FAILOVER */
+
+static __inline int
+qla2x00_is_fcport_in_config(scsi_qla_host_t *ha, fc_port_t *fcport)
+{
+	if (qla2x00_failover_enabled(ha))
+		return __qla2x00_is_fcport_in_config(ha, fcport);
+	else if (fcport->flags & FCF_PERSISTENT_BOUND)
+		return 1;
+	return 0;
+}
+
+#endif /* __QLA_FOLN_H */
diff -uNr qla6hch/qla_gbl.h qla6nofo/qla_gbl.h
--- qla6hch/qla_gbl.h	2003-11-13 21:54:58.000000000 +0100
+++ qla6nofo/qla_gbl.h	2003-11-15 16:36:46.130000000 +0100
@@ -70,11 +70,7 @@
 extern int ql2xplogiabsentdevice;
 extern int ql2xintrdelaytimer;
 
-extern int ql2xfailover;
-
 extern int ConfigRequired;
-extern int recoveryTime;
-extern int failbackTime;
 
 extern int Bind;
 extern int ql2xsuspendcount;
@@ -260,60 +256,9 @@
 #endif
 
 /*
- * Global Data in qla_fo.c source file.
- */
-extern SysFoParams_t qla_fo_params;
-
-/*
- * Global Function Prototypes in qla_fo.c source file.
- */
-extern scsi_qla_host_t *qla2x00_get_hba(unsigned long);
-extern uint32_t qla2x00_send_fo_notification(fc_lun_t *fclun_p, fc_lun_t *olun_p);
-extern void qla2x00_fo_init_params(scsi_qla_host_t *ha);
-extern uint8_t qla2x00_fo_enabled(scsi_qla_host_t *ha, int instance);
-
-/*
- * Global Data in qla_cfg.c source file.
- */
-extern mp_host_t  *mp_hosts_base;
-extern uint8_t   mp_config_required;
-/*
- * Global Function Prototypes in qla_cfg.c source file.
- */
-extern mp_host_t * qla2x00_cfg_find_host(scsi_qla_host_t *);
-extern uint8_t qla2x00_is_portname_in_device(mp_device_t *, uint8_t *);
-extern int qla2x00_cfg_init (scsi_qla_host_t *ha);
-extern int qla2x00_cfg_path_discovery(scsi_qla_host_t *ha);
-extern int qla2x00_cfg_event_notify(scsi_qla_host_t *ha, uint32_t i_type);
-extern fc_lun_t *qla2x00_cfg_failover(scsi_qla_host_t *ha, fc_lun_t *fp,
-					      os_tgt_t *tgt, srb_t *sp);
-extern int qla2x00_cfg_get_paths( EXT_IOCTL *, FO_GET_PATHS *, int);
-extern int qla2x00_cfg_set_current_path( EXT_IOCTL *,
-			FO_SET_CURRENT_PATH *, int);
-extern void qla2x00_fo_properties(scsi_qla_host_t *ha);
-extern mp_host_t * qla2x00_add_mp_host(uint8_t *);
-extern void qla2x00_cfg_mem_free(scsi_qla_host_t *ha);
-extern mp_host_t * qla2x00_alloc_host(scsi_qla_host_t *);
-extern uint8_t qla2x00_fo_check(scsi_qla_host_t *ha, srb_t *sp);
-extern mp_path_t *qla2x00_find_path_by_name(mp_host_t *, mp_path_list_t *,
-			uint8_t *name);
-extern int qla2x00_is_fcport_in_config(scsi_qla_host_t *, fc_port_t *);
-
-/*
- * Global Function Prototypes in qla_cfgln.c source file.
- */
-extern void qla2x00_cfg_build_path_tree( scsi_qla_host_t *ha);
-extern uint8_t qla2x00_update_mp_device(mp_host_t *,
-    fc_port_t  *, uint16_t, uint16_t);
-extern void qla2x00_cfg_display_devices(void);
-
-/*
  * Global Function Prototypes in qla_xioctl.c source file.
  */
 extern void qla2x00_enqueue_aen(scsi_qla_host_t *, uint16_t, void *);
-extern int qla2x00_fo_ioctl(scsi_qla_host_t *, int, EXT_IOCTL *, int);
-extern int qla2x00_fo_missing_port_summary(scsi_qla_host_t *,
-    EXT_DEVICEDATAENTRY *, void *, uint32_t, uint32_t *, uint32_t *);
 extern int qla2x00_alloc_ioctl_mem(scsi_qla_host_t *);
 extern void qla2x00_free_ioctl_mem(scsi_qla_host_t *);
 extern int qla2x00_get_ioctl_scrap_mem(scsi_qla_host_t *, void **, uint32_t);
diff -uNr qla6hch/qla_init.c qla6nofo/qla_init.c
--- qla6hch/qla_init.c	2003-11-13 22:17:25.000000000 +0100
+++ qla6nofo/qla_init.c	2003-11-15 16:36:37.880000000 +0100
@@ -143,7 +143,7 @@
 	 */
 	if (ql2xdevconf) {
 		ha->cmdline = ql2xdevconf;
-		if (!ha->flags.failover_enabled)
+		if (!qla2x00_failover_enabled(ha))
 			qla2x00_get_properties(ha, ql2xdevconf);
 	}
 
@@ -1585,23 +1585,24 @@
 	if (!atomic_read(&ha->loop_down_timer) &&
 	    !(test_bit(LOOP_RESYNC_NEEDED, &ha->dpc_flags))) {
 
-		if (!ha->flags.failover_enabled)
+		if (!qla2x00_failover_enabled(ha))
 			qla2x00_config_os(ha);
 
 		/* If we found all devices then go ready */
 		if (!(test_bit(LOGIN_RETRY_NEEDED, &ha->dpc_flags))) {
 			ha->loop_state = LOOP_READY;
 
-			if (ha->flags.failover_enabled) {
+#ifdef HAVE_FAILOVER
+			if (qla2x00_failover_enabled(ha)) {
 				DEBUG(printk("scsi(%ld): schedule FAILBACK "
 				    "EVENT\n", ha->host_no));
 				if (!(test_and_set_bit(FAILOVER_EVENT_NEEDED,
 				    &ha->dpc_flags))) {
-					ha->failback_delay = failbackTime;
+					ha->failback_delay = ql2xfailbackTime;
 				}
 				ha->failover_type = MP_NOTIFY_LOOP_UP;
 			}
-
+#endif
 			DEBUG(printk("scsi(%ld): LOOP READY\n", ha->host_no));
 		} else {
 			if (test_bit(LOCAL_LOOP_UPDATE, &save_flags))
@@ -3113,9 +3114,6 @@
 	int		pending_q_cnt = 0;
 	struct list_head *list, *temp;
 	unsigned long flags = 0;
-	struct list_head *hal;
-	scsi_qla_host_t *vis_ha;
-
 
 	ENTER(__func__);
 
@@ -3176,25 +3174,8 @@
 			ha->failover_cnt,
 			ha->scsi_retry_q_cnt);)
 
-	if (ha->flags.failover_enabled) {
-		/* Try and start all visible adapters */
-		read_lock(&qla_hostlist_lock);
-		list_for_each(hal, &qla_hostlist) {
-			vis_ha = list_entry(hal, scsi_qla_host_t, list);
-
-			if (!list_empty(&vis_ha->pending_queue))
-				qla2x00_next(vis_ha);
-
-			DEBUG2(printk("host(%ld):Commands busy=%d "
-					"failed=%d\neh_active=%d\n ",
-					vis_ha->host_no,
-					vis_ha->host->host_busy,
-					vis_ha->host->host_failed,
-					vis_ha->host->eh_active);)	
-		}
-		read_unlock(&qla_hostlist_lock);
-	}
-
+	if (qla2x00_failover_enabled(ha))
+		qla2xxx_start_all_adapters(ha);
 	if (!list_empty(&ha->done_queue))
 		qla2x00_done(ha);
 
@@ -3353,7 +3334,7 @@
 		tq->flags |= TQF_ONLINE;
 		tq->port_down_retry_count = ha->port_down_retry_count;
 
-		if (!ha->flags.failover_enabled)
+		if (!qla2x00_failover_enabled(ha))
 			qla2x00_get_lun_mask_from_config(ha, fcport, tgt, 0);
 	}
 
diff -uNr qla6hch/qla_os.c qla6nofo/qla_os.c
--- qla6hch/qla_os.c	2003-11-13 21:56:37.000000000 +0100
+++ qla6nofo/qla_os.c	2003-11-15 16:38:20.500000000 +0100
@@ -44,11 +44,7 @@
  */
 
 char *ql2xdevconf = NULL;
-#if MPIO_SUPPORT
-int ql2xretrycount = 30;
-#else
 int ql2xretrycount = 20;
-#endif
 int qla2xenbinq = 1;
 int ql2xlogintimeout = 20;
 int qlport_down_retry = 0;
@@ -58,15 +54,7 @@
 int ql2xintrdelaytimer = 10;
 
 /* Enable for failover */
-#if MPIO_SUPPORT
-int ql2xfailover = 1;
-#else
-int ql2xfailover = 0;
-#endif
-
 int ConfigRequired = 0;
-int recoveryTime = MAX_RECOVERYTIME;
-int failbackTime = MAX_FAILBACKTIME;
 
 /* Persistent binding type */
 int Bind = BIND_BY_PORT_NAME;
@@ -85,12 +73,6 @@
 MODULE_PARM_DESC(ql2xopts,
 		"Additional driver options.");
 
-MODULE_PARM(ql2xfailover, "i");
-MODULE_PARM_DESC(ql2xfailover,
-		"Driver failover support: 0 to disable; 1 to enable. "
-		"Default behaviour based on compile-time option "
-		"MPIO_SUPPORT.");
-
 MODULE_PARM(ql2xmaxqdepth, "i");
 MODULE_PARM_DESC(ql2xmaxqdepth,
 		"Maximum queue depth to report for target devices.");
@@ -107,13 +89,12 @@
 MODULE_PARM(ql2xretrycount,"i");
 MODULE_PARM_DESC(ql2xretrycount,
 		"Maximum number of mid-layer retries allowed for a command.  "
-		"Default value in non-failover mode is 20, "
-		"in failover mode, 30.");
+		"Default value is 20, ");
 
 MODULE_PARM(displayConfig, "i");
 MODULE_PARM_DESC(displayConfig,
-		"If 1 then display the configuration used in "
-		"/etc/modules.conf.");
+		"If 1 then display the configuration used in /etc/modules.conf.");
+
 MODULE_PARM(ql2xplogiabsentdevice, "i");
 MODULE_PARM_DESC(ql2xplogiabsentdevice,
 		"Option to enable PLOGI to devices that are not present after "
@@ -130,15 +111,6 @@
 		"If 1, then only configured devices passed in through the"
 		"ql2xopts parameter will be presented to the OS");
 
-MODULE_PARM(recoveryTime, "i");
-MODULE_PARM_DESC(recoveryTime,
-		"Recovery time in seconds before a target device is sent I/O "
-		"after a failback is performed.");
-
-MODULE_PARM(failbackTime, "i");
-MODULE_PARM_DESC(failbackTime,
-		"Delay in seconds before a failback is performed.");
-
 MODULE_PARM(Bind, "i");
 MODULE_PARM_DESC(Bind,
 		"Target persistent binding method: "
@@ -495,12 +467,9 @@
 }
 
 static int qla2x00_do_dpc(void *data);
-static uint8_t qla2x00_check_for_devices_online(scsi_qla_host_t *);
 
 static void qla2x00_rst_aen(scsi_qla_host_t *);
 
-static void qla2x00_process_failover(scsi_qla_host_t *);
-
 static uint8_t qla2x00_mem_alloc(scsi_qla_host_t *);
 static void qla2x00_mem_free(scsi_qla_host_t *ha);
 int qla2x00_allocate_sp_pool( scsi_qla_host_t *ha);
@@ -1085,7 +1054,6 @@
 	return (return_status);	
 }
 
-
 /**************************************************************************
 * qla2xxx_eh_abort
 *
@@ -1140,7 +1108,7 @@
 	}
 
 	vis_ha = (scsi_qla_host_t *) cmd->device->host->hostdata;
-	if (vis_ha->flags.failover_enabled)
+	if (qla2x00_failover_enabled(vis_ha))
 		/* Get Actual HA pointer */
 		ha = (scsi_qla_host_t *)sp->ha;
 	else
@@ -1222,66 +1190,40 @@
 	/*
 	 * See if this command is in the retry queue
 	 */
-	if (!found) {
-		DEBUG3(printk("qla2xxx_eh_abort: searching sp %p in retry "
+	DEBUG3(printk("qla2xxx_eh_abort: searching sp %p in retry "
 		    "queue.\n", sp);)
 
-		spin_lock_irqsave(&ha->list_lock, flags);
-		list_for_each_safe(list, temp, &ha->retry_queue) {
-			rp = list_entry(list, srb_t, list);
+	spin_lock_irqsave(&ha->list_lock, flags);
+	list_for_each_safe(list, temp, &ha->retry_queue) {
+		rp = list_entry(list, srb_t, list);
 
-			if (cmd != rp->cmd)
-				continue;
+		if (cmd != rp->cmd)
+			continue;
 
 
-			DEBUG2(printk("qla2xxx_eh_abort: found "
-			    "in retry queue. SP=%p\n", sp);)
+		DEBUG2(printk("qla2xxx_eh_abort: found "
+		    "in retry queue. SP=%p\n", sp);)
 
-			__del_from_retry_queue(ha, rp);
-			cmd->result = DID_ABORT << 16;
-			__add_to_done_queue(ha, rp);
+		__del_from_retry_queue(ha, rp);
+		cmd->result = DID_ABORT << 16;
+		__add_to_done_queue(ha, rp);
 
-			return_status = SUCCESS;
-			found++;
+		return_status = SUCCESS;
+		found++;
 
-			break;
+		break;
 
-		} /* list_for_each_safe() */
-		spin_unlock_irqrestore(&ha->list_lock, flags);
-	}
+	} 
+	spin_unlock_irqrestore(&ha->list_lock, flags);
 
 	/*
 	 * Search failover queue
 	 */
-	if (ha->flags.failover_enabled) {
-		if (!found) {
-			DEBUG3(printk("qla2xxx_eh_abort: searching sp %p in "
-			    "failover queue.\n", sp);)
-
-			spin_lock_irqsave(&ha->list_lock, flags);
-			list_for_each_safe(list, temp, &ha->failover_queue) {
-				rp = list_entry(list, srb_t, list);
-
-				if (cmd != rp->cmd)
-					continue;
-
-				DEBUG2(printk(KERN_WARNING
-				    "qla2xxx_eh_abort: found in failover "
-				    "queue. SP=%p\n", sp);)
-
-				/* Remove srb from failover queue. */
-				__del_from_failover_queue(ha, rp);
-				cmd->result = DID_ABORT << 16;
-				__add_to_done_queue(ha, rp);
-
-				return_status = SUCCESS;
-				found++;
-
-				break;
-
-			} /* list_for_each_safe() */
-			spin_unlock_irqrestore(&ha->list_lock, flags);
-		} /*End of if !found */
+	if (qla2x00_failover_enabled(ha)) {
+		if (!found && qla2x00_search_failover_queue(ha, cmd)) {
+			return_status = SUCCESS;
+			found++;
+		}
 	}
 
 	/*
@@ -1805,8 +1747,8 @@
 	ha = (scsi_qla_host_t *)cmd->device->host->hostdata;
 	/* Find actual ha */
 	sp = (srb_t *)CMD_SP(cmd);
-	if (ha->flags.failover_enabled && sp != NULL &&
-	    ha->host->eh_active == EH_ACTIVE)
+	if (qla2x00_failover_enabled(ha) && sp &&
+			ha->host->eh_active == EH_ACTIVE)
 		ha = sp->ha;
 	else
 		ha = (scsi_qla_host_t *)cmd->device->host->hostdata;
@@ -2233,11 +2175,6 @@
 	INIT_LIST_HEAD(&ha->failover_queue);
 	INIT_LIST_HEAD(&ha->pending_queue);
 
-	if (ql2xfailover)
-		ha->flags.failover_enabled = 1;
-	else
-		ha->flags.failover_enabled = 0;
-
 	/*
 	 * These locks are used to prevent more than one CPU
 	 * from modifying the queue at the same time. The
@@ -2324,17 +2261,8 @@
 	/*
 	 * if failover is enabled read the user configuration
 	 */
-	if (ha->flags.failover_enabled) {
-		if (ConfigRequired > 0)
-			mp_config_required = 1;
-		else
-			mp_config_required = 0;
-
-		DEBUG(printk("qla2x00_detect: qla2x00_cfg_init for hba %ld\n",
-		    ha->instance));
-
+	if (qla2x00_failover_enabled(ha))
 		qla2x00_cfg_init(ha);
-	}
 
 	/* Enable chip interrupts. */
 	qla2x00_enable_intrs(ha);
@@ -2361,16 +2289,17 @@
 		schedule_timeout(5);
 	}
 
-	/* List the target we have found */
-	if (displayConfig && (!ha->flags.failover_enabled))
-		qla2x00_display_fc_names(ha);
-
 	pci_set_drvdata(pdev, ha);
 	ha->init_done = 1;
 	num_hosts++;
 
- 	if (displayConfig && ha->flags.failover_enabled)
-		qla2x00_cfg_display_devices();
+	/* List the target we have found */
+	if (displayConfig) {
+		if (qla2x00_failover_enabled(ha))
+			qla2x00_cfg_display_devices();
+		else
+			qla2x00_display_fc_names(ha);
+	}
 
 	if (scsi_add_host(host, &pdev->dev))
 		goto probe_failed;
@@ -2456,7 +2385,7 @@
 
 	qla2x00_mem_free(ha);
 
-	if (ha->flags.failover_enabled)
+	if (qla2x00_failover_enabled(ha))
 		qla2x00_cfg_mem_free(ha);
 
 	ha->flags.online = FALSE;
@@ -2659,7 +2588,7 @@
 	    ha->qthreads, ha->retry_q_cnt,
 	    ha->done_q_cnt, ha->scsi_retry_q_cnt);
 
-	if (ha->flags.failover_enabled) {
+	if (qla2x00_failover_enabled(ha)) {
 		copy_info(&info,
 		    "Number of reqs in failover_q= %d\n",
 		    ha->failover_cnt);
@@ -2743,7 +2672,7 @@
 		if ((tq = TGT_Q(ha, i)) == NULL)
 			continue;
 
-		if (ha->flags.failover_enabled) {
+		if (qla2x00_failover_enabled(ha)) {
 			copy_info(&info,
 			    "scsi-qla%d-port-%d="
 			    "%02x%02x%02x%02x%02x%02x%02x%02x:"
@@ -3539,8 +3468,6 @@
 	}
 }
 
-
-
 /**************************************************************************
 * qla2x00_do_dpc
 *   This kernel thread is a task that is schedule by the interrupt handler
@@ -3835,42 +3762,8 @@
 			    ha->host_no));
 		}
 
-		if (ha->flags.failover_enabled) {
-			/*
-			 * If we are not processing a ioctl or one of
-			 * the ports are still MISSING or need a resync
-			 * then process the failover event.
-			*/  
-			if (!test_bit(CFG_ACTIVE, &ha->cfg_flags)) {
-				if (qla2x00_check_for_devices_online(ha)) {
-					if (test_and_clear_bit(FAILOVER_EVENT, &ha->dpc_flags)) {
-
-						DEBUG(printk("scsi(%ld): qla2x00_cfg_event_notify()\n",
-						    ha->host_no));
-
-						if (ha->flags.online) {
-							qla2x00_cfg_event_notify(ha, ha->failover_type);
-						}
-
-						DEBUG(printk("scsi(%ld): qla2x00_cfg_event_notify - end\n",
-						    ha->host_no));
-					}
-				}
-
-				if (test_and_clear_bit(FAILOVER_NEEDED, &ha->dpc_flags)) {
-					/*
-					 * Get any requests from failover queue
-					 */
-					DEBUG(printk("scsi(%ld): qla2x00_process_failover()\n",
-					    ha->host_no));
-
-					qla2x00_process_failover(ha);
-
-					DEBUG(printk("scsi(%ld): qla2x00_process_failover - end\n",
-					    ha->host_no));
-				}
-			}
-		}
+		if (qla2x00_failover_enabled(ha))
+			qla2x00_process_failover_event(ha);
 
 		if (test_bit(RESTART_QUEUES_NEEDED, &ha->dpc_flags)) {
 			DEBUG(printk("scsi(%ld): qla2x00_restart_queues()\n",
@@ -3970,47 +3863,6 @@
 }
 
 /*
- * qla2x00_check_for_devices_online
- *
- *	Check fcport state of all devices to make sure online.
- *
- * Input:
- *	ha = adapter block pointer.
- *
- * Return:
- *	None.
- *
- * Context:
- */
-static uint8_t
-qla2x00_check_for_devices_online(scsi_qla_host_t *ha) 
-{
-	struct list_head	*fcpl;
-	fc_port_t	*fcport;
-	int		found, cnt;
-
-	found = 0;
-	cnt = 0;
-
-	list_for_each(fcpl, &ha->fcports) {
-		fcport = list_entry(fcpl, fc_port_t, list);
-
-		if ((atomic_read(&fcport->state) == FCS_ONLINE) ||
-			(atomic_read(&fcport->state) == FCS_DEVICE_DEAD))
-			found++;
-
-		cnt++;
-	}
-	if (cnt == found) {
-		DEBUG5(printk("%s(%ld): all online\n",
-				__func__,
-				ha->host_no);)
-		return 1;
-	} else
-		return 0;
-}
-
-/*
 *  qla2x00_rst_aen
 *      Processes asynchronous reset.
 *
@@ -4293,8 +4145,9 @@
 
 			set_bit(RESTART_QUEUES_NEEDED, &ha->dpc_flags);
 			start_dpc++;
-			if (!(ha->device_flags & DFLG_NO_CABLE) &&
-			    qla2x00_reinit && !ha->flags.failover_enabled) {
+
+			if (!qla2x00_failover_enabled(ha) && qla2x00_reinit &&
+				!(ha->device_flags & DFLG_NO_CABLE)) {
 
 				DEBUG(printk("scsi(%ld): Loop down - "
 				    "aborting ISP.\n",
@@ -4500,7 +4353,7 @@
 		 * DID_NO_CONNECT status.  Otherwise set the host_byte to
 		 * DID_BUS_BUSY to let the OS  retry this cmd.
 		 */
-		if (dest_ha->flags.failover_enabled) {
+		if (qla2x00_failover_enabled(dest_ha))  {
 			cmd->result = DID_BUS_BUSY << 16;
 		} else {
 			if ((atomic_read(&fcport->state) == FCS_DEVICE_DEAD) ||
@@ -4635,31 +4488,9 @@
 			}
 		}
 
-		if (!(sp->flags & SRB_IOCTL) && ha->flags.failover_enabled) {
-			/*
-			 * This routine checks for DID_NO_CONNECT to decide
-			 * whether to failover to another path or not. We only
-			 * failover on that status.
-			 */
-			if (qla2x00_fo_check(ha, sp)) {
-				if ((sp->state != SRB_FAILOVER_STATE)) {
-					/*
-					 * Retry the command on this path
-					 * several times before selecting a new
-					 * path.
-					 */
-					add_to_pending_queue_head(vis_ha, sp);
-					qla2x00_next(vis_ha);
-				}
-				else {
-					/* we failover this path */
-					qla2x00_extend_timeout(cmd,
-					    EXTEND_CMD_TIMEOUT);
-				}
+		if (qla2x00_failover_enabled(ha) && !(sp->flags & SRB_IOCTL))
+			if (qla2x00_do_fo_check(ha, sp, vis_ha))
 				continue;
-			}
-			
-		}
 
 		switch (host_byte(cmd->result)) {
 			case DID_OK:
@@ -4887,7 +4718,7 @@
 		/* Process response_queue if ZIO support is enabled*/ 
 		qla2x00_process_response_queue_in_zio_mode(vis_ha);
 
-		if (dest_ha && dest_ha->flags.failover_enabled)
+		if (dest_ha && qla2x00_failover_enabled(dest_ha))
 			qla2x00_process_response_queue_in_zio_mode(dest_ha);
 	}
 }
@@ -4980,128 +4811,6 @@
 	spin_unlock_irqrestore(&ha->list_lock, flags);
 }
 
-/*
- *  qla2x00_failover_cleanup
- *	Cleanup queues after a failover.
- *
- * Input:
- *	sp = command pointer
- *
- * Context:
- *	Interrupt context.
- */
-static void
-qla2x00_failover_cleanup(srb_t *sp) 
-{
-	sp->cmd->result = DID_BUS_BUSY << 16;
-	sp->cmd->host_scribble = (unsigned char *) NULL;
-
-	/* turn-off all failover flags */
-	sp->flags = sp->flags & ~(SRB_RETRY|SRB_FAILOVER|SRB_FO_CANCEL);
-}
-
-
-/*
- *  qla2x00_process_failover
- *	Process any command on the failover queue.
- *
- * Input:
- *	ha = adapter block pointer.
- *
- * Context:
- *	Interrupt context.
- */
-static void
-qla2x00_process_failover(scsi_qla_host_t *ha) 
-{
-
-	os_tgt_t	*tq;
-	os_lun_t	*lq;
-	srb_t       *sp;
-	fc_port_t *fcport;
-	struct list_head *list, *temp;
-	unsigned long flags;
-	unsigned int	t, l;
-	scsi_qla_host_t *vis_ha = NULL;
-
-	DEBUG(printk("scsi(%ld): Processing failover for hba.\n", ha->host_no));
-
-	/*
-	 * Process all the commands in the failover queue. Attempt to failover
-	 * then either complete the command as is or requeue for retry.
-	 */
-
-	/* Prevent or allow acceptance of new I/O requests. */
-	spin_lock_irqsave(&ha->list_lock, flags);
-
-	/*
-	 * Get first entry to find our visible adapter.  We could never get
-	 * here if the list is empty
-	 */
-	list = ha->failover_queue.next;
-	sp = list_entry(list, srb_t, list);
-	vis_ha = (scsi_qla_host_t *) sp->cmd->device->host->hostdata;
-	list_for_each_safe(list, temp, &ha->failover_queue) {
-		sp = list_entry(list, srb_t, list);
-
-		tq = sp->tgt_queue;
-		lq = sp->lun_queue;
-		fcport = lq->fclun->fcport;
-
-		/* Remove srb from failover queue. */
-		__del_from_failover_queue(ha, sp);
-
-		DEBUG2(printk("%s(): pid %ld retrycnt=%d\n",
-		    __func__, sp->cmd->serial_number, sp->cmd->retries));
-
-		/*** Select an alternate path ***/
-		/* 
-		 * If the path has already been change by a previous request
-		 * sp->fclun != lq->fclun
-		 */
-		if (sp->fclun != lq->fclun ||
-		    atomic_read(&fcport->state) != FCS_DEVICE_DEAD) {
-
-			qla2x00_failover_cleanup(sp);
-
-		} else if (qla2x00_cfg_failover(ha, lq->fclun, tq, sp) ==
-		    NULL) {
-			/*
-			 * We ran out of paths, so just post the status which
-			 * is already set in the cmd.
-			 */
-			printk(KERN_INFO
-			    "scsi(%ld): Ran out of paths - pid %ld\n",
-			    ha->host_no, sp->cmd->serial_number);
-		} else {
-			qla2x00_failover_cleanup(sp);
-
-		}
-		__add_to_done_queue(ha, sp);
-	} /* list_for_each_safe */
-	spin_unlock_irqrestore(&ha->list_lock, flags);
-
-	for (t = 0; t < vis_ha->max_targets; t++) {
-		if ((tq = vis_ha->otgt[t]) == NULL)
-			continue;
-		for (l = 0; l < vis_ha->max_luns; l++) {
-			if ((lq = (os_lun_t *) tq->olun[l]) == NULL)
-				continue;
-
-			if( test_and_clear_bit(LUN_MPIO_BUSY, &lq->q_flag) ) {
-				/* EMPTY */
-				DEBUG(printk("scsi(%ld): remove suspend for "
-				    "lun %d\n", ha->host_no, lq->fclun->lun));
-			}
-		}
-	}
-
-	//qla2x00_restart_queues(ha,TRUE);
-	qla2x00_restart_queues(ha, FALSE);
-
-	DEBUG(printk("%s() - done", __func__));
-}
-
 /**************************************************************************
 *   qla2x00_check_tgt_status
 *
diff -uNr qla6hch/qla_settings.h qla6nofo/qla_settings.h
--- qla6hch/qla_settings.h	2003-11-12 14:07:03.000000000 +0100
+++ qla6nofo/qla_settings.h	2003-11-15 16:30:16.920000000 +0100
@@ -37,7 +37,6 @@
 #define VSA			0	/* Volume Set Addressing */
 
 /* Failover options */
-#define MPIO_SUPPORT		0
 #define MAX_RECOVERYTIME	10	/*
 					 * Max suspend time for a lun recovery
 					 * time
diff -uNr qla6hch/qla_xioct.c qla6nofo/qla_xioct.c
--- qla6hch/qla_xioct.c	2003-11-13 21:56:05.000000000 +0100
+++ qla6nofo/qla_xioct.c	2003-11-15 16:43:11.210000000 +0100
@@ -584,6 +584,7 @@
 	   break;
 	 */
 
+#ifdef HAVE_FAILOVER
 	/* Failover IOCTLs */
 	case FO_CC_GET_PARAMS:
 	case FO_CC_SET_PARAMS:
@@ -600,6 +601,7 @@
 		qla2x00_fo_ioctl(ha, cmd, pext, mode);
 
 		break;
+#endif
 
 	default:
 	fail:
@@ -1388,10 +1390,12 @@
 
 	ptmp_hba_node->InterfaceType = EXT_DEF_FC_INTF_TYPE;
 	ptmp_hba_node->PortCount = 1;
+	ptmp_hba_node->DriverAttr = 0;
 
-
-	ptmp_hba_node->DriverAttr = (ha->flags.failover_enabled) ?
-	    DRVR_FO_ENABLED : 0;
+#ifdef HAVE_FAILOVER
+	if (qla2x00_failover_enabled(ha))
+		ptmp_hba_node->DriverAttr |= DRVR_FO_ENABLED;
+#endif
 
 	ret = verify_area(VERIFY_WRITE, (void  *)pext->ResponseAdr,
 	    sizeof(EXT_HBA_NODE));
@@ -2486,7 +2490,7 @@
 	 * in config file which don't actually exist (missing).
 	 */
 	if (ret == 0) {
-		if (!ha->flags.failover_enabled) {
+		if (!qla2x00_failover_enabled(ha)) {
 #if 0
 			ret = qla2x00_std_missing_port_summary(ha, pdd_entry,
 			    start_of_entry_list, usr_no_of_entries,

^ permalink raw reply	[flat|nested] 44+ messages in thread

* RE: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
@ 2003-11-19 23:03 Andrew Vasquez
  2003-11-19 23:18 ` Matthew Wilcox
  2003-11-20  9:19 ` Jes Sorensen
  0 siblings, 2 replies; 44+ messages in thread
From: Andrew Vasquez @ 2003-11-19 23:03 UTC (permalink / raw)
  To: Jes Sorensen; +Cc: Linux-SCSI, jeremy, jbarnes

Jes,

> More changes that really needs to go into the driver:
>  - Call qla2x00_config_dma_addressing() before performing any
>    consistent allocations. This is required since the dma mask
>    settings will affect the memory pci_alloc_consistent() will return.
>

This was definitely a problem.

>  - Call pci_set_consistent_dma_mask() to allow for 64 bit consistent
>    allocations, required on some platforms such as the SN2.
>

Yes, I believe Jeremy forwarded a patchset for the 6.x driver.

>  - Wait 20 usecs (not sure how long is really necessary, but this
>    seems safe) after setting CSR_ISP_SOFT_RESET in the ctrl_status
>    register as the card doesn't respond to PCI reads while in reset
>    state. This causes a machine check on some architectures.
>  - Flush PCI writes before calling udelay() to ensure the write is not
>    sitting idle in-flight for a while before hitting the hardware.

Yes, we also need to look at some PCI posting issues with our move to MMIO.

>  - Use auto-negotiate link speed when using default parameters rather
>    than NVRAM settings. Disable NVRAM reading on SN2 since it's
>    not possible to execute the HBA's BIOS on an SN2. 

Internally, we've been talking about taking a more defensive route
within the driver if the NVRAM data is not valid -- failing the
initialization process completely, and therefore, removing this code
completely from the driver.

We've had a number of support calls from folks that have fallen
through the catch-all path only to discover 'things' don't always work
as expected because one parameter was set or not cleared in the
doctored NVRAM data.

Manufacturing writes a pre-canned NVRAM image along with a rolling
serial number (unique to each HBA) to each card that leaves QLogic.
One obvious example of a potential problem in the case of using the
(driver) doctored NVRAM data is how to assign a unique serial number
to the ISP that is being initialized.  BTW: The serial number is actually
encoded in bytes 5, 6, and 7 of the WWPN (portname); coupled with
the hardcoded port number (33) and the QLogic copany code of (224 and
139), code from qla2x00_nvram_config():

		nv->port_name[0] = 33;
		nv->port_name[3] = 224;
		nv->port_name[4] = 139;

yield obvious results: each ISP on the host with invalid (or unread as
in the case of SN2) NVRAM data will have the same WWPN.  This (in
*most* cases) is not a good thing!

> I suggest doing something similar for all architectures that do not
> provide x86 BIOS emulation.
>

I don't believe this is going to be a safe route.  QLogic does offer
other methods to modify NVRAM parameters besides the BIOS utility, a
GUI (SANsurfer) as well as a command-line tool (SANblade CLI) - the
64bit versions are available here:

	http://www.qlogic.com/support/os_detail.asp?productid=256&osid=65

We'll need to talk more to figure this out.

>  - Include linux/vmalloc.h in qla_os.c since it uses vmalloc()
> 

Ok.

> And a quick recommendation: there's a lot of global variables in the
> driver which are explicitly being initialized to zero/NULL. Please
> don't do that as it forces them into the DATA segment rather than the
> BSS segment. Just declaring them 'static int foo;' is sufficient.
> 

Will do.



More comments below...

>  		/* If firmware needs to be loaded */
> -		if (qla2x00_isp_firmware(ha) != QLA_SUCCESS) {
> +		if ((rval = qla2x00_isp_firmware(ha)) != QLA_SUCCESS) {
>  			if ((rval = qla2x00_chip_diag(ha)) == 
> QLA_SUCCESS) {
>  				rval = qla2x00_setup_chip(ha);
>  			}

Good catch, if disable_risc_code_load is set and verify checksum
fails, poof...Typically, this flag is cleared.

>  	/* Bad NVRAM data, set defaults parameters. */
>  	if (chksum || nv->id[0] != 'I' || nv->id[1] != 'S' ||
>  	    nv->id[2] != 'P' || nv->id[3] != ' ' || 
> nv->nvram_version < 1) {
> @@ -1184,6 +1210,7 @@
>  		nv->add_firmware_options[0] = BIT_5;
>  		nv->add_firmware_options[1] = BIT_5 | BIT_4;
>  		nv->frame_payload_size  = __constant_cpu_to_le16(2048);
> +		nv->special_options.data_rate = SO_DATA_RATE_AUTO;

How about we keep the current byte array definition and add the
following code:

	nv->special_options[1] = BIT_7;

Same effect, less BE/LE structure overhead.


Thanks for the patch,

Andrew Vasquez
QLogic Corporation

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-19 23:03 Andrew Vasquez
@ 2003-11-19 23:18 ` Matthew Wilcox
  2003-11-20  9:19 ` Jes Sorensen
  1 sibling, 0 replies; 44+ messages in thread
From: Matthew Wilcox @ 2003-11-19 23:18 UTC (permalink / raw)
  To: Andrew Vasquez; +Cc: Jes Sorensen, Linux-SCSI, jeremy, jbarnes

On Wed, Nov 19, 2003 at 03:03:09PM -0800, Andrew Vasquez wrote:
> > I suggest doing something similar for all architectures that do not
> > provide x86 BIOS emulation.
> 
> I don't believe this is going to be a safe route.  QLogic does offer
> other methods to modify NVRAM parameters besides the BIOS utility, a
> GUI (SANsurfer) as well as a command-line tool (SANblade CLI) - the
> 64bit versions are available here:
> 
> 	http://www.qlogic.com/support/os_detail.asp?productid=256&osid=65

Where are the PA-RISC versions?  Where are the Alpha versions?  Where are
the Sparc versions?  This just isn't a workable solution for many people.
PCI cards really are supposed to work on all architectures.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

^ permalink raw reply	[flat|nested] 44+ messages in thread

* RE: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
@ 2003-11-19 23:38 Andrew Vasquez
  0 siblings, 0 replies; 44+ messages in thread
From: Andrew Vasquez @ 2003-11-19 23:38 UTC (permalink / raw)
  To: Matthew Wilcox; +Cc: Jes Sorensen, Linux-SCSI, jeremy, jbarnes

Matthew,

> On Wed, Nov 19, 2003 at 03:03:09PM -0800, Andrew Vasquez wrote:
> > > I suggest doing something similar for all architectures that do
> > > not provide x86 BIOS emulation.
> > 
> > I don't believe this is going to be a safe route.  QLogic does
> > offer other methods to modify NVRAM parameters besides the BIOS
> > utility, a GUI (SANsurfer) as well as a command-line tool
> > (SANblade CLI) - the 64bit versions are available here:
> > 
> > 	
> http://www.qlogic.com/support/os_detail.asp?productid=256&osid=65
> 
> Where are the PA-RISC versions?  Where are the Alpha versions?
> Where are the Sparc versions?  This just isn't a workable solution
> for many people.  

True, but we are talking about two different things here, and perhaps
I didn't make that clear in the previous email, the driver doesn't
require BIOS to exist in order to read NVRAM, NVRAM doesn't depend on
a BIOS (or EFI).  Therefore, disabling the read of NVRAM based on an
architecture's ability to provide x86 BIOS emulation does not make
sense.

> PCI cards really are supposed to work on all architectures.
> 

And they do (at least the QLogic ones).  The reason I referenced the
utilities in the first place was because the BIOS utility simply allows
you to configure NVRAM parameters.

Hope this (confus...) helps...

Regards,
Andrew Vasquez
QLogic Corporation

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-19 23:03 Andrew Vasquez
  2003-11-19 23:18 ` Matthew Wilcox
@ 2003-11-20  9:19 ` Jes Sorensen
  2003-11-21  8:43   ` Jeremy Higdon
  1 sibling, 1 reply; 44+ messages in thread
From: Jes Sorensen @ 2003-11-20  9:19 UTC (permalink / raw)
  To: Andrew Vasquez; +Cc: Linux-SCSI, jeremy, jbarnes

>>>>> "Andrew" == Andrew Vasquez <andrew.vasquez@qlogic.com> writes:

>> - Call pci_set_consistent_dma_mask() to allow for 64 bit consistent
>> allocations, required on some platforms such as the SN2.

Andrew> Yes, I believe Jeremy forwarded a patchset for the 6.x driver.

Andrew,

Yep, my patch is basically a consolidation of Jeremy's changes and a
few extras of my own.

>> - Wait 20 usecs (not sure how long is really necessary, but this
>> seems safe) after setting CSR_ISP_SOFT_RESET in the ctrl_status
>> register as the card doesn't respond to PCI reads while in reset
>> state. This causes a machine check on some architectures.  - Flush
>> PCI writes before calling udelay() to ensure the write is not
>> sitting idle in-flight for a while before hitting the hardware.

Andrew> Yes, we also need to look at some PCI posting issues with our
Andrew> move to MMIO.

I went through the init code and I didn't notice any other posting
issues, but that doesn't mean there aren't any ;-) Some of the higher
end ia64 McKinley boxees such as hte HP and SGI ones are good for
triggering these.

>> - Use auto-negotiate link speed when using default parameters
>> rather than NVRAM settings. Disable NVRAM reading on SN2 since it's
>> not possible to execute the HBA's BIOS on an SN2.

Andrew> Internally, we've been talking about taking a more defensive
Andrew> route within the driver if the NVRAM data is not valid --
Andrew> failing the initialization process completely, and therefore,
Andrew> removing this code completely from the driver.

I would really like to discourage this approach. Instead I think it
would be better to sit down with a manual and plug in safe defaults
for all the entries. I have run into the problem several times in
particular with the qla1280 based cards that the NVRAM settings were
bogus and I couldn't get to them. I don't know if this can happen with
the FC cards, but I have seen cases where machines have OEM'd SCSI
parts without and NVRAM and QL HBAs in their PCI slots, in this case
you end up with a situation where some of the devices have to be
mangled via a BIOS mangling tool and otheres require command line
parameters.

The Linux model is quite different here, we normally rely on sane
defaults in the driver and then allow users to tweek these settings in
/etc/modules.conf or through /proc at runtime.

Then there's the problems non-x86 platforms not having tools
available, and even if they are out there, they might not match the
version of glibc you are running or your distribution of choice. I
checked out your web page and I only see references to Red Hat Linux
and SuSE Linux both in 32 and 64 bit (presuming that by 32 bit you
mean x86 and by 64 bit you mean ia64 - just that naming doesn't make
any sense in the Linux space since we support a lot of different 32
and 64 bit architectures).

If the tools were open source that would make it slightly easier, but
even then you have the problem that you need to be able to boot the
system to get to the settings. If I have say an PPC64 box with my root
file system on a QL2344, I lose.

Andrew> Manufacturing writes a pre-canned NVRAM image along with a
Andrew> rolling serial number (unique to each HBA) to each card that
Andrew> leaves QLogic.  One obvious example of a potential problem in
Andrew> the case of using the (driver) doctored NVRAM data is how to
Andrew> assign a unique serial number to the ISP that is being
Andrew> initialized.  BTW: The serial number is actually encoded in
Andrew> bytes 5, 6, and 7 of the WWPN (portname); coupled with the
Andrew> hardcoded port number (33) and the QLogic copany code of (224
Andrew> and 139), code from qla2x00_nvram_config():

Ok this one is more tricky. There's a couple of options though, we
could generate a unique serial number based on the random driver
output, or maybe it's worth coming up with an infrastructure for this,
other FC card drivers will run into the same problem.

Andrew> I don't believe this is going to be a safe route.  QLogic does
Andrew> offer other methods to modify NVRAM parameters besides the
Andrew> BIOS utility, a GUI (SANsurfer) as well as a command-line tool
Andrew> (SANblade CLI) - the 64bit versions are available here:

I didn't actually know these existed, I never noticed a reference to
them in the driver. However as Matthew pointed out, they don't really
solve the problem for non-x86 and non-ia64 users.

>> /* Bad NVRAM data, set defaults parameters. */ if (chksum ||

Andrew> How about we keep the current byte array definition and add
Andrew> the following code:

Andrew> nv->special_options[1] = BIT_7;

Andrew> Same effect, less BE/LE structure overhead.

I prefer the other way, it's a lot more readable for outsiders who do
not have a copy of the firmware programming guide (such as myself).

Thanks,
Jes

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-20  9:19 ` Jes Sorensen
@ 2003-11-21  8:43   ` Jeremy Higdon
  0 siblings, 0 replies; 44+ messages in thread
From: Jeremy Higdon @ 2003-11-21  8:43 UTC (permalink / raw)
  To: Jes Sorensen; +Cc: Andrew Vasquez, Linux-SCSI, jbarnes, mdr

On Thu, Nov 20, 2003 at 04:19:33AM -0500, Jes Sorensen wrote:
> 
> Andrew> Manufacturing writes a pre-canned NVRAM image along with a
> Andrew> rolling serial number (unique to each HBA) to each card that
> Andrew> leaves QLogic.  One obvious example of a potential problem in
> Andrew> the case of using the (driver) doctored NVRAM data is how to
> Andrew> assign a unique serial number to the ISP that is being
> Andrew> initialized.  BTW: The serial number is actually encoded in
> Andrew> bytes 5, 6, and 7 of the WWPN (portname); coupled with the
> Andrew> hardcoded port number (33) and the QLogic copany code of (224
> Andrew> and 139), code from qla2x00_nvram_config():
> 
> Ok this one is more tricky. There's a couple of options though, we
> could generate a unique serial number based on the random driver
> output, or maybe it's worth coming up with an infrastructure for this,
> other FC card drivers will run into the same problem.


We should be able to read the WWPN out of the NVRAM, since there is
no reason for that to be reset.  There are various utilities/firmware
out there that actually look at an adapter's WWPN and decide whether
or not to talk to that adapter.

I think the WWPN is the only thing that we read from firmware in our
Irix driver.  We also verify the checksum, so that we can tell if the
portname is valid.

My recommendation is that the driver get the WWPN from nvram and go
with sane defaults for everything else.  Perhaps make it a config
option to read other settings from the NVRAM, but also provide command
line or config options for other settings that might need adjustment,
for those systems that cannot change nvram values.  Our experience is
that we really don't need to mess with them, however.  The only two
things that we allow adjustment to are frame size and data rate.

jeremy

^ permalink raw reply	[flat|nested] 44+ messages in thread

* RE: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
@ 2003-11-24 17:37 Andrew Vasquez
  2003-11-25  1:22 ` Jeremy Higdon
  2003-11-25  8:21 ` Jes Sorensen
  0 siblings, 2 replies; 44+ messages in thread
From: Andrew Vasquez @ 2003-11-24 17:37 UTC (permalink / raw)
  To: Jeremy Higdon, Jes Sorensen; +Cc: Linux-SCSI, jbarnes, mdr

Jeremy,

> > Andrew> Manufacturing writes a pre-canned NVRAM image along with a
> > Andrew> rolling serial number (unique to each HBA) to each card that
> > Andrew> leaves QLogic.  One obvious example of a potential problem in
> > Andrew> the case of using the (driver) doctored NVRAM data is how to
> > Andrew> assign a unique serial number to the ISP that is being
> > Andrew> initialized.  BTW: The serial number is actually encoded in
> > Andrew> bytes 5, 6, and 7 of the WWPN (portname); coupled with the
> > Andrew> hardcoded port number (33) and the QLogic copany code of (224
> > Andrew> and 139), code from qla2x00_nvram_config():
> > 
> > Ok this one is more tricky. There's a couple of options though, we
> > could generate a unique serial number based on the random driver
> > output, or maybe it's worth coming up with an infrastructure for this,
> > other FC card drivers will run into the same problem.
> 
> We should be able to read the WWPN out of the NVRAM, since there is
> no reason for that to be reset.  There are various utilities/firmware
> out there that actually look at an adapter's WWPN and decide whether
> or not to talk to that adapter.
> 
> I think the WWPN is the only thing that we read from firmware in our
> Irix driver.  We also verify the checksum, so that we can tell if the
> portname is valid.
> 
> My recommendation is that the driver get the WWPN from nvram and go
> with sane defaults for everything else.
>

Ok, then what groups of parameters would you suggest have sane
defaults.  With the patch that was provided, the following
(additional)-firmware options are set for the ISP23xx by invalidating
the checksum (SN2 behaviour):

	o Full duplex
	o Fairness
	o Full login after LIP
	o use extended firmware control block
	o Loop prefered, else point-to-point
	o Tape enabled
	o FC Confirm

Along with a large number of numeric defaults for retries, delays, a
timer counts.

> Perhaps make it a config option to read other settings from the
> NVRAM, but also provide command line or config options for other
> settings that might need adjustment, for those systems that cannot
> change nvram values.  
>

The (additional-)firmware options, perhaps a subset, seem like a
(possibily) reasonable thing to force at the driver level.  But, on
the otherhand, the retry, delay and timer counts tend to be very
customer specific based on topology and storage.  Additionally, the
driver already exports via module parameters several of the more
important driver retry and timer counts, i.e. port_down_try_count,
link_down_timeout, retry_count (try modinfo for a full list).  A user
can use these facilities to perform any fine-tuning.

> Our experience is that we really don't need to mess with them,
> however.  The only two things that we allow adjustment to are frame
> size and data rate.
> 

The driver still depend on the NVRAM to provide these values.  In many
cases, the standard NVRAM values programmed at manufacturing time
satisfy the majority of users.  Do you have boards that have 'bogus'
NVRAM settings, or are you just being cautious and not depending on
the end-user to not mess things up?

Regards,
Andrew Vasquez

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-24 17:37 Andrew Vasquez
@ 2003-11-25  1:22 ` Jeremy Higdon
  2003-11-25  8:18   ` Christoph Hellwig
  2003-11-25  8:21 ` Jes Sorensen
  1 sibling, 1 reply; 44+ messages in thread
From: Jeremy Higdon @ 2003-11-25  1:22 UTC (permalink / raw)
  To: Andrew Vasquez; +Cc: Jes Sorensen, Linux-SCSI, jbarnes, mdr

On Mon, Nov 24, 2003 at 09:37:08AM -0800, Andrew Vasquez wrote:
> Jeremy,
> 
> > We should be able to read the WWPN out of the NVRAM, since there is
> > no reason for that to be reset.  There are various utilities/firmware
> > out there that actually look at an adapter's WWPN and decide whether
> > or not to talk to that adapter.
> > 
> > I think the WWPN is the only thing that we read from firmware in our
> > Irix driver.  We also verify the checksum, so that we can tell if the
> > portname is valid.
> > 
> > My recommendation is that the driver get the WWPN from nvram and go
> > with sane defaults for everything else.
> >
> 
> Ok, then what groups of parameters would you suggest have sane
> defaults.  With the patch that was provided, the following
> (additional)-firmware options are set for the ISP23xx by invalidating
> the checksum (SN2 behaviour):
> 
> 	o Full duplex
> 	o Fairness
> 	o Full login after LIP
> 	o use extended firmware control block
> 	o Loop prefered, else point-to-point
> 	o Tape enabled
> 	o FC Confirm

Right.
I want to confirm that "Loop prefered, else point-to-point" means
connection mode 2, which actually means that if you have a device
that can do both, you get point-to-point mode, right?

> Along with a large number of numeric defaults for retries, delays, a
> timer counts.
> 
> > Perhaps make it a config option to read other settings from the
> > NVRAM, but also provide command line or config options for other
> > settings that might need adjustment, for those systems that cannot
> > change nvram values.  
> >
> 
> The (additional-)firmware options, perhaps a subset, seem like a
> (possibily) reasonable thing to force at the driver level.  But, on
> the otherhand, the retry, delay and timer counts tend to be very
> customer specific based on topology and storage.  Additionally, the
> driver already exports via module parameters several of the more
> important driver retry and timer counts, i.e. port_down_try_count,
> link_down_timeout, retry_count (try modinfo for a full list).  A user
> can use these facilities to perform any fine-tuning.

This sounds fine, though a little unwieldy.  You can't do much about
the unwieldiness, though.

> > Our experience is that we really don't need to mess with them,
> > however.  The only two things that we allow adjustment to are frame
> > size and data rate.
> > 
> 
> The driver still depend on the NVRAM to provide these values.  In many
> cases, the standard NVRAM values programmed at manufacturing time
> satisfy the majority of users.  Do you have boards that have 'bogus'
> NVRAM settings, or are you just being cautious and not depending on
> the end-user to not mess things up?

We don't use NVRAM settings on Irix.
We do have a number of 2300-type boards which, for example, don't work
in 2GB mode unless you bypass the NVRAM setting.  There are also problems
with using 1KB frames instead of 2KB frames.

How about a config option that bypasses the NVRAM.  That way, if one
of your customers wants to use it to set different values, they can
use NVRAM.  If others don't want to use NVRAM, then they won't.


jeremy

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-25  1:22 ` Jeremy Higdon
@ 2003-11-25  8:18   ` Christoph Hellwig
  0 siblings, 0 replies; 44+ messages in thread
From: Christoph Hellwig @ 2003-11-25  8:18 UTC (permalink / raw)
  To: Jeremy Higdon; +Cc: Andrew Vasquez, Jes Sorensen, Linux-SCSI, jbarnes, mdr

On Mon, Nov 24, 2003 at 05:22:47PM -0800, Jeremy Higdon wrote:
> We don't use NVRAM settings on Irix.
> We do have a number of 2300-type boards which, for example, don't work
> in 2GB mode unless you bypass the NVRAM setting.  There are also problems
> with using 1KB frames instead of 2KB frames.
> 
> How about a config option that bypasses the NVRAM.  That way, if one
> of your customers wants to use it to set different values, they can
> use NVRAM.  If others don't want to use NVRAM, then they won't.

Wouldn't life be much easier if we just had a tiny opesource tool to
modify the nvram?, nothing fancy, just numerical setting of the values..


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-24 17:37 Andrew Vasquez
  2003-11-25  1:22 ` Jeremy Higdon
@ 2003-11-25  8:21 ` Jes Sorensen
  1 sibling, 0 replies; 44+ messages in thread
From: Jes Sorensen @ 2003-11-25  8:21 UTC (permalink / raw)
  To: Andrew Vasquez; +Cc: Jeremy Higdon, Linux-SCSI, jbarnes, mdr

>>>>> "Andrew" == Andrew Vasquez <andrew.vasquez@qlogic.com> writes:

Andrew> The (additional-)firmware options, perhaps a subset, seem like
Andrew> a (possibily) reasonable thing to force at the driver level.
Andrew> But, on the otherhand, the retry, delay and timer counts tend
Andrew> to be very customer specific based on topology and storage.
Andrew> Additionally, the driver already exports via module parameters
Andrew> several of the more important driver retry and timer counts,
Andrew> i.e. port_down_try_count, link_down_timeout, retry_count (try
Andrew> modinfo for a full list).  A user can use these facilities to
Andrew> perform any fine-tuning.

Andrew,

I would be a nice feature if all these tuning parameters were exported
via sysfs in 2.6 allowing users to modify them at runtime without
having to reload the module every time. It would be very useful to
test tuning parameters etc.

Cheers,
Jes

^ permalink raw reply	[flat|nested] 44+ messages in thread

* RE: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
@ 2003-11-25 19:29 Andrew Vasquez
  2003-11-25 23:31 ` Jeremy Higdon
  0 siblings, 1 reply; 44+ messages in thread
From: Andrew Vasquez @ 2003-11-25 19:29 UTC (permalink / raw)
  To: Jeremy Higdon; +Cc: Jes Sorensen, Linux-SCSI, jbarnes, mdr

On Monday, November 24, 2003 5:23 PM, Jeremy Higdon wrote:

> On Mon, Nov 24, 2003 at 09:37:08AM -0800, Andrew Vasquez wrote:
> > Ok, then what groups of parameters would you suggest have sane
> > defaults.  With the patch that was provided, the following
> > (additional)-firmware options are set for the ISP23xx by
> > invalidating the checksum (SN2 behaviour): 
> > 
> > 	o Full duplex
> > 	o Fairness
> > 	o Full login after LIP
> > 	o use extended firmware control block
> > 	o Loop prefered, else point-to-point
> > 	o Tape enabled
> > 	o FC Confirm
> 
> Right.
> I want to confirm that "Loop prefered, else point-to-point" means
> connection mode 2, which actually means that if you have a device
> that can do both, you get point-to-point mode, right?
> 

Yes, connection mode 2 is loop-preferred, else point-to-point.  But,
in your example of a device supporting both and the HBA coming up in 
point-to-point mode is probably due to the connected device's desire to
come up in point-to-point mode.  This is a typical scenario of how a
switch behaves when an HBA first negotiates a link -- can do loop,
tries point-to-point, if fails, fallback to loop.

> > The (additional-)firmware options, perhaps a subset, seem like a
> > (possibily) reasonable thing to force at the driver level.  But, on
> > the otherhand, the retry, delay and timer counts tend to be very
> > customer specific based on topology and storage.  Additionally, the
> > driver already exports via module parameters several of the more
> > important driver retry and timer counts, i.e. port_down_try_count,
> > link_down_timeout, retry_count (try modinfo for a full list).  A
> > user can use these facilities to perform any fine-tuning.
> 
> This sounds fine, though a little unwieldy.  You can't do much about
> the unwieldiness, though. 
> 

Yes, it's certainly looking so...

> > The driver still depend on the NVRAM to provide these values.  In
> > many cases, the standard NVRAM values programmed at manufacturing
> > time satisfy the majority of users.  Do you have boards that have
> > 'bogus' NVRAM settings, or are you just being cautious and not
> > depending on the end-user to not mess things up?
> 
> We don't use NVRAM settings on Irix.
> We do have a number of 2300-type boards which, for example, don't work
> in 2GB mode unless you bypass the NVRAM setting.
>

Hmm, is the NVRAM data-rate set to 1gb?

> There are also problems with using 1KB frames instead of 2KB frames.
> 
> How about a config option that bypasses the NVRAM.  That way, if one
> of your customers wants to use it to set different values, they can
> use NVRAM.  If others don't want to use NVRAM, then they won't.
> 

Perhaps our best route would be to provide a opensource tool to do
NVRAM updates (as Christoph suggested in an ealier email).  I'll see
what I can do to get that to happen.

Regards,
Andrew Vasquez

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-25 19:29 Andrew Vasquez
@ 2003-11-25 23:31 ` Jeremy Higdon
  2003-11-27  1:20   ` Jeremy Higdon
  0 siblings, 1 reply; 44+ messages in thread
From: Jeremy Higdon @ 2003-11-25 23:31 UTC (permalink / raw)
  To: Andrew Vasquez; +Cc: Jes Sorensen, Linux-SCSI, jbarnes, mdr

On Tue, Nov 25, 2003 at 11:29:40AM -0800, Andrew Vasquez wrote:
> 
> > There are also problems with using 1KB frames instead of 2KB frames.
> > 
> > How about a config option that bypasses the NVRAM.  That way, if one
> > of your customers wants to use it to set different values, they can
> > use NVRAM.  If others don't want to use NVRAM, then they won't.
> > 
> 
> Perhaps our best route would be to provide a opensource tool to do
> NVRAM updates (as Christoph suggested in an ealier email).  I'll see
> what I can do to get that to happen.


Yes, that would be best.

jeremy

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-11-25 23:31 ` Jeremy Higdon
@ 2003-11-27  1:20   ` Jeremy Higdon
  0 siblings, 0 replies; 44+ messages in thread
From: Jeremy Higdon @ 2003-11-27  1:20 UTC (permalink / raw)
  To: Andrew Vasquez; +Cc: Jes Sorensen, Linux-SCSI, jbarnes, mdr

I've found a problem with the driver on our SN2 system.  There
needs to be a register read after updating the Request Queue In
index, prior to releasing the host spin lock.

The calls to sn_mmiob() will need to be replaced by reading an
appropriate register on the chip.  sn_mmiob() is a lightweight
way of doing the same thing without having to go to the chip,
but only on SGI SN platforms.



--- drivers/scsi/qla2xxx/qla_iocb.c	Wed Nov 26 17:28:26 2003
+++ ../qla2xxx/qla_iocb.c	Tue Nov	 4 15:48:29 2003
@@ -506,7 +506,6 @@
	/* Set chip new ring index. */
	reg_flushed = CACHE_FLUSH(ISP_REQ_Q_IN(reg));
	WRT_REG_WORD(ISP_REQ_Q_IN(reg), ha->req_ring_index);
-	sn_mmiob();
 
	spin_unlock_irqrestore(&ha->hardware_lock, flags);
	return (QLA_SUCCESS);
@@ -778,7 +777,6 @@
 
	/* Set chip new ring index. */
	WRT_REG_WORD(ISP_REQ_Q_IN(reg), ha->req_ring_index);
-	sn_mmiob();
 
	LEAVE(__func__);
 }


^ permalink raw reply	[flat|nested] 44+ messages in thread

* RE: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
@ 2003-12-01 23:21 Andrew Vasquez
  2003-12-02  2:02 ` Jeremy Higdon
  2003-12-02  3:22 ` Jeremy Higdon
  0 siblings, 2 replies; 44+ messages in thread
From: Andrew Vasquez @ 2003-12-01 23:21 UTC (permalink / raw)
  To: Jeremy Higdon; +Cc: Jes Sorensen, Linux-SCSI, jbarnes, mdr

On Wednesday, November 26, 2003 5:20 PM, Jeremy Higdon wrote:

> I've found a problem with the driver on our SN2 system.  There needs
> to be a register read after updating the Request Queue In index,
> prior to releasing the host spin lock.
> 
> The calls to sn_mmiob() will need to be replaced by reading an
> appropriate register on the chip.  sn_mmiob() is a lightweight way
> of doing the same thing without having to go to the chip, but only
> on SGI SN platforms. 
> 

I'm curious, what types of symptoms were exibited without the
sn_mmiob() call?  Did I/O stall?

BTW: The CACHE_FLUSH() call:

	/* Set chip new ring index. */
	reg_flushed = CACHE_FLUSH(ISP_REQ_Q_IN(reg));

preceeding the WRT_REG_WORD() has been removed from my working tree
(remnants of an ancient motherboard problem with an on-board ISP while
using PIO).

Regards,
Andrew Vasquez

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-12-01 23:21 Andrew Vasquez
@ 2003-12-02  2:02 ` Jeremy Higdon
  2003-12-02 10:01   ` Andrew Vasquez
  2003-12-02  3:22 ` Jeremy Higdon
  1 sibling, 1 reply; 44+ messages in thread
From: Jeremy Higdon @ 2003-12-02  2:02 UTC (permalink / raw)
  To: Andrew Vasquez; +Cc: Jes Sorensen, Linux-SCSI, jbarnes, mdr

On Mon, Dec 01, 2003 at 03:21:44PM -0800, Andrew Vasquez wrote:
> On Wednesday, November 26, 2003 5:20 PM, Jeremy Higdon wrote:
> 
> > I've found a problem with the driver on our SN2 system.  There needs
> > to be a register read after updating the Request Queue In index,
> > prior to releasing the host spin lock.
> > 
> > The calls to sn_mmiob() will need to be replaced by reading an
> > appropriate register on the chip.  sn_mmiob() is a lightweight way
> > of doing the same thing without having to go to the chip, but only
> > on SGI SN platforms. 
> > 

Jesse pointed out that my patch was screwed up, by the way, having
been done in reverse -- I don't know why I didn't see that.
Is it okay to read back from the request queue in register?
I'm planning to generate a new patch that includes the previous
changes, and I may as well generate something without the sn_mmiob.

> I'm curious, what types of symptoms were exibited without the
> sn_mmiob() call?  Did I/O stall?

No.  What happens is that writes from two different CPUs make
it to the chip out of order.  So if CPU A writes a 4 to request
queue in, and then releases the spinlock and CPU B acquires the
spinlock and writes a 5, the two writes can make it to the
chip out of order, causing the chip to think that a bunch of
new commands have been issued.  The driver detects lots of
invalid I/O completions after that (stale handles and such).

> BTW: The CACHE_FLUSH() call:
> 
> 	/* Set chip new ring index. */
> 	reg_flushed = CACHE_FLUSH(ISP_REQ_Q_IN(reg));
> 
> preceeding the WRT_REG_WORD() has been removed from my working tree
> (remnants of an ancient motherboard problem with an on-board ISP while
> using PIO).

What about setting the consistent DMA mask to -1UL?


thanks

jeremy

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-12-01 23:21 Andrew Vasquez
  2003-12-02  2:02 ` Jeremy Higdon
@ 2003-12-02  3:22 ` Jeremy Higdon
  2003-12-02 10:15   ` Andrew Vasquez
  1 sibling, 1 reply; 44+ messages in thread
From: Jeremy Higdon @ 2003-12-02  3:22 UTC (permalink / raw)
  To: Andrew Vasquez; +Cc: Jes Sorensen, Linux-SCSI, jbarnes, mdr

Andrew,

The enable_64bit_addressing flag is set in qla2x00_nvram_config().
It is then later overridden in qla2x00_config_dma_addressing().

Since we would like to call qla2x00_config_dma_addressing() before
consistent allocations in order to set the consistent mask, that
would mean that the flag set in qla2x00_config_dma_addressing() would
now be overridden in qla2x00_nvram_config().

What was your intention here?  It seems to me that you should not
be touching this flag in qla2x00_nvram_config().  Is that correct?

Is there any other problem caused by moving the call to
qla2x00_config_dma_addressing() to an early position?

thanks

jeremy

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-12-02 10:01   ` Andrew Vasquez
@ 2003-12-02  9:36     ` Jeremy Higdon
  0 siblings, 0 replies; 44+ messages in thread
From: Jeremy Higdon @ 2003-12-02  9:36 UTC (permalink / raw)
  To: Andrew Vasquez, Andrew Vasquez, Jes Sorensen, Linux-SCSI, jbarnes,
	mdr

On Tue, Dec 02, 2003 at 02:01:25AM -0800, Andrew Vasquez wrote:
> 
> > Is it okay to read back from the request queue in register?
> > I'm planning to generate a new patch that includes the previous
> > changes, and I may as well generate something without the sn_mmiob.
> > 
> 
> I believe we'll need a readl() to flush the write.  Just curious, on
> SGI ia64 machines, how many bridges must a PCI write transaction cross
> before it reaches the target device?

It depends on what you call a bridge.  If you count chips traversed,
it could be as many as 6, I think.  However, the system in which I
had the problem is much smaller than that.

Here is my patch to the v8.00.00b6 driver.  It includes most of
Jes's earlier patch, but not Christoph's patch, which I have not
yet tried.  If you're going to supply a way to change NVRAM without
using BIOS (please!), then this patch can be a bit smaller.  Please
let me know what you think.

I added a read-after-write of the Request In register and commented
out setting of the enable_64bit_addressing flag in the nvram config
function.

I returned SN2 to using nvram variables, except for data rate and
frame size, since at least some QLA2310/2342 boards have the wrong
values.  As you pointed out, we need the nvram node and port name
for proper fabric operation.

jeremy

--- /usr/people/jeremy/26bk/qla2xxx/qla_def.h	Tue Nov  4 15:48:29 2003
+++ drivers/scsi/qla2xxx/qla_def.h	Mon Dec  1 19:58:25 2003
@@ -727,6 +727,47 @@
 #define PD_STATE_WAIT_PORT_LOGOUT_ACK		11
 
 
+struct qla2x00_special_options
+{
+#if defined(__BIG_ENDIAN)
+	uint8_t	data_rate			:2;
+	uint8_t	enable_50_ohm_termination	:1;
+	uint8_t	unused_12			:1;
+
+	uint8_t	unused_11			:1;
+	uint8_t	unused_10			:1;
+	uint8_t	unused_9			:1;
+	uint8_t	unused_8			:1;
+
+	uint8_t	disable_auto_plogi_local_loop	:1;
+	uint8_t	enable_ooo_frame_handling	:1;
+	uint8_t	fcp_rsp_payload			:2;
+
+	uint8_t	unused_3			:1;
+	uint8_t	unused_2			:1;
+	uint8_t	soft_id_only			:1;
+	uint8_t	enable_read_xfr_rdy		:1;
+#else
+	uint8_t	enable_read_xfr_rdy		:1;
+	uint8_t	soft_id_only			:1;
+	uint8_t	unused_2			:1;
+	uint8_t	unused_3			:1;
+
+	uint8_t	fcp_rsp_payload			:2;
+	uint8_t	enable_ooo_frame_handling	:1;
+	uint8_t	disable_auto_plogi_local_loop	:1;
+
+	uint8_t	unused_8			:1;
+	uint8_t	unused_9			:1;
+	uint8_t	unused_10			:1;
+	uint8_t	unused_11			:1;
+
+	uint8_t	unused_12			:1;
+	uint8_t	enable_50_ohm_termination	:1;
+	uint8_t	data_rate			:2;
+#endif
+};
+
 /*
  * ISP Initialization Control Block.
  */
@@ -954,7 +995,7 @@
 	 * MSB BIT 6 = Data Rate (2300 only)
 	 * MSB BIT 7 = Data Rate (2300 only)
 	 */
-	uint8_t	 special_options[2];
+	struct qla2x00_special_options special_options;
 
 	/* Reserved for expanded RISC parameter block */
 	uint8_t reserved_2[24];
diff -u /usr/people/jeremy/26bk/qla2xxx/qla_init.c drivers/scsi/qla2xxx/qla_init.c
--- /usr/people/jeremy/26bk/qla2xxx/qla_init.c	Tue Nov  4 15:48:29 2003
+++ drivers/scsi/qla2xxx/qla_init.c	Tue Dec  2 00:44:28 2003
@@ -162,7 +162,7 @@
 		isp_init = 0;
 
 		/* If firmware needs to be loaded */
-		if (qla2x00_isp_firmware(ha) != QLA_SUCCESS) {
+		if ((rval = qla2x00_isp_firmware(ha)) != QLA_SUCCESS) {
 			if ((rval = qla2x00_chip_diag(ha)) == QLA_SUCCESS) {
 				rval = qla2x00_setup_chip(ha);
 			}
@@ -470,6 +470,12 @@
 	    ha->pdev->device == QLA2322_DEVICE_ID) {
 		udelay(10);
 	} else {
+		/*
+		 * It is necessary to for a delay here since the card 
+		 * doesn't respond to PCI reads during a reset. On some
+		 * architectures this will result in an MCA.
+		 */
+		udelay(20);
 		for (cnt = 30000; cnt; cnt--) {
 			if ((RD_REG_WORD(&reg->ctrl_status) &
 			    CSR_ISP_SOFT_RESET) == 0)
@@ -485,6 +491,10 @@
 
 	/* Release RISC processor. */
 	WRT_REG_WORD(&reg->hccr, HCCR_RELEASE_RISC);
+	/*
+	 * Flush the write so the udelay count below will be reliable
+	 */
+	RD_REG_WORD(&reg->hccr);
 
 	if (ha->pdev->device == QLA2312_DEVICE_ID ||
 	    ha->pdev->device == QLA2322_DEVICE_ID) {
@@ -546,6 +556,11 @@
 
 	/* Reset ISP chip. */
 	WRT_REG_WORD(&reg->ctrl_status, CSR_ISP_SOFT_RESET);
+	/*
+	 * We need to have a delay here since the card will not respond
+	 * while in reset causing an MCA on some architectures.
+	 */
+	udelay(20);
 	data = qla2x00_debounce_register(&reg->ctrl_status);
 	for (cnt = 6000000 ; cnt && (data & CSR_ISP_SOFT_RESET); cnt--) {
 		udelay(5);
@@ -821,6 +836,7 @@
 	WRT_REG_WORD(ISP_REQ_Q_OUT(reg), 0);
 	WRT_REG_WORD(ISP_RSP_Q_IN(reg), 0);
 	WRT_REG_WORD(ISP_RSP_Q_OUT(reg), 0);
+	RD_REG_WORD(ISP_RSP_Q_OUT(reg));
 
 	spin_unlock_irqrestore(&ha->hardware_lock, flags);
 
@@ -1184,6 +1200,7 @@
 		nv->add_firmware_options[0] = BIT_5;
 		nv->add_firmware_options[1] = BIT_5 | BIT_4;
 		nv->frame_payload_size  = __constant_cpu_to_le16(2048);
+		nv->special_options.data_rate = SO_DATA_RATE_AUTO;
 #elif defined(ISP2200)
 		nv->firmware_options[0] = BIT_2 | BIT_1;
 		nv->firmware_options[1] = BIT_7 | BIT_5;
@@ -1219,6 +1236,21 @@
 		rval = 1;
 	}
 
+#if defined(CONFIG_IA64_GENERIC) || defined(CONFIG_IA64_SGI_SN2)
+	/*
+	 * The SN2 does not provide BIOS emulation which means you can't
+	 * change potentially bogus BIOS settings. Force the use of default
+	 * settings for link rate and frame size.  Hope that the rest of
+	 * the settings are valid.
+	 */
+	if (ia64_platform_is("sn2")) {
+		nv->frame_payload_size  = __constant_cpu_to_le16(2048);
+#if defined(ISP2300)
+		nv->special_options.data_rate = SO_DATA_RATE_AUTO;
+#endif
+	}
+#endif
+
 	/* Reset Initialization control block */
 	memset(icb, 0, sizeof(init_cb_t));
 
@@ -1310,7 +1342,11 @@
 	ha->flags.disable_luns = ((nv->host_p[0] & BIT_2) ? 1 : 0);
 	ha->flags.disable_risc_code_load = ((nv->host_p[0] & BIT_4) ? 1 : 0);
 	ha->flags.set_cache_line_size_1 = ((nv->host_p[0] & BIT_5) ? 1 : 0);
-	ha->flags.enable_64bit_addressing = ((nv->host_p[1] & BIT_0) ? 1 : 0);
+	/*
+	 * enable_64bit_addressing gets set in qla2x00_config_dma_addressing;
+	 * do not set it here.
+	 * ha->flags.enable_64bit_addressing = ((nv->host_p[1] & BIT_0) ? 1 : 0);
+	 */
 	ha->flags.enable_lip_reset = ((nv->host_p[1] & BIT_1) ? 1 : 0);
 	ha->flags.enable_lip_full_login = ((nv->host_p[1] & BIT_2) ? 1 : 0);
 	ha->flags.enable_target_reset = ((nv->host_p[1] & BIT_3) ? 1 : 0);
@@ -1319,8 +1355,6 @@
 	ha->operating_mode =
 	    (icb->add_firmware_options[0] & (BIT_6 | BIT_5 | BIT_4)) >> 4;
 
-	qla2x00_config_dma_addressing(ha);
-
 	ha->fw_seriallink_options[0] = nv->seriallink_options[0];
 	ha->fw_seriallink_options[1] = nv->seriallink_options[1];
 
diff -u /usr/people/jeremy/26bk/qla2xxx/qla_inline.h drivers/scsi/qla2xxx/qla_inline.h
--- /usr/people/jeremy/26bk/qla2xxx/qla_inline.h	Tue Nov  4 15:48:29 2003
+++ drivers/scsi/qla2xxx/qla_inline.h	Mon Dec  1 19:58:25 2003
@@ -73,6 +73,12 @@
 			ha->calc_request_entries = qla2x00_calc_iocbs_64;
 			ha->build_scsi_iocbs = qla2x00_build_scsi_iocbs_64;
 			ha->host->sg_tablesize = SG_SEGMENTS_64;
+			if (pci_set_consistent_dma_mask(ha->pdev, 0xffffffffffffffffULL)) {
+				printk(KERN_DEBUG "scsi(%ld): Failed to set 64 bit PCI"
+						" consistent mask; using 32 bit.\n",
+						ha->host_no);
+				pci_set_consistent_dma_mask(ha->pdev, 0xffffffffULL);
+			}
 		} else {
 			printk(KERN_DEBUG
 			    "scsi(%ld): Failed to set 64 bit PCI DMA mask, "
diff -u /usr/people/jeremy/26bk/qla2xxx/qla_iocb.c drivers/scsi/qla2xxx/qla_iocb.c
--- /usr/people/jeremy/26bk/qla2xxx/qla_iocb.c	Tue Nov  4 15:48:29 2003
+++ drivers/scsi/qla2xxx/qla_iocb.c	Tue Dec  2 00:49:29 2003
@@ -506,6 +506,7 @@
 	/* Set chip new ring index. */
 	reg_flushed = CACHE_FLUSH(ISP_REQ_Q_IN(reg));
 	WRT_REG_WORD(ISP_REQ_Q_IN(reg), ha->req_ring_index);
+	RD_REG_WORD(ISP_REQ_Q_IN(reg));
 
 	spin_unlock_irqrestore(&ha->hardware_lock, flags);
 	return (QLA_SUCCESS);
@@ -777,6 +778,7 @@
 
 	/* Set chip new ring index. */
 	WRT_REG_WORD(ISP_REQ_Q_IN(reg), ha->req_ring_index);
+	RD_REG_WORD(ISP_REQ_Q_IN(reg));
 
 	LEAVE(__func__);
 }
diff -u /usr/people/jeremy/26bk/qla2xxx/qla_os.c drivers/scsi/qla2xxx/qla_os.c
--- /usr/people/jeremy/26bk/qla2xxx/qla_os.c	Tue Nov  4 15:48:29 2003
+++ drivers/scsi/qla2xxx/qla_os.c	Mon Dec  1 19:58:25 2003
@@ -20,6 +20,7 @@
 #include "qla_os.h"
 
 #include "qla_def.h"
+#include <linux/vmalloc.h>
 
 /*
  * Driver version
@@ -2492,6 +2493,7 @@
 	    "scsi(%ld): Scatter/Gather Entries (0x%x).\n",
 	    ha->host_no, ha->host->sg_tablesize));
 
+	qla2x00_config_dma_addressing(ha);
 	if (qla2x00_mem_alloc(ha)) {
 		qla_printk(KERN_WARNING, ha,
 		    "[ERROR] Failed to allocate memory for adapter\n");

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-12-02 10:15   ` Andrew Vasquez
@ 2003-12-02  9:50     ` Jeremy Higdon
  0 siblings, 0 replies; 44+ messages in thread
From: Jeremy Higdon @ 2003-12-02  9:50 UTC (permalink / raw)
  To: Andrew Vasquez, Andrew Vasquez, Jes Sorensen, Linux-SCSI, jbarnes,
	mdr

On Tue, Dec 02, 2003 at 02:15:06AM -0800, Andrew Vasquez wrote:
> 
> Yes, in the Linux world, the NVRAM value is irrelevent -- the driver
> will determine the ideal value based on the sizeof(dma_addr_t).  I've
> already removed the NVRAM reads of the host_p[] from
> qla2x00_nvram_config().

Okay, that sounds good.  Do I take this to mean that this whole block:

        ha->flags.disable_luns = ((nv->host_p[0] & BIT_2) ? 1 : 0);
        ha->flags.disable_risc_code_load = ((nv->host_p[0] & BIT_4) ? 1 : 0);
        ha->flags.set_cache_line_size_1 = ((nv->host_p[0] & BIT_5) ? 1 : 0);
        /*
         * enable_64bit_addressing gets set in qla2x00_config_dma_addressing;
         * do not set it here.
         * ha->flags.enable_64bit_addressing = ((nv->host_p[1] & BIT_0) ? 1 : 0);
         */
        ha->flags.enable_lip_reset = ((nv->host_p[1] & BIT_1) ? 1 : 0);
        ha->flags.enable_lip_full_login = ((nv->host_p[1] & BIT_2) ? 1 : 0);
        ha->flags.enable_target_reset = ((nv->host_p[1] & BIT_3) ? 1 : 0);
        ha->flags.enable_flash_db_update = ((nv->host_p[1] & BIT_4) ? 1 : 0);

will be gone in the next update?

When do you plan to make the next update available?

thanks,

jeremy

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-12-02  2:02 ` Jeremy Higdon
@ 2003-12-02 10:01   ` Andrew Vasquez
  2003-12-02  9:36     ` Jeremy Higdon
  0 siblings, 1 reply; 44+ messages in thread
From: Andrew Vasquez @ 2003-12-02 10:01 UTC (permalink / raw)
  To: Jeremy Higdon; +Cc: Andrew Vasquez, Jes Sorensen, Linux-SCSI, jbarnes, mdr

On Mon, 01 Dec 2003, Jeremy Higdon wrote:

> > On Wednesday, November 26, 2003 5:20 PM, Jeremy Higdon wrote:
> > 
> > > I've found a problem with the driver on our SN2 system.  There needs
> > > to be a register read after updating the Request Queue In index,
> > > prior to releasing the host spin lock.
> > > 
> > > The calls to sn_mmiob() will need to be replaced by reading an
> > > appropriate register on the chip.  sn_mmiob() is a lightweight way
> > > of doing the same thing without having to go to the chip, but only
> > > on SGI SN platforms. 
> > > 
> 
> Jesse pointed out that my patch was screwed up, by the way, having
> been done in reverse -- I don't know why I didn't see that.

Yes, your original explanation was sufficient.

> Is it okay to read back from the request queue in register?
> I'm planning to generate a new patch that includes the previous
> changes, and I may as well generate something without the sn_mmiob.
> 

I believe we'll need a readl() to flush the write.  Just curious, on
SGI ia64 machines, how many bridges must a PCI write transaction cross
before it reaches the target device?

> > I'm curious, what types of symptoms were exibited without the
> > sn_mmiob() call?  Did I/O stall?
> 
> No.  What happens is that writes from two different CPUs make
> it to the chip out of order.  So if CPU A writes a 4 to request
> queue in, and then releases the spinlock and CPU B acquires the
> spinlock and writes a 5, the two writes can make it to the
> chip out of order, causing the chip to think that a bunch of
> new commands have been issued.  The driver detects lots of
> invalid I/O completions after that (stale handles and such).
> 

Yep, definitely a posting problem.

> > BTW: The CACHE_FLUSH() call:
> > 
> > 	/* Set chip new ring index. */
> > 	reg_flushed = CACHE_FLUSH(ISP_REQ_Q_IN(reg));
> > 
> > preceeding the WRT_REG_WORD() has been removed from my working tree
> > (remnants of an ancient motherboard problem with an on-board ISP while
> > using PIO).
> 
> What about setting the consistent DMA mask to -1UL?
> 

Yes, and I hope a simple sysfs interface to the NVRAM (for the
GUI challenged).

Regards,
Andrew Vasquez

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
  2003-12-02  3:22 ` Jeremy Higdon
@ 2003-12-02 10:15   ` Andrew Vasquez
  2003-12-02  9:50     ` Jeremy Higdon
  0 siblings, 1 reply; 44+ messages in thread
From: Andrew Vasquez @ 2003-12-02 10:15 UTC (permalink / raw)
  To: Jeremy Higdon; +Cc: Andrew Vasquez, Jes Sorensen, Linux-SCSI, jbarnes, mdr

On Mon, 01 Dec 2003, Jeremy Higdon wrote:

> The enable_64bit_addressing flag is set in qla2x00_nvram_config().
> It is then later overridden in qla2x00_config_dma_addressing().
> 
> Since we would like to call qla2x00_config_dma_addressing() before
> consistent allocations in order to set the consistent mask, that
> would mean that the flag set in qla2x00_config_dma_addressing() would
> now be overridden in qla2x00_nvram_config().
> 
> What was your intention here?  It seems to me that you should not
> be touching this flag in qla2x00_nvram_config().  Is that correct?
> 

Yes, in the Linux world, the NVRAM value is irrelevent -- the driver
will determine the ideal value based on the sizeof(dma_addr_t).  I've
already removed the NVRAM reads of the host_p[] from
qla2x00_nvram_config().

> Is there any other problem caused by moving the call to
> qla2x00_config_dma_addressing() to an early position?
> 

I don't see any additional issues with the move.

Thanks again for your feedback.

Regards,
Andrew Vasquez

^ permalink raw reply	[flat|nested] 44+ messages in thread

* RE: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
@ 2003-12-02 18:10 Andrew Vasquez
  0 siblings, 0 replies; 44+ messages in thread
From: Andrew Vasquez @ 2003-12-02 18:10 UTC (permalink / raw)
  To: Jeremy Higdon, Jes Sorensen, Linux-SCSI, jbarnes, mdr

On Tuesday, December 02, 2003 1:37 AM, Jeremy Higdon wrote:

> On Tue, Dec 02, 2003 at 02:01:25AM -0800, Andrew Vasquez wrote:
> > 
> > > Is it okay to read back from the request queue in register?
> > > I'm planning to generate a new patch that includes the previous
> > > changes, and I may as well generate something without the
> > > sn_mmiob. 
> > > 
> > 
> > I believe we'll need a readl() to flush the write.  Just curious, on
> > SGI ia64 machines, how many bridges must a PCI write transaction
> > cross before it reaches the target device?
> 
> It depends on what you call a bridge.  If you count chips traversed,
> it could be as many as 6, I think.  However, the system in which I
> had the problem is much smaller than that.
> 
> Here is my patch to the v8.00.00b6 driver.  It includes most of
> Jes's earlier patch, but not Christoph's patch, which I have not
> yet tried.  
>

Thanks, I've already had a running tree which included Jes's patch --
I'll add the deltas.

> If you're going to supply a way to change NVRAM without
> using BIOS (please!), then this patch can be a bit smaller.  Please
> let me know what you think. 
> 

The model with which I'm basing the NVRAM update on is the code for
PCI config space updates in drivers/pci/pci-sysfs.c (pci_config_attr).

> I added a read-after-write of the Request In register and commented
> out setting of the enable_64bit_addressing flag in the nvram config
> function. 
> 
> I returned SN2 to using nvram variables, except for data rate and
> frame size, since at least some QLA2310/2342 boards have the wrong
> values.  As you pointed out, we need the nvram node and port name
> for proper fabric operation.
> 

That's the safest path.

Regards,
Andrew Vasquez

^ permalink raw reply	[flat|nested] 44+ messages in thread

* RE: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6).
@ 2003-12-02 18:22 Andrew Vasquez
  0 siblings, 0 replies; 44+ messages in thread
From: Andrew Vasquez @ 2003-12-02 18:22 UTC (permalink / raw)
  To: Jeremy Higdon, Jes Sorensen, Linux-SCSI, jbarnes, mdr

On Tuesday, December 02, 2003 1:51 AM, Jeremy Higdon wrote:

> On Tue, Dec 02, 2003 at 02:15:06AM -0800, Andrew Vasquez wrote:
> > 
> > Yes, in the Linux world, the NVRAM value is irrelevent -- the
> > driver will determine the ideal value based on the
> > sizeof(dma_addr_t).  I've already removed the NVRAM reads of the
> > host_p[] from qla2x00_nvram_config().
> 
> Okay, that sounds good.  Do I take this to mean that this whole
> block: ...  will be gone in the next update?
> 

Actually, the only host_p values that are relevent and used in the linux
qla driver are the following:

	ha->flags.disable_risc_code_load = ((nv->host_p[0] & BIT_4) ? 1 : 0);
	ha->flags.enable_lip_reset = ((nv->host_p[1] & BIT_1) ? 1 : 0);
	ha->flags.enable_lip_full_login = ((nv->host_p[1] & BIT_2) ? 1 : 0);
	ha->flags.enable_target_reset = ((nv->host_p[1] & BIT_3) ? 1 : 0);

I've removed references to the other members.

> When do you plan to make the next update available?
>

Thursday.

Regards,
Andrew Vasquez

^ permalink raw reply	[flat|nested] 44+ messages in thread

end of thread, other threads:[~2003-12-02 18:21 UTC | newest]

Thread overview: 44+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-11-05  1:15 [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6) Andrew Vasquez
2003-11-05  9:17 ` Mike Anderson
2003-11-06  9:36 ` Christoph Hellwig
2003-11-06 10:51 ` Christoph Hellwig
2003-11-10 14:00 ` Jes Sorensen
     [not found] ` <20031114115847.GA32664@lst.de>
2003-11-17 12:18   ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2003-11-05 18:39 Andrew Vasquez
2003-11-06  9:17 ` Jens Axboe
2003-11-06 17:02 Andrew Vasquez
2003-11-06 17:53 ` Matthew Wilcox
2003-11-07  9:58   ` Christoph Hellwig
2003-11-07  9:33 ` Christoph Hellwig
2003-11-06 17:11 Andrew Vasquez
2003-11-06 17:14 ` Jens Axboe
2003-11-06 17:43   ` Arjan van de Ven
2003-11-06 17:50     ` Jens Axboe
2003-11-06 17:55       ` Arjan van de Ven
2003-11-06 17:58         ` Jens Axboe
2003-11-06 17:45 Andrew Vasquez
2003-11-06 17:59 ` Arjan van de Ven
2003-11-07  9:37 ` Christoph Hellwig
2003-11-06 19:33 Andrew Vasquez
2003-11-07  9:39 ` Christoph Hellwig
2003-11-19 23:03 Andrew Vasquez
2003-11-19 23:18 ` Matthew Wilcox
2003-11-20  9:19 ` Jes Sorensen
2003-11-21  8:43   ` Jeremy Higdon
2003-11-19 23:38 Andrew Vasquez
2003-11-24 17:37 Andrew Vasquez
2003-11-25  1:22 ` Jeremy Higdon
2003-11-25  8:18   ` Christoph Hellwig
2003-11-25  8:21 ` Jes Sorensen
2003-11-25 19:29 Andrew Vasquez
2003-11-25 23:31 ` Jeremy Higdon
2003-11-27  1:20   ` Jeremy Higdon
2003-12-01 23:21 Andrew Vasquez
2003-12-02  2:02 ` Jeremy Higdon
2003-12-02 10:01   ` Andrew Vasquez
2003-12-02  9:36     ` Jeremy Higdon
2003-12-02  3:22 ` Jeremy Higdon
2003-12-02 10:15   ` Andrew Vasquez
2003-12-02  9:50     ` Jeremy Higdon
2003-12-02 18:10 Andrew Vasquez
2003-12-02 18:22 Andrew Vasquez

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