qla1280 endiannes and 64/32bit fixes

qla1280 endiannes and 64/32bit fixes

[James Bottomley]

Well, I finally got this to work for me on the parisc.

There were three specific problems

1. The Fimware reading routine is still wrong.  If you reverse all the
words, then the byte quantities will be correct but the word quantities
still need reversing again.

2. The new qla1280_return_status() routine wasn't endian neutral

3. You can't simply override the nvram 64/32 bit mode without actually
telling the card you're doing it.

To fix 3, I just removed the override, but since I was actually running
on a 64 bit platform (parisc64) there should be a command to tell the
card this...I'll see if I can find it.

With the attached patch, the card works nicely on parisc.

James

===== drivers/scsi/qla1280.c 1.53 vs edited =====
--- 1.53/drivers/scsi/qla1280.c	Thu Jan  8 15:42:46 2004
+++ edited/drivers/scsi/qla1280.c	Sat Jan 17 17:26:33 2004
@@ -765,7 +765,7 @@
 {
 	uint16_t *wptr;
 	uint8_t chksum;
-	int cnt;
+	int cnt, i;
 	struct nvram *nv;
 
 	ENTER("qla1280_read_nvram");
@@ -812,6 +812,28 @@
 	} else
 		ha->nvram_valid = 1;
 
+	/* The firmware interface is, um, interesting, in that the
+	 * actual firmware image on the chip is little endian, thus,
+	 * the process of taking that image to the CPU would end up
+	 * little endian.  However, the firmare interface requires it
+	 * to be read a word (two bytes) at a time.
+	 *
+	 * The net result of this would be that the word (and
+	 * doubleword) quantites in the firmware would be correct, but
+	 * the bytes would be pairwise reversed.  Since most of the
+	 * firmware quantites are, in fact, bytes, we do an extra
+	 * le16_to_cpu() in the firmware read routine.
+	 *
+	 * The upshot of all this is that the bytes in the firmware
+	 * are in the correct places, but the 16 and 32 bit quantites
+	 * are still in little endian format.  We fix that up below by
+	 * doing extra reverses on them */
+	nv->isp_parameter = cpu_to_le16(nv->isp_parameter);
+	nv->firmware_feature.w = cpu_to_le16(nv->firmware_feature.w);
+	for(i = 0; i < MAX_BUSES; i++) {
+		nv->bus[i].selection_timeout = cpu_to_le16(nv->bus[i].selection_timeout);
+		nv->bus[i].max_queue_depth = cpu_to_le16(nv->bus[i].max_queue_depth);
+	}
 	dprintk(1, "qla1280_read_nvram: Completed Reading NVRAM\n");
 	LEAVE("qla1280_read_nvram");
 
