Re: new qla2xxx driver breaks SAN setup with 2 controllers

Re: new qla2xxx driver breaks SAN setup with 2 controllers

[Patrick Mansfield]

On Tue, Aug 23, 2005 at 01:25:35PM +0200, Frederik Schueler wrote:
> hello,
> 
> we are experiencing problems with the new qlogic driver in 2.6.12 on
> a set of servers with qla2310 HBAs.
> 
> The problem is as follows:
> 
> The Infotrend storage array we are using has two controllers, each
> of them has two virtual discs with a couple of partitions exported
> as shared storage.
> 
> The controllers are linked inside of the storage box, each controller
> has one qlogic fabric switch attached, and half of the servers are
> connected to the lefthand switch, the other half is connected to the
> righthand switch.
> 
> Now, with the qlogic driver in 2.6.11.12, we can access all shares
> on both controllers from every server, while the new driver allows
> only access to the respective controller where the switch is attached
> to directly, thus depriving the servers of half of it's shared
> storage devices.
> 
> Example: on server s05, we have a boot device (lun 3 on primary
> controller), and 2 shared storages (lun 9 on primary, lun 10 on
> secondary controller).

The use of scsiadd script implies that you are attaching or somehow
modifying the storage after the driver has loaded. Is that correct?

There is a fix for scanning initiated via user space, this change:

http://www.kernel.org/git/?p=linux/kernel/git/jejb/scsi-rc-fixes-2.6.git;a=commit;h=5c44cd2afad3f7b015542187e147a820600172f1

The above fix is in the current 2.6 git tree. Does that fix your problem?

If so, reloading the driver should also rescan correctly (even in
2.6.12.5).

unplugging/plugging the cable might also fix the problem.

> With 2.6.11.12, this looks as follows:
> 
> s05:~# cat /proc/scsi/scsi
> Attached devices:
> Host: scsi0 Channel: 00 Id: 00 Lun: 03
>   Vendor: IFT      Model: A16F-R1211       Rev: 334B
>   Type:   Direct-Access                    ANSI SCSI revision: 03
> Host: scsi0 Channel: 00 Id: 00 Lun: 09
>   Vendor: IFT      Model: A16F-R1211       Rev: 334B
>   Type:   Direct-Access                    ANSI SCSI revision: 03
> Host: scsi0 Channel: 00 Id: 01 Lun: 10
>   Vendor: IFT      Model: A16F-R1211       Rev: 334B
>   Type:   Direct-Access                    ANSI SCSI revision: 03
> 
> 
> and the driver sees everything:
> 
> s05:~# cat /proc/scsi/qla2xxx/0
> QLogic PCI to Fibre Channel Host Adapter for QLA2310:
>         Firmware version 3.03.08 IPX, Driver version 8.00.02b4-k
> ISP: ISP2300, Serial# R74545
> Request Queue = 0xcf940000, Response Queue = 0xcf980000
> Request Queue count = 2048, Response Queue count = 512
> Total number of active commands = 0
> Total number of interrupts = 1117762
>     Device queue depth = 0x20
> Number of free request entries = 964
> Number of mailbox timeouts = 0
> Number of ISP aborts = 0
> Number of loop resyncs = 0
> Number of retries for empty slots = 0
> Number of reqs in pending_q= 0, retry_q= 0, done_q= 0, scsi_retry_q= 0
> Host adapter:loop state = <READY>, flags = 0x1a03
> Dpc flags = 0x0
> MBX flags = 0x0
> Link down Timeout = 030
> Port down retry = 030
> Login retry count = 030
> Commands retried with dropped frame(s) = 0
> Product ID = 4953 5020 2020 0001
> 
> 
> SCSI Device Information:
> scsi-qla0-adapter-node=200000e08b1bd113;
> scsi-qla0-adapter-port=210000e08b1bd113;
> scsi-qla0-target-0=210000d023800002;
> scsi-qla0-target-1=210000d023600002;
> 
> SCSI LUN Information:
> (Id:Lun)  * - indicates lun is not registered with the OS.
> ( 0: 0): Total reqs 2, Pending reqs 0, flags 0x0*, 0:0:81 00
> ( 0: 3): Total reqs 470693, Pending reqs 0, flags 0x0, 0:0:81 00
> ( 0: 9): Total reqs 227717, Pending reqs 0, flags 0x0, 0:0:81 00
> ( 0:11): Total reqs 0, Pending reqs 0, flags 0x0*, 0:0:81 00
> ( 0:13): Total reqs 0, Pending reqs 0, flags 0x0*, 0:0:81 00
> ( 1: 0): Total reqs 2, Pending reqs 0, flags 0x0*, 0:0:82 00
> ( 1:10): Total reqs 12, Pending reqs 0, flags 0x0, 0:0:82 00
> ( 1:12): Total reqs 0, Pending reqs 0, flags 0x0*, 0:0:82 00
> ( 1:14): Total reqs 0, Pending reqs 0, flags 0x0*, 0:0:82 00
> 
> 
> while on 2.6.12.5 and 2.6.13-rc6 it looks like this:
> 
> sm05:~# scsiadd -a 0 0 0 9
> Attached devices:
> Host: scsi0 Channel: 00 Id: 00 Lun: 03
>   Vendor: IFT      Model: A16F-R1211       Rev: 334B
>   Type:   Direct-Access                    ANSI SCSI revision: 03
> Host: scsi0 Channel: 00 Id: 00 Lun: 09
>   Vendor: IFT      Model: A16F-R1211       Rev: 334B
>   Type:   Direct-Access                    ANSI SCSI revision: 03
> 
> 
> sm05:~# scsiadd -a 0 0 1 10
> Attached devices:
> Host: scsi0 Channel: 00 Id: 00 Lun: 03
>   Vendor: IFT      Model: A16F-R1211       Rev: 334B
>   Type:   Direct-Access                    ANSI SCSI revision: 03
> Host: scsi0 Channel: 00 Id: 00 Lun: 09
>   Vendor: IFT      Model: A16F-R1211       Rev: 334B
>   Type:   Direct-Access                    ANSI SCSI revision: 03
> 
> 
> unfortunately, the proc interface was removed:

