Re: qlogicfc driver

Re: qlogicfc driver

[Roland Fehrenbacher]

> While the controller itself sees all the 3 drives
> when booting up, under Linux I am only able to see the LUN 0 drives.

Update to my previous post:

The command 
echo "scsi add-single-device 0 0 0 1" > /proc/scsi/scsi
makes the LUN 1 device appear, so it seems the problem is with the SCSI 
scanning code.

Roland

Re: qlogicfc driver

[jsack]

On Fri, 20 Jul 2001, Roland Fehrenbacher wrote:

> > While the controller itself sees all the 3 drives
> > when booting up, under Linux I am only able to see the LUN 0 drives.
> 
> Update to my previous post:
> 
> The command 
> echo "scsi add-single-device 0 0 0 1" > /proc/scsi/scsi
> makes the LUN 1 device appear, so it seems the problem is with the SCSI 
> scanning code.
> 


is "probe all luns" configured in your kernel? 
 (.config: CONFIG_SCSI_MULTI_LUN=y)

..jim

Re: qlogicfc driver

[Roland Fehrenbacher]

    Roland> While the controller itself sees all the 3 drives when booting up,
    Roland> under Linux I am only able to see the LUN 0 drives.

    Roland> The command echo "scsi add-single-device 0 0 0 1" > /proc/scsi/scsi
    Roland> makes the LUN 1 device appear, so it seems the problem is with the
    Roland> SCSI scanning code.

In the meantime I found out that I need to identify the RAID controller as a
sparse LUN device. This works fine as long as there is a host drive mapped to
LUN 0. If there is no host drive mapped to LUN 0, we run into a bug of the SCSI
scanning code: The variable *sparse_lun=1 never gets set and any other host
drives at LUNs > 0 are not detected. This problem has already been discussed
in a different context previously
(http://groups.google.com/groups?q=scsi_scan.c&hl=en&safe=off&rnum=2&selm=F888C30C3021D411B9DA00B0D0209BE8FAB0EB%40cvo-exchange.roguewave.com).

The following patch fixes the problem, and I can't see any side effects. Please
review the patch, and if approved, include it in the kernel.

Cheers,

Roland

--- scsi_scan.c.orig    Mon Jul 23 09:24:53 2001
+++ scsi_scan.c Thu Jul 26 16:29:14 2001
@@ -153,6 +153,8 @@
        {"DELL", "PSEUDO DEVICE .",   "*", BLIST_SPARSELUN}, // Dell PV 530F
        {"DELL", "PV530F",    "*", BLIST_SPARSELUN}, // Dell PV 530F
        {"EMC", "SYMMETRIX", "*", BLIST_SPARSELUN},
+       {"CMD", "CRA-7280", "*", BLIST_SPARSELUN},   // CMD RAID Controller
+       {"Zzyzx", "RocketStor 500S", "*", BLIST_SPARSELUN}, // Zzyzx RocketStor Raid
        {"SONY", "TSL",       "*", BLIST_FORCELUN},  // DDS3 & DDS4 autoloaders
        {"DELL", "PERCRAID", "*", BLIST_FORCELUN},
        {"HP", "NetRAID-4M", "*", BLIST_FORCELUN},
@@ -565,20 +567,26 @@
        }
 
        /*
-        * Check the peripheral qualifier field - this tells us whether LUNS
-        * are supported here or not.
+        * Check for SPARSELUN before checking the peripheral qualifier,
+        * so sparse lun devices are completely scanned.
         */
-       if ((scsi_result[0] >> 5) == 3) {
-               scsi_release_request(SRpnt);
-               return 0;       /* assume no peripheral if any sort of error */
-       }
 
        /*
         * Get any flags for this device.  
         */
        bflags = get_device_flags (scsi_result);
 