@@ -1558,6 +1580,10 @@
 qla1280_return_status(struct response * sts, struct scsi_cmnd *cp)
 {
 	int host_status = DID_ERROR;
+	uint16_t comp_status = le16_to_cpu(sts->comp_status);
+	uint16_t state_flags = le16_to_cpu(sts->state_flags);
+	uint16_t residual_length = le16_to_cpu(sts->residual_length);
+	uint16_t scsi_status = le16_to_cpu(sts->scsi_status);
 #if DEBUG_QLA1280_INTR
 	static char *reason[] = {
 		"DID_OK",
@@ -1578,26 +1604,27 @@
 #if DEBUG_QLA1280_INTR
 	/*
 	  dprintk(1, "qla1280_return_status: compl status = 0x%04x\n",
-	  sts->comp_status);
+	  comp_status);
 	*/
 #endif
-	switch (sts->comp_status) {
+
+	switch (comp_status) {
 	case CS_COMPLETE:
 		host_status = DID_OK;
 		break;
 
 	case CS_INCOMPLETE:
-		if (!(sts->state_flags & SF_GOT_BUS))
+		if (!(state_flags & SF_GOT_BUS))
 			host_status = DID_NO_CONNECT;
-		else if (!(sts->state_flags & SF_GOT_TARGET))
+		else if (!(state_flags & SF_GOT_TARGET))
 			host_status = DID_BAD_TARGET;
-		else if (!(sts->state_flags & SF_SENT_CDB))
+		else if (!(state_flags & SF_SENT_CDB))
 			host_status = DID_ERROR;
-		else if (!(sts->state_flags & SF_TRANSFERRED_DATA))
+		else if (!(state_flags & SF_TRANSFERRED_DATA))
 			host_status = DID_ERROR;
-		else if (!(sts->state_flags & SF_GOT_STATUS))
+		else if (!(state_flags & SF_GOT_STATUS))
 			host_status = DID_ERROR;
-		else if (!(sts->state_flags & SF_GOT_SENSE))
+		else if (!(state_flags & SF_GOT_SENSE))
 			host_status = DID_ERROR;
 		break;
 
@@ -1614,14 +1641,14 @@
 		break;
 
 	case CS_DATA_OVERRUN:
-		dprintk(2, "Data overrun 0x%x\n", sts->residual_length);
+		dprintk(2, "Data overrun 0x%x\n", residual_length);
 		dprintk(2, "qla1280_isr: response packet data\n");
 		qla1280_dump_buffer(2, (char *)sts, RESPONSE_ENTRY_SIZE);
 		host_status = DID_ERROR;
 		break;
 
 	case CS_DATA_UNDERRUN:
-		if ((cp->request_bufflen - sts->residual_length) <
+		if ((cp->request_bufflen - residual_length) <
 		    cp->underflow) {
 			printk(KERN_WARNING
 			       "scsi: Underflow detected - retrying "
@@ -1638,12 +1665,12 @@
 
 #if DEBUG_QLA1280_INTR
 	dprintk(1, "qla1280 ISP status: host status (%s) scsi status %x\n",
-		reason[host_status], sts->scsi_status);
+		reason[host_status], scsi_status);
 #endif
 
 	LEAVE("qla1280_return_status");
 
-	return (sts->scsi_status & 0xff) | (host_status << 16);
+	return (scsi_status & 0xff) | (host_status << 16);
 }
 
 /****************************************************************************/
@@ -2393,16 +2420,6 @@
 	/* Disable RISC load of firmware. */
 	ha->flags.disable_risc_code_load =
 		nv->cntr_flags_1.disable_loading_risc_code;
-
-#ifdef QLA_64BIT_PTR
-	/* Enable 64bit addressing for OS/System combination supporting it   */
-	/* actual NVRAM bit is: nv->cntr_flags_1.enable_64bit_addressing     */
-	/* but we will ignore it and use BITS_PER_LONG macro to setup for    */
-	/* 64 or 32 bit access of host memory in all x86/ia-64/Alpha systems */
-	ha->flags.enable_64bit_addressing = 1;
-#else
-	ha->flags.enable_64bit_addressing = 0;
-#endif
 
 	if (ha->flags.enable_64bit_addressing) {
 		dprintk(2, "scsi(%li): 64 Bit PCI Addressing Enabled\n",
===== drivers/scsi/qla1280.h 1.23 vs edited =====
--- 1.23/drivers/scsi/qla1280.h	Sun Jan  4 23:07:47 2004
+++ edited/drivers/scsi/qla1280.h	Sat Jan 17 13:04:48 2004
@@ -309,16 +309,19 @@
 	} cntr_flags_1;		/* 5 */
 
 	struct {
-		uint16_t boot_lun_number:5;
-		uint16_t scsi_bus_number:1;
-		uint16_t unused_6:1;
-		uint16_t unused_7:1;
-		uint16_t boot_target_number:4;
-		uint16_t unused_12:1;
-		uint16_t unused_13:1;
-		uint16_t unused_14:1;
-		uint16_t unused_15:1;
-	} cntr_flags_2;		/* 6, 7 */
+		uint8_t boot_lun_number:5;
+		uint8_t scsi_bus_number:1;
+		uint8_t unused_6:1;
+		uint8_t unused_7:1;
+	} cntr_flags_2l;	/* 7 */
+
+	struct {
+		uint8_t boot_target_number:4;
+		uint8_t unused_12:1;
+		uint8_t unused_13:1;
+		uint8_t unused_14:1;
+		uint8_t unused_15:1;
+	} cntr_flags_2h;	/* 8 */
 
 	uint16_t unused_8;	/* 8, 9 */
 	uint16_t unused_10;	/* 10, 11 */

Re: qla1280 endiannes and 64/32bit fixes

[Jeremy Higdon]

On Sat, Jan 17, 2004 at 06:40:58PM -0500, James Bottomley wrote:
> 
> @@ -2393,16 +2420,6 @@
>  	/* Disable RISC load of firmware. */
>  	ha->flags.disable_risc_code_load =
>  		nv->cntr_flags_1.disable_loading_risc_code;
> -
> -#ifdef QLA_64BIT_PTR
> -	/* Enable 64bit addressing for OS/System combination supporting it   */
> -	/* actual NVRAM bit is: nv->cntr_flags_1.enable_64bit_addressing     */
> -	/* but we will ignore it and use BITS_PER_LONG macro to setup for    */
> -	/* 64 or 32 bit access of host memory in all x86/ia-64/Alpha systems */
> -	ha->flags.enable_64bit_addressing = 1;
> -#else
> -	ha->flags.enable_64bit_addressing = 0;
> -#endif
>  
>  	if (ha->flags.enable_64bit_addressing) {
>  		dprintk(2, "scsi(%li): 64 Bit PCI Addressing Enabled\n",


What is the reason for this change?  Is there an alternate way that this
gets set?

jeremy

Re: qla1280 endiannes and 64/32bit fixes

[James Bottomley]

On Sat, 2004-01-17 at 21:43, Jeremy Higdon wrote:
> > @@ -2393,16 +2420,6 @@
> >  	/* Disable RISC load of firmware. */
> >  	ha->flags.disable_risc_code_load =
> >  		nv->cntr_flags_1.disable_loading_risc_code;
> > -
> > -#ifdef QLA_64BIT_PTR
> > -	/* Enable 64bit addressing for OS/System combination supporting it   */
> > -	/* actual NVRAM bit is: nv->cntr_flags_1.enable_64bit_addressing     */
> > -	/* but we will ignore it and use BITS_PER_LONG macro to setup for    */
> > -	/* 64 or 32 bit access of host memory in all x86/ia-64/Alpha systems */
> > -	ha->flags.enable_64bit_addressing = 1;
> > -#else
> > -	ha->flags.enable_64bit_addressing = 0;
> > -#endif
> >  
> >  	if (ha->flags.enable_64bit_addressing) {
> >  		dprintk(2, "scsi(%li): 64 Bit PCI Addressing Enabled\n",
> 
> 
> What is the reason for this change?  Is there an alternate way that this
> gets set?

That's reason number three in the previous email: apparently you can't
simply address the card in 64 bit mode if the nvram is set up for 32 bit
mode.  We either have to take the nvram value or find a way to switch
the card into 64 bit mode.

This was causing transfer failures on a 64 bit parisc box.  The nvram
returns 32 bit, and no transfers were occurring when it was addressed in
64 bit mode.  It may be because there's an endianness failure somewhere
in the 64bit_start_scsi routine, but if there is I couldn't find it. 
The address can't be wrong, because the PA has a pretty fierce IOMMU
that detects DMA to wrong memory.

James





James

Re: qla1280 endiannes and 64/32bit fixes

[Andrew Vasquez]

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

On Sat, 17 Jan 2004, James Bottomley wrote:

> On Sat, 2004-01-17 at 21:43, Jeremy Higdon wrote:
> > What is the reason for this change?  Is there an alternate way that this
> > gets set?
> 
> That's reason number three in the previous email: apparently you can't
> simply address the card in 64 bit mode if the nvram is set up for 32 bit
> mode.  We either have to take the nvram value or find a way to switch
> the card into 64 bit mode.
> 

That NVRAM setting really has no functional meaning for the card or
Linux driver.  I believe it was an artifact from some ancient
(non-linux) driver.  In essence, the ha flag simply indicates the
which type of IOCBs are used to initiate the CDB transfer.

> This was causing transfer failures on a 64 bit parisc box.  The nvram
> returns 32 bit, and no transfers were occurring when it was addressed in
> 64 bit mode.  It may be because there's an endianness failure somewhere
> in the 64bit_start_scsi routine, but if there is I couldn't find it. 
>

Either could I (but then again its late :).  What I did notice was
some rather weird code being executed when the CDB calls for no data
to transfer (both 64/32_start).  The code in question is this small
snippet:

	...
        } else {        /* No data transfer */
                dword_ptr = (uint32_t *)(pkt + 1);
                *dword_ptr++ = 0;
                *dword_ptr++ = 0;
                *dword_ptr = 0;
                dprintk(5, "qla1280_64bit_start_scsi: No data, command "
                        "packet data - b %i, t %i, l %i \n",
                        SCSI_BUS_32(cmd), SCSI_TCN_32(cmd),
			SCSI_LUN_32(cmd));
		qla1280_dump_buffer(5, (char *)pkt, REQUEST_ENTRY_SIZE);
        }

What exactly are we trying to zero out here?  The IOCB has already
been cleared with the following line earlier in the function:

        /* Zero out remaining portion of packet. */
        memset(((char *)pkt + 8), 0, (REQUEST_ENTRY_SIZE - 8));

pkt points to:

        /*
	 * Build command packet.
	 */
        pkt = (cmd_a64_entry_t *) ha->request_ring_ptr;

(uint32_t *)(pkt + 1) points to the next request_ring entry.
Certainly not what we want.

Here's a small patch, not sure if its going to solve your problem
though.  I'll look some more tomorrow.

Jeremy:  have you had any problems with running I/O down the 64bit
capable IOCB path?

--
Andrew

[-- Attachment #2: 1280-no_data_transfer.diff --]
[-- Type: text/plain, Size: 800 bytes --]

--- qla1280.c.orig	2004-01-17 22:18:16.000000000 -0800
+++ qla1280.c	2004-01-17 22:19:18.000000000 -0800
@@ -3325,10 +3325,6 @@
 					    REQUEST_ENTRY_SIZE);
 		}
 	} else {	/* No data transfer */
-		dword_ptr = (uint32_t *)(pkt + 1);
-		*dword_ptr++ = 0;
-		*dword_ptr++ = 0;
-		*dword_ptr = 0;
 		dprintk(5, "qla1280_64bit_start_scsi: No data, command "
 			"packet data - b %i, t %i, l %i \n",
 			SCSI_BUS_32(cmd), SCSI_TCN_32(cmd), SCSI_LUN_32(cmd));
@@ -3593,9 +3589,6 @@
 			*dword_ptr = cpu_to_le32(cmd->request_bufflen);
 		}
 	} else {	/* No data transfer at all */
-		dword_ptr = (uint32_t *)(pkt + 1);
-		*dword_ptr++ = 0;
-		*dword_ptr = 0;
 		dprintk(5, "qla1280_32bit_start_scsi: No data, command "
 			"packet data - \n");
 		qla1280_dump_buffer(5, (char *)pkt, REQUEST_ENTRY_SIZE);

Re: qla1280 endiannes and 64/32bit fixes

[Jeremy Higdon]

On Sat, Jan 17, 2004 at 10:16:57PM -0500, James Bottomley wrote:
> On Sat, 2004-01-17 at 21:43, Jeremy Higdon wrote:
> > > @@ -2393,16 +2420,6 @@
> > >  	/* Disable RISC load of firmware. */
> > >  	ha->flags.disable_risc_code_load =
> > >  		nv->cntr_flags_1.disable_loading_risc_code;
> > > -
> > > -#ifdef QLA_64BIT_PTR
> > > -	/* Enable 64bit addressing for OS/System combination supporting it   */
> > > -	/* actual NVRAM bit is: nv->cntr_flags_1.enable_64bit_addressing     */
> > > -	/* but we will ignore it and use BITS_PER_LONG macro to setup for    */
> > > -	/* 64 or 32 bit access of host memory in all x86/ia-64/Alpha systems */
> > > -	ha->flags.enable_64bit_addressing = 1;
> > > -#else
> > > -	ha->flags.enable_64bit_addressing = 0;
> > > -#endif
> > >  
> > >  	if (ha->flags.enable_64bit_addressing) {
> > >  		dprintk(2, "scsi(%li): 64 Bit PCI Addressing Enabled\n",
> > 
> > 
> > What is the reason for this change?  Is there an alternate way that this
> > gets set?
> 
> That's reason number three in the previous email: apparently you can't
> simply address the card in 64 bit mode if the nvram is set up for 32 bit
> mode.  We either have to take the nvram value or find a way to switch
> the card into 64 bit mode.

I see.  Well, it causes this driver to stop working on our SN2
(Altix) systems.

> This was causing transfer failures on a 64 bit parisc box.  The nvram
> returns 32 bit, and no transfers were occurring when it was addressed in
> 64 bit mode.  It may be because there's an endianness failure somewhere
> in the 64bit_start_scsi routine, but if there is I couldn't find it. 
> The address can't be wrong, because the PA has a pretty fierce IOMMU
> that detects DMA to wrong memory.

It very well could be.  Our ql driver has lots of code to do endian
conversions on our big endian platforms.  That's all excised in our
XSCSI ql driver, since the Altix is little endian.

> James

I'm leaving shortly for a vacation, so hopefully Jes can pursue this
with you for the next few days.

jeremy

Re: qla1280 endiannes and 64/32bit fixes

[Jeremy Higdon]

On Sat, Jan 17, 2004 at 10:21:57PM -0800, Andrew Vasquez wrote:
> 
> Jeremy:  have you had any problems with running I/O down the 64bit
> capable IOCB path?
> 
> --
> Andrew

No problems.  But then our Linux boxes are little endian.  We have
an ISP12160 on every one built so far, with no NVRAM.


James, with your code as it is now, ha->flags.enable_64bit_addressing
is always 0.  You'd need to add code to read the value out of the
nvram.  Then we'll need an nvram override for Altix.

Here's a patch to James's patch.  Yes, it has more nasty #ifdefs.  I
think there is probably a better way, but it's late  :-)

I'll let Jes continue with this, as I'll be away until next Friday.

thanks

jeremy

--- drivers/scsi/qla1280.c.bak	Sat Jan 17 23:22:54 2004
+++ drivers/scsi/qla1280.c	Sat Jan 17 23:22:59 2004
@@ -2935,6 +2935,15 @@
 	ha->flags.disable_risc_code_load =
 		nv->cntr_flags_1.disable_loading_risc_code;
 
+	/* Get NVRAM value from firmware */
+	ha->flags.enable_64bit_addressing =
+		nv->cntr_flags_1.enable_64bit_addressing;
+#if defined(CONFIG_IA64_GENERIC) || defined (CONFIG_IA64_SGI_SN2)
+	/* SN2 needs 64 bit */
+	if (ia64_platform_is("sn2"))
+		ha->flags.enable_64bit_addressing = 1;
+#endif
+
 	if (ha->flags.enable_64bit_addressing) {
 		dprintk(2, "scsi(%li): 64 Bit PCI Addressing Enabled\n",
 			ha->host_no);

Re: qla1280 endiannes and 64/32bit fixes

[James Bottomley]

On Sun, 2004-01-18 at 01:21, Andrew Vasquez wrote:
> That NVRAM setting really has no functional meaning for the card or
> Linux driver.  I believe it was an artifact from some ancient
> (non-linux) driver.  In essence, the ha flag simply indicates the
> which type of IOCBs are used to initiate the CDB transfer.

Well, since there are still no published specs, I had to guess...

> Here's a small patch, not sure if its going to solve your problem
> though.  I'll look some more tomorrow.

I tried the patch, but the behaviour is still the same.

What I see is that the returned data from actual data transfer
instructions is full of NULLs (presumably either because there was no
transfer, or the transfer was to the wrong location---although the fact
that the IOMMU doesn't halt the machine does tend to deny the latter).

I'm also using a qla1280 (not a 12160) if that helps.

James

Re: qla1280 endiannes and 64/32bit fixes

[James Bottomley]

On Sun, 2004-01-18 at 02:33, Jeremy Higdon wrote:
> James, with your code as it is now, ha->flags.enable_64bit_addressing
> is always 0.  You'd need to add code to read the value out of the
> nvram.  Then we'll need an nvram override for Altix.

Actually, I found it.  There was a missed endianness problem in the 64
bit path (see patch).

However, I have another question for you:  Does the card BIOS actually
get to run on bootup?  It doesn't (because it can't) on PA, so I get
strange values for certain NVRAM quantities (like the 32 bit mode, but
more importantly, the offset of all my devices gets set to 1).  I was
thinking about doing an override to set them more sensibly and wondered
if you were having the same problem.

James

===== drivers/scsi/qla1280.c 1.54 vs edited =====
--- 1.54/drivers/scsi/qla1280.c	Sat Jan 17 17:44:11 2004
+++ edited/drivers/scsi/qla1280.c	Sun Jan 18 08:47:42 2004
@@ -3332,7 +3336,7 @@
 #endif
 			*dword_ptr++ = cpu_to_le32(pci_dma_lo32(dma_handle));
 			*dword_ptr++ = cpu_to_le32(pci_dma_hi32(dma_handle));
-			*dword_ptr = (uint32_t)cmd->request_bufflen;
+			*dword_ptr = cpu_to_le32(cmd->request_bufflen);
 
 			dprintk(5, "qla1280_64bit_start_scsi: No scatter/"
 				"gather command packet data - b %i, t %i, "

Re: qla1280 endiannes and 64/32bit fixes

[Jes Sorensen]

On Sun, 2004-01-18 at 09:54, James Bottomley wrote:
> On Sun, 2004-01-18 at 02:33, Jeremy Higdon wrote:
> > James, with your code as it is now, ha->flags.enable_64bit_addressing
> > is always 0.  You'd need to add code to read the value out of the
> > nvram.  Then we'll need an nvram override for Altix.
> 
> Actually, I found it.  There was a missed endianness problem in the 64
> bit path (see patch).
> 
> However, I have another question for you:  Does the card BIOS actually
> get to run on bootup?  It doesn't (because it can't) on PA, so I get
> strange values for certain NVRAM quantities (like the 32 bit mode, but
> more importantly, the offset of all my devices gets set to 1).  I was
> thinking about doing an override to set them more sensibly and wondered
> if you were having the same problem.

Hi James,

Same problem on Altix, the BIOS can't run as there is no x86 emulation
in the EFI firmware on the box.

Cheers,
Jes

Re: qla1280 endiannes and 64/32bit fixes

[Jes Sorensen]

>>>>> "Andrew" == Andrew Vasquez <praka@users.sourceforge.net> writes:

Andrew> Either could I (but then again its late :).  What I did notice
Andrew> was some rather weird code being executed when the CDB calls
Andrew> for no data to transfer (both 64/32_start).  The code in
Andrew> question is this small snippet:

[snip]

Andrew> What exactly are we trying to zero out here?  The IOCB has
Andrew> already been cleared with the following line earlier in the
Andrew> function:

Andrew,

I actually have zero clue why that code was looking like that, it goes
back to the original driver from before I started maintaining
it. Someone in a cube next to you must have written it.

Andrew> Jeremy: have you had any problems with running I/O down the
Andrew> 64bit capable IOCB path?

The 64bit IOCB path has been working great for quite a while, both on
Altix but also as far back as the BigSur boat anchors ;-)

I'll include your change with James' changes into the next release
(modulo the 64 bit addressing bit one as per your explanation).

Cheers,
Jes

Re: qla1280 endiannes and 64/32bit fixes

[Christoph Hellwig]

On Sun, Jan 18, 2004 at 09:54:13AM -0500, James Bottomley wrote:
> However, I have another question for you:  Does the card BIOS actually
> get to run on bootup?  It doesn't (because it can't) on PA, so I get
> strange values for certain NVRAM quantities (like the 32 bit mode, but
> more importantly, the offset of all my devices gets set to 1).  I was
> thinking about doing an override to set them more sensibly and wondered
> if you were having the same problem.

Guys, given that problems with that nvram reading stuff show up again and
again, shouldn't we rip out the code looking at the nvram completely?
Or at least disable it by default and enable it only by a module option
(for both qla1280 and qla2xxx).

Re: qla1280 endiannes and 64/32bit fixes

[Jes Sorensen]

>>>>> "Christoph" == Christoph Hellwig <hch@infradead.org> writes:

Christoph> On Sun, Jan 18, 2004 at 09:54:13AM -0500, James Bottomley
Christoph> wrote:
>> However, I have another question for you: Does the card BIOS
>> actually get to run on bootup?  It doesn't (because it can't) on
>> PA, so I get strange values for certain NVRAM quantities (like the
>> 32 bit mode, but more importantly, the offset of all my devices
>> gets set to 1).  I was thinking about doing an override to set them
>> more sensibly and wondered if you were having the same problem.

Christoph> Guys, given that problems with that nvram reading stuff
Christoph> show up again and again, shouldn't we rip out the code
Christoph> looking at the nvram completely?  Or at least disable it by
Christoph> default and enable it only by a module option (for both
Christoph> qla1280 and qla2xxx).

Christoph, I have thought about this before and while I agree in
principle that relying on BIOS settings is inherently broken, I am
also wary of changing a behavior a number of users are currently
relying upon.

Second, for qla2xxx you need a persistent place where you can store
the Fibre Channel ID (the name slips my mind right now).

Cheers,
Jes