Why, is some data missing?

Also try using lsscsi.

> s05:/sys/devices/pci0000:00/0000:00:02.0/0000:01:00.0/0000:02:02.0/host0#
> find .
> .
> ./rport-0:0-1
> ./rport-0:0-1/power
> ./rport-0:0-1/power/state
> ./rport-0:0-0
> ./rport-0:0-0/target0:0:0
> ./rport-0:0-0/target0:0:0/0:0:0:9
> ./rport-0:0-0/target0:0:0/0:0:0:9/ioerr_cnt
> ./rport-0:0-0/target0:0:0/0:0:0:9/iodone_cnt
> ./rport-0:0-0/target0:0:0/0:0:0:9/iorequest_cnt
> ./rport-0:0-0/target0:0:0/0:0:0:9/iocounterbits
> ./rport-0:0-0/target0:0:0/0:0:0:9/timeout
> ./rport-0:0-0/target0:0:0/0:0:0:9/state
> ./rport-0:0-0/target0:0:0/0:0:0:9/delete
> ./rport-0:0-0/target0:0:0/0:0:0:9/rescan
> ./rport-0:0-0/target0:0:0/0:0:0:9/rev
> ./rport-0:0-0/target0:0:0/0:0:0:9/model
> ./rport-0:0-0/target0:0:0/0:0:0:9/vendor
> ./rport-0:0-0/target0:0:0/0:0:0:9/scsi_level
> ./rport-0:0-0/target0:0:0/0:0:0:9/type
> ./rport-0:0-0/target0:0:0/0:0:0:9/queue_type
> ./rport-0:0-0/target0:0:0/0:0:0:9/queue_depth
> ./rport-0:0-0/target0:0:0/0:0:0:9/device_blocked
> ./rport-0:0-0/target0:0:0/0:0:0:9/bus
> ./rport-0:0-0/target0:0:0/0:0:0:9/driver
> ./rport-0:0-0/target0:0:0/0:0:0:9/block
> ./rport-0:0-0/target0:0:0/0:0:0:9/power
> ./rport-0:0-0/target0:0:0/0:0:0:9/power/state
> ./rport-0:0-0/target0:0:0/0:0:0:3
> ./rport-0:0-0/target0:0:0/0:0:0:3/ioerr_cnt
> ./rport-0:0-0/target0:0:0/0:0:0:3/iodone_cnt
> ./rport-0:0-0/target0:0:0/0:0:0:3/iorequest_cnt
> ./rport-0:0-0/target0:0:0/0:0:0:3/iocounterbits
> ./rport-0:0-0/target0:0:0/0:0:0:3/timeout
> ./rport-0:0-0/target0:0:0/0:0:0:3/state
> ./rport-0:0-0/target0:0:0/0:0:0:3/delete
> ./rport-0:0-0/target0:0:0/0:0:0:3/rescan
> ./rport-0:0-0/target0:0:0/0:0:0:3/rev
> ./rport-0:0-0/target0:0:0/0:0:0:3/model
> ./rport-0:0-0/target0:0:0/0:0:0:3/vendor
> ./rport-0:0-0/target0:0:0/0:0:0:3/scsi_level
> ./rport-0:0-0/target0:0:0/0:0:0:3/type
> ./rport-0:0-0/target0:0:0/0:0:0:3/queue_type
> ./rport-0:0-0/target0:0:0/0:0:0:3/queue_depth
> ./rport-0:0-0/target0:0:0/0:0:0:3/device_blocked
> ./rport-0:0-0/target0:0:0/0:0:0:3/bus
> ./rport-0:0-0/target0:0:0/0:0:0:3/driver
> ./rport-0:0-0/target0:0:0/0:0:0:3/block
> ./rport-0:0-0/target0:0:0/0:0:0:3/power
> ./rport-0:0-0/target0:0:0/0:0:0:3/power/state
> ./rport-0:0-0/target0:0:0/power
> ./rport-0:0-0/target0:0:0/power/state
> ./rport-0:0-0/power
> ./rport-0:0-0/power/state
> ./nvram
> ./fw_dump
> ./power
> ./power/state
> 
> 
> apparently the targets on rport-0:0-1 are not scanned at all, and
> so the devices on the secondary controller are not reachable.
> 
> placing an additional link between the two fabric switches did
> double the amount of targets, but not solve our problem.
> It seems to us the 2.6.12+ driver does not allow access to
> controllers not directly attached to the very same fabric switch.
> 
> how can this be fixed?
> 
> 
> Best regards
> Frederik Schueler

