linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 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-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
* 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-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-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-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
  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-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: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: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: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-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
* [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

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-12-01 23:21 [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6) 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
  -- strict thread matches above, loose matches on Subject: below --
2003-12-02 18:22 Andrew Vasquez
2003-12-02 18:10 Andrew Vasquez
2003-11-25 19:29 Andrew Vasquez
2003-11-25 23:31 ` Jeremy Higdon
2003-11-27  1:20   ` Jeremy Higdon
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-19 23:38 Andrew Vasquez
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-06 19:33 Andrew Vasquez
2003-11-07  9:39 ` Christoph Hellwig
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 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: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-05 18:39 Andrew Vasquez
2003-11-06  9:17 ` Jens Axboe
2003-11-05  1:15 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

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