-
+       if (bflags & BLIST_SPARSELUN) {
+         *sparse_lun = 1;
+       }
+       /*
+        * Check the peripheral qualifier field - this tells us whether LUNS
+        * are supported here or not.
+        */
+       if ((scsi_result[0] >> 5) == 3) {
+               scsi_release_request(SRpnt);
+               return 0;       /* assume no peripheral if any sort of error */
+       }
         /*   The Toshiba ROM was "gender-changed" here as an inline hack.
              This is now much more generic.
              This is a mess: What we really want is to leave the scsi_result

Re: qlogicfc driver

[Roland Fehrenbacher]

    Roland> While the controller itself sees all the 3 drives when booting up,
    Roland> under Linux I am only able to see the LUN 0 drives.

    Roland> The command echo "scsi add-single-device 0 0 0 1" > /proc/scsi/scsi
    Roland> makes the LUN 1 device appear, so it seems the problem is with the
    Roland> SCSI scanning code.

In the meantime I found out that I need to identify the RAID controller as a
sparse LUN device. This works fine as long as there is a host drive mapped to
LUN 0. If there is no host drive mapped to LUN 0, we run into a bug of the SCSI
scanning code: The variable *sparse_lun=1 never gets set and any other host
drives at LUNs > 0 are not detected. This problem has already been discussed
in a different context previously
(http://groups.google.com/groups?q=scsi_scan.c&hl=en&safe=off&rnum=2&selm=F888C30C3021D411B9DA00B0D0209BE8FAB0EB%40cvo-exchange.roguewave.com).

The following patch fixes the problem, and I can't see any side effects. Please
review the patch, and if approved, include it in the kernel.

Cheers,

Roland

--- scsi_scan.c.orig    Mon Jul 23 09:24:53 2001
+++ scsi_scan.c Thu Jul 26 16:29:14 2001
@@ -153,6 +153,8 @@
        {"DELL", "PSEUDO DEVICE .",   "*", BLIST_SPARSELUN}, // Dell PV 530F
        {"DELL", "PV530F",    "*", BLIST_SPARSELUN}, // Dell PV 530F
        {"EMC", "SYMMETRIX", "*", BLIST_SPARSELUN},
+       {"CMD", "CRA-7280", "*", BLIST_SPARSELUN},   // CMD RAID Controller
+       {"Zzyzx", "RocketStor 500S", "*", BLIST_SPARSELUN}, // Zzyzx RocketStor Raid
        {"SONY", "TSL",       "*", BLIST_FORCELUN},  // DDS3 & DDS4 autoloaders
        {"DELL", "PERCRAID", "*", BLIST_FORCELUN},
        {"HP", "NetRAID-4M", "*", BLIST_FORCELUN},
@@ -565,20 +567,26 @@
        }
 
        /*
-        * Check the peripheral qualifier field - this tells us whether LUNS
-        * are supported here or not.
+        * Check for SPARSELUN before checking the peripheral qualifier,
+        * so sparse lun devices are completely scanned.
         */
-       if ((scsi_result[0] >> 5) == 3) {
-               scsi_release_request(SRpnt);
-               return 0;       /* assume no peripheral if any sort of error */
-       }
 
        /*
         * Get any flags for this device.  
         */
        bflags = get_device_flags (scsi_result);
 