-- Patrick Mansfield

Re: new qla2xxx driver breaks SAN setup with 2 controllers

[Frederik Schueler]

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

Hello,

On Tue, Aug 23, 2005 at 01:00:40PM -0700, Patrick Mansfield wrote:
> The use of scsiadd script implies that you are attaching or somehow
> modifying the storage after the driver has loaded. Is that correct?

yes exactly, only the bootdrive LUN is registered after bootup. I have
to selectively scsiadd the other LUNs if there is a gap between the 
boot LUN (1-8 in our setup) and the shared storages (9-14). I don't
consider this a bug though, I had to remove some devices otherwise, 
and old drivers had to be patched to allow this at all.


> There is a fix for scanning initiated via user space, this change:
> 
> http://www.kernel.org/git/?p=linux/kernel/git/jejb/scsi-rc-fixes-2.6.git;a=commit;h=5c44cd2afad3f7b015542187e147a820600172f1
> 
> The above fix is in the current 2.6 git tree. Does that fix your problem?
 
It does, thanks for the hint :-)

I see this is in rc7 too.


> Also try using lsscsi.

it does not list the non-registered LUNs the driver knows about, as the
old proc interface did.


Best regards
Frederik Schueler

-- 
ENOSIG

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: new qla2xxx driver breaks SAN setup with 2 controllers

[Christoph Hellwig]

On Wed, Aug 24, 2005 at 11:55:20AM +0200, Frederik Schueler wrote:
> Hello,
> 
> On Tue, Aug 23, 2005 at 01:00:40PM -0700, Patrick Mansfield wrote:
> > The use of scsiadd script implies that you are attaching or somehow
> > modifying the storage after the driver has loaded. Is that correct?
> 
> yes exactly, only the bootdrive LUN is registered after bootup. I have
> to selectively scsiadd the other LUNs if there is a gap between the 
> boot LUN (1-8 in our setup) and the shared storages (9-14). I don't
> consider this a bug though, I had to remove some devices otherwise, 
> and old drivers had to be patched to allow this at all.

Actually this sounds like a bug in your storage system.  It's probably
reporting to be only SCSI2 complicant, which doesn't make sense for
FC storage.  Please try the patch below:

Index: scsi-misc-2.6/drivers/scsi/scsi_devinfo.c
===================================================================
--- scsi-misc-2.6.orig/drivers/scsi/scsi_devinfo.c	2005-08-13 13:53:53.000000000 +0200
+++ scsi-misc-2.6/drivers/scsi/scsi_devinfo.c	2005-08-24 12:00:22.000000000 +0200
@@ -162,6 +162,7 @@
 	{"IBM", "AuSaV1S2", NULL, BLIST_FORCELUN},
 	{"IBM", "ProFibre 4000R", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
 	{"IBM", "2105", NULL, BLIST_RETRY_HWERROR},
+	{"IFT", "A16F-R1211", NULL, BLIST_REPORTLUN2},
 	{"iomega", "jaz 1GB", "J.86", BLIST_NOTQ | BLIST_NOLUN},
 	{"IOMEGA", "Io20S         *F", NULL, BLIST_KEY},
 	{"INSITE", "Floptical   F*8I", NULL, BLIST_KEY},

Re: new qla2xxx driver breaks SAN setup with 2 controllers

[Frederik Schueler]

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

Hello,

On Wed, Aug 24, 2005 at 11:01:12AM +0100, Christoph Hellwig wrote:
> > yes exactly, only the bootdrive LUN is registered after bootup. I have
> > to selectively scsiadd the other LUNs if there is a gap between the 
> > boot LUN (1-8 in our setup) and the shared storages (9-14). I don't
> > consider this a bug though, I had to remove some devices otherwise, 
> > and old drivers had to be patched to allow this at all.
> 
> Actually this sounds like a bug in your storage system.  It's probably
> reporting to be only SCSI2 complicant, which doesn't make sense for
> FC storage.  Please try the patch below:

[...]

Unfortunately this does not fix this issue, besides the SAN being 
reported as a scsi3 device now.

Thanks anyway :)
Frederik Schueler

-- 
ENOSIG

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: new qla2xxx driver breaks SAN setup with 2 controllers

[Christoph Hellwig]

On Wed, Aug 24, 2005 at 02:48:03PM +0200, Frederik Schueler wrote:
> Hello,
> 
> On Wed, Aug 24, 2005 at 11:01:12AM +0100, Christoph Hellwig wrote:
> > > yes exactly, only the bootdrive LUN is registered after bootup. I have
> > > to selectively scsiadd the other LUNs if there is a gap between the 
> > > boot LUN (1-8 in our setup) and the shared storages (9-14). I don't
> > > consider this a bug though, I had to remove some devices otherwise, 
> > > and old drivers had to be patched to allow this at all.
> > 
> > Actually this sounds like a bug in your storage system.  It's probably
> > reporting to be only SCSI2 complicant, which doesn't make sense for
> > FC storage.  Please try the patch below:
> 
> [...]
> 
> Unfortunately this does not fix this issue, besides the SAN being 
> reported as a scsi3 device now.

Cane you add BLIST_SPARSELUN and BLIST_LARGELUN to the flags aswell?

Re: new qla2xxx driver breaks SAN setup with 2 controllers

[Frederik Schueler]

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

Hello,

no change.

On Wed, Aug 24, 2005 at 01:50:22PM +0100, Christoph Hellwig wrote:
> > > Actually this sounds like a bug in your storage system.  It's probably
> > > reporting to be only SCSI2 complicant, which doesn't make sense for
> > > FC storage.  Please try the patch below:
> > 
> > [...]
> > 
> > Unfortunately this does not fix this issue, besides the SAN being 
> > reported as a scsi3 device now.
> 
> Cane you add BLIST_SPARSELUN and BLIST_LARGELUN to the flags aswell?

-- 
ENOSIG

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: new qla2xxx driver breaks SAN setup with 2 controllers

[Patrick Mansfield]

On Wed, Aug 24, 2005 at 03:08:23PM +0200, Frederik Schueler wrote:
> Hello,
> 
> no change.

What was logged? Any errors?

Try setting scsi logging_level for scan, after boot/load:

     sysctl -w dev.scsi.logging_level=0x1c0

Then reload the qla driver, and post logs.

If the qlogic driver returned DID_NO_CONNECT while scanning (or similar
errors), we stop the scan, but there is no code like that in the mainline
qlogic driver.

Can you also try this patch to use REPORT LUN scan even if no storage on
LUN 0?  Herre posted a similar patch that keeps LUN 0 around after the
scan, this version does not; I was going to post this after 2.6.13 was
out.

Also, you can pass devinfo additions as a module param (or boot time
param).

diff -uprN -X /home/patman/dontdiff linux-2.6.13-rc6-git13/drivers/scsi/scsi_scan.c lun0-linux-2.6.13-rc6-git13/drivers/scsi/scsi_scan.c
--- linux-2.6.13-rc6-git13/drivers/scsi/scsi_scan.c	2005-08-21 03:20:19.000000000 -0700
+++ lun0-linux-2.6.13-rc6-git13/drivers/scsi/scsi_scan.c	2005-08-24 09:22:23.000000000 -0700
@@ -64,14 +64,14 @@
  * SCSI_SCAN_NO_RESPONSE: no valid response received from the target, this
  * includes allocation or general failures preventing IO from being sent.
  *