-
+       if (bflags & BLIST_SPARSELUN) {
+         *sparse_lun = 1;
+       }
+       /*
+        * Check the peripheral qualifier field - this tells us whether LUNS
+        * are supported here or not.
+        */
+       if ((scsi_result[0] >> 5) == 3) {
+               scsi_release_request(SRpnt);
+               return 0;       /* assume no peripheral if any sort of error */
+       }
         /*   The Toshiba ROM was "gender-changed" here as an inline hack.
              This is now much more generic.
              This is a mess: What we really want is to leave the scsi_result

Re: qlogicfc driver

[Roland Fehrenbacher]

Update to my previous post:

If I force a SCSI scan using

echo "scsi add-single-device 0 0 0 1" > /proc/scsi/scsi

the device is detected correctly. So it seems like a problem in the SCSI
scanning code.

Cheers,

Roland

----
Roland Fehrenbacher
transtec AG
Waldhörnlestrasse 18
D-72072 Tübingen
Tel.: +49(0)7071/703-320
Fax: +49(0)7071/703-90320
EMail: Roland.Fehrenbacher@transtec.de
http://www.transtec.de

qlogicfc driver

[Roland Fehrenbacher]

Hi,

I am testing a SAN setup with a Fibre Channel RAID Controller (GMR) connected
to a QLA2200/QLA2100 via Gadzoox Cappelix Switches. The RAID controller
supports 32 LUNs on configurable SCSI target Ids. In the present case I have 3
RAID sets with pairs (SCSI Id, LUN) (0, 0) (0, 1) (1, 0), i.e. two drives with
LUN 0 and one with LUN 1. While the controller itself sees all the 3 drives
when booting up, under Linux I am only able to see the LUN 0 drives.

Kernel is stock 2.4.6 using the qlogicfc driver. I also tried to set
max_scsi_luns=32, even though the default of 8 should be enough. No success.
Of course, support for multiple LUNs is enabled in the kernel. By the way,
using the beta driver on the qlogic site (qla2x00src-v4.27Beta.tgz) also
doesn't help. So the issue might not even be driver related.

Any ideas anyone?

Thanks.

Cheers,

Roland

----
Roland Fehrenbacher
transtec AG
Waldhörnlestrasse 18
D-72072 Tübingen
Tel.: +49(0)7071/703-320
Fax: +49(0)7071/703-90320
EMail: Roland.Fehrenbacher@transtec.de
http://www.transtec.de

qlogicfc driver

[Dmitry Meshchaninov]

  Hi!
  Judging from recent messages on linux-kernel and from the code which is
currently in 2.4.x the qlogicfc driver needs to be updated a bit. I have
done some amount of work on this driver and have sent patches to
Chris in the past, however I did not receive any comments on my changes.
It looks like Chris is too busy with other things right now, and I will
gladly maintain the driver if there is a consensus that the driver needs
a new maintainer. Meanwhile I am cleaning up driver for 2.4.4
(not tested with 2.4.5 yet, but probably will work). I'll publish those
changes if there will be any interest.  It is a  drop-in replacement for
the five files in drivers/scsi/ (qlogicfc.c, qlogicfc.h, qlogicfc_inc.h,
qlogicfc_asm_ip.c and qlogicfc_asm.c).  This contains updated (both with
and without ip support) firmware and many bugfixes. I decided not to
provide a patch because it is bigger then just those five files combind.
I have splitted up driver body into .h-file with types&defines  and
driver itself (as it should be). But this is negotiable.

Sincerely,
Dmitry Meshchaninov
software engineer
DataFoundation Inc

Re: qlogicfc driver

[Jeff Garzik]

Dmitry Meshchaninov wrote:
> 
>   Hi!
>   Judging from recent messages on linux-kernel and from the code which is
> currently in 2.4.x the qlogicfc driver needs to be updated a bit. I have
> done some amount of work on this driver and have sent patches to
> Chris in the past, however I did not receive any comments on my changes.
> It looks like Chris is too busy with other things right now, and I will
> gladly maintain the driver if there is a consensus that the driver needs
> a new maintainer. Meanwhile I am cleaning up driver for 2.4.4
> (not tested with 2.4.5 yet, but probably will work). I'll publish those
> changes if there will be any interest.  It is a  drop-in replacement for
> the five files in drivers/scsi/ (qlogicfc.c, qlogicfc.h, qlogicfc_inc.h,
> qlogicfc_asm_ip.c and qlogicfc_asm.c).  This contains updated (both with
> and without ip support) firmware and many bugfixes. I decided not to
> provide a patch because it is bigger then just those five files combind.
> I have splitted up driver body into .h-file with types&defines  and
> driver itself (as it should be). But this is negotiable.

If you are working on qlogicfc, that's great!

But since others are currently using this driver without problems, you
might consider sending in your patches separated out (per
Documentation/SubmittingPatches) so that it is easier for others to
review and apply them in turn.

-- 
Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |

Re: qlogicfc driver

[David S. Miller]

Jeff Garzik writes:
 > If you are working on qlogicfc, that's great!
 > 
 > But since others are currently using this driver without problems, you
 > might consider sending in your patches separated out (per
 > Documentation/SubmittingPatches) so that it is easier for others to
 > review and apply them in turn.

One thing that is especially important is multi-platform testing
since the current driver does use all of the proper APIs and is
mindful of endianness and word size issues.

Later,
David S. Miller
davem@redhat.com

Re: qlogicfc driver

[christophe barbé]

Dmitry,

Could you post your driver, please, to the lkml (It should not be so big)
or to me if you prefer. I would like to test it. Files (instead of patches)
are ok for me.

Christophe ...

Le ven, 29 jun 2001 23:59:34, David S. Miller a écrit :
> 
> Jeff Garzik writes:
>  > If you are working on qlogicfc, that's great!
>  > 
>  > But since others are currently using this driver without problems, you
>  > might consider sending in your patches separated out (per
>  > Documentation/SubmittingPatches) so that it is easier for others to
>  > review and apply them in turn.
> 
> One thing that is especially important is multi-platform testing
> since the current driver does use all of the proper APIs and is
> mindful of endianness and word size issues.
> 
> Later,
> David S. Miller
> davem@redhat.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
-- 
Christophe Barbé
Software Engineer - christophe.barbe@lineo.fr
Lineo France - Lineo High Availability Group
42-46, rue Médéric - 92110 Clichy - France
phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01
http://www.lineo.com

qlogicfc driver

[christophe barbé]

My previous mail about Qlogic Fiber Channel driver didn't get so many
attention. 

The QLogic support is like a wall. You can't use a normal e-mail. Instead
of that you should use a http form. And the answer you get is anonymous and
IMHO a standart one.

"... Please check our site periodically for driver updates.
QLogic CSG Product Support "

I know that they have a working IP enhanced driver, DOCs are distributed
under NDA and the IP-enhanced firmware also.

What we have in the kernel today is a nearly broken driver with an obscure
firmware. I believe that this situation only tell (lie) people "this card
is supported under linux" and so they buy this hardware. That's what I've
done.

I'm ready to spend time to modify the driver but I'm not fluent in firmware
microcode reading and I've not managed to find documentations.

There's no maintener for it and Chris Loveland is unreachable.
If somebody has a valid email address for Chris Loveland, Please send it to
me.

If somebody can give me a email address for a HUMAN person working for
QLogic (I hate their e-support 

What about removing this driver ?

Christophe


-- 
Christophe Barbé
Software Engineer - christophe.barbe@lineo.fr
Lineo France - Lineo High Availability Group
42-46, rue Médéric - 92110 Clichy - France
phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01
http://www.lineo.com