- * SCSI_SCAN_TARGET_PRESENT: target responded, but no device is available
+ * SCSI_SCAN_LUN_IGNORED: target responded, but no device is available
  * on the given LUN.
  *
  * SCSI_SCAN_LUN_PRESENT: target responded, and a device is available on a
  * given LUN.
  */
 #define SCSI_SCAN_NO_RESPONSE		0
-#define SCSI_SCAN_TARGET_PRESENT	1
+#define SCSI_SCAN_LUN_IGNORED		1
 #define SCSI_SCAN_LUN_PRESENT		2
 
 static char *scsi_null_device_strs = "nullnullnullnull";
@@ -585,7 +585,7 @@ static void scsi_probe_lun(struct scsi_r
 
 	/*
 	 * The scanning code needs to know the scsi_level, even if no
-	 * device is attached at LUN 0 (SCSI_SCAN_TARGET_PRESENT) so
+	 * device is attached at LUN 0 (SCSI_SCAN_LUN_IGNORED) so
 	 * non-zero LUNs can be scanned.
 	 */
 	sdev->scsi_level = inq_result[2] & 0x07;
@@ -776,6 +776,19 @@ static int scsi_add_lun(struct scsi_devi
 	return SCSI_SCAN_LUN_PRESENT;
 }
 
+/*
+ * scsi_scan_remove: Helper funciton to free up sdev's that are not added
+ * as sys devices. That is, we never call scsi_probe_and_add_lun for these
+ * sdev's.
+ */
+static void scsi_scan_remove(struct scsi_device *sdev)
+{
+	if (sdev->host->hostt->slave_destroy)
+		sdev->host->hostt->slave_destroy(sdev);
+	transport_destroy_device(&sdev->sdev_gendev);
+	put_device(&sdev->sdev_gendev);
+}
+
 /**
  * scsi_probe_and_add_lun - probe a LUN, if a LUN is found add it
  * @starget:	pointer to target device structure
@@ -788,9 +801,12 @@ static int scsi_add_lun(struct scsi_devi
  *     Call scsi_probe_lun, if a LUN with an attached device is found,
  *     allocate and set it up by calling scsi_add_lun.
  *
+ * Note: LUN 0 is special cased so it can be used for a REPORT LUN scan,
+ *     the caller must release the sdev if we return SCSI_SCAN_LUN_IGNORED.
+ *
  * Return:
  *     SCSI_SCAN_NO_RESPONSE: could not allocate or setup a Scsi_Device
- *     SCSI_SCAN_TARGET_PRESENT: target responded, but no device is
+ *     SCSI_SCAN_LUN_IGNORED: target responded, but no device is
  *         attached at the LUN
  *     SCSI_SCAN_LUN_PRESENT: a new Scsi_Device was allocated and initialized
  **/
@@ -860,7 +876,7 @@ static int scsi_probe_and_add_lun(struct
 		SCSI_LOG_SCAN_BUS(3, printk(KERN_INFO
 					"scsi scan: peripheral qualifier of 3,"
 					" no device added\n"));
-		res = SCSI_SCAN_TARGET_PRESENT;
+		res = SCSI_SCAN_LUN_IGNORED;
 		goto out_free_result;
 	}
 
@@ -879,17 +895,14 @@ static int scsi_probe_and_add_lun(struct
  out_free_sreq:
 	scsi_release_request(sreq);
  out_free_sdev:
-	if (res == SCSI_SCAN_LUN_PRESENT) {
+	if ((res == SCSI_SCAN_LUN_PRESENT) ||
+	    ((lun == 0) && (res == SCSI_SCAN_LUN_IGNORED))) {
 		if (sdevp) {
 			scsi_device_get(sdev);
 			*sdevp = sdev;
 		}
-	} else {
-		if (sdev->host->hostt->slave_destroy)
-			sdev->host->hostt->slave_destroy(sdev);
-		transport_destroy_device(&sdev->sdev_gendev);
-		put_device(&sdev->sdev_gendev);
-	}
+	} else
+		scsi_scan_remove(sdev);
  out:
 	return res;
 }
@@ -1266,6 +1279,8 @@ struct scsi_device *__scsi_add_device(st
 	get_device(&starget->dev);
 	down(&shost->scan_mutex);
 	res = scsi_probe_and_add_lun(starget, lun, NULL, &sdev, 1, hostdata);
+	if ((lun == 0) && (res == SCSI_SCAN_LUN_IGNORED))
+		scsi_scan_remove(sdev);
 	if (res != SCSI_SCAN_LUN_PRESENT)
 		sdev = ERR_PTR(-ENODEV);
 	up(&shost->scan_mutex);
@@ -1337,7 +1352,8 @@ void scsi_scan_target(struct device *par
 		/*
 		 * Scan for a specific host/chan/id/lun.
 		 */
-		scsi_probe_and_add_lun(starget, lun, NULL, NULL, rescan, NULL);
+		res = scsi_probe_and_add_lun(starget, lun, NULL, &sdev,
+					     rescan, NULL);
 		goto out_reap;
 	}
 
@@ -1345,8 +1361,11 @@ void scsi_scan_target(struct device *par
 	 * Scan LUN 0, if there is some response, scan further. Ideally, we
 	 * would not configure LUN 0 until all LUNs are scanned.
 	 */
-	res = scsi_probe_and_add_lun(starget, 0, &bflags, &sdev, rescan, NULL);
-	if (res == SCSI_SCAN_LUN_PRESENT) {
+	lun = 0;
+	res = scsi_probe_and_add_lun(starget, lun, &bflags, &sdev, rescan,
+				     NULL);
+	WARN_ON(!sdev && res != SCSI_SCAN_NO_RESPONSE);
+	if (sdev && res != SCSI_SCAN_NO_RESPONSE)
 		if (scsi_report_lun_scan(sdev, bflags, rescan) != 0)
 			/*
 			 * The REPORT LUN did not scan the target,
@@ -1354,20 +1373,12 @@ void scsi_scan_target(struct device *par
 			 */
 			scsi_sequential_lun_scan(starget, bflags,
 				       	res, sdev->scsi_level, rescan);
-	} else if (res == SCSI_SCAN_TARGET_PRESENT) {
-		/*
-		 * There's a target here, but lun 0 is offline so we
-		 * can't use the report_lun scan.  Fall back to a
-		 * sequential lun scan with a bflags of SPARSELUN and
-		 * a default scsi level of SCSI_2
-		 */
-		scsi_sequential_lun_scan(starget, BLIST_SPARSELUN,
-				SCSI_SCAN_TARGET_PRESENT, SCSI_2, rescan);
-	}
 	if (sdev)
 		scsi_device_put(sdev);
 
  out_reap:
+	if ((lun == 0) && (res == SCSI_SCAN_LUN_IGNORED))
+		scsi_scan_remove(sdev);
 	/* now determine if the target has any children at all
 	 * and if not, nuke it */
 	scsi_target_reap(starget);

-- Patrick Mansfield

Re: new qla2xxx driver breaks SAN setup with 2 controllers

[Frederik Schueler]

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

Hello,

your patch works!

first a box booting from a gdth:

a01:~# lsscsi 
[0:0:0:0]    disk    ICP      Host Drive  #00        /dev/sda
[0:2:6:0]    process SUPER    GEM318           0     -       
[1:0:0:10]   disk    IFT      A16F-R1211       334B  /dev/sdb
[1:0:0:12]   disk    IFT      A16F-R1211       334B  /dev/sdc
[1:0:0:14]   disk    IFT      A16F-R1211       334B  /dev/sdd
[1:0:1:9]    disk    IFT      A16F-R1211       334B  /dev/sde
[1:0:1:11]   disk    IFT      A16F-R1211       334B  /dev/sdf
[1:0:1:13]   disk    IFT      A16F-R1211       334B  /dev/sdg


and this is one of the cluster nodes, wich boots from san:

s06:~# lsscsi 
[0:0:0:3]    disk    IFT      A16F-R1211       334B  /dev/sda
[0:0:0:10]   disk    IFT      A16F-R1211       334B  /dev/sdb
[0:0:0:12]   disk    IFT      A16F-R1211       334B  /dev/sdc
[0:0:0:14]   disk    IFT      A16F-R1211       334B  /dev/sdd
[0:0:1:9]    disk    IFT      A16F-R1211       334B  /dev/sde
[0:0:1:11]   disk    IFT      A16F-R1211       334B  /dev/sdf
[0:0:1:13]   disk    IFT      A16F-R1211       334B  /dev/sdg


it finds everything on bootup.


Best regards
Frederik Schueler

-- 
ENOSIG

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]