Enterprise patch needed - please help

Enterprise patch needed - please help

[HINCHMAN,PAUL (HP-Roseville,ex1)]

Dear SCSI maintainers,

We need desparately a patch (or better yet) permanent integration of an
enablement for Linux to see max_scsi_luns "out of the box", at least in
"enterprise" kernels.  I'm not a coder, but I do test Linux connectivity to
mass storage over fibre channel.  It's easy enough to go into xconfig or
menuconfig and enable 128 LUN's, then build a new kernel.  However, doing so
negates support from whatever vendor (like SuSE and Red Hat).  So, an
"out-of-the-box" solution is desparately needed.  Linux won't go far in the
enterprise without fully enabled (and stress-tested) storage.  I'd like to
see this change to the 2.4.18+ kernels and beyond, I think it would probably
be simple. Any advice you folks could give me as to who to talk to and
escalate this issue would be great.  I'll provide more info to anyone who
thinks they can help.

R/

Paul Hinchman
NSAS Linux Connectivity Lab
HP Roseville, CA
916.785.2346

Re: Enterprise patch needed - please help

[Alan Cox]

On Thu, 2002-05-30 at 00:23, HINCHMAN,PAUL (HP-Roseville,ex1) wrote:
> We need desparately a patch (or better yet) permanent integration of an
> enablement for Linux to see max_scsi_luns "out of the box", at least in
> "enterprise" kernels.  I'm not a coder, but I do test Linux connectivity to

Load the module with max_scsi_luns=number as an option

> negates support from whatever vendor (like SuSE and Red Hat).  So, an
> "out-of-the-box" solution is desparately needed.  Linux won't go far in the
> enterprise without fully enabled (and stress-tested) storage.  I'd like to
> see this change to the 2.4.18+ kernels and beyond, I think it would probably
> be simple. Any advice you folks could give me as to who to talk to and
> escalate this issue would be great.  I'll provide more info to anyone who
> thinks they can help.

What I am more curious about is why your storage system didn't get
enumerating using the SCSI-3 report luns code path

Re: Enterprise patch needed - please help

[Michael Clark]

On 05/30/02 08:41, Alan Cox wrote:

>On Thu, 2002-05-30 at 00:23, HINCHMAN,PAUL (HP-Roseville,ex1) wrote:
>  
>
>>negates support from whatever vendor (like SuSE and Red Hat).  So, an
>>"out-of-the-box" solution is desparately needed.  Linux won't go far in the
>>enterprise without fully enabled (and stress-tested) storage.  I'd like to
>>see this change to the 2.4.18+ kernels and beyond, I think it would probably
>>be simple. Any advice you folks could give me as to who to talk to and
>>escalate this issue would be great.  I'll provide more info to anyone who
>>thinks they can help.
>>    
>>
>
>What I am more curious about is why your storage system didn't get
>enumerating using the SCSI-3 report luns code path
>

There was a bug regarding this a few revisions ago (2.4.17 it was fixed) 
where
even if the device reported SCSI-3, it still wouldn't scan past 8 luns. 
This bug
didn't exist in RedHat kernels.

Also, some devices need a BLIST_SPARSELUN added in scsi_scan.c - even if 
the device
reports SCSI-3, the scanning code by defaults stops when it finds a lun 
that doesn't
respond. It is quite common with enterpise storage to have sparse 
between luns.

~mc

Re: Enterprise patch needed - please help

[Alan Cox]

On Thu, 2002-05-30 at 05:46, Michael Clark wrote:
> Also, some devices need a BLIST_SPARSELUN added in scsi_scan.c - even if 
> the device
> reports SCSI-3, the scanning code by defaults stops when it finds a lun 
> that doesn't
> respond. It is quite common with enterpise storage to have sparse 
> between luns.

If we use report luns should we even be checking BLIST_SPARSELUN I
wonder

Re: Enterprise patch needed - please help

[Michael Clark]

On 05/30/02 20:38, Alan Cox wrote:

>On Thu, 2002-05-30 at 05:46, Michael Clark wrote:
>  
>
>>Also, some devices need a BLIST_SPARSELUN added in scsi_scan.c - even if 
>>the device
>>reports SCSI-3, the scanning code by defaults stops when it finds a lun 
>>that doesn't
>>respond. It is quite common with enterpise storage to have sparse 
>>between luns.
>>    
>>
>
>If we use report luns should we even be checking BLIST_SPARSELUN I
>wonder
>
>  
>
Oh, is this new or maybe my device doesn't report luns as I've needed
the sparse lun hint even though device was correctly detected as SCSI-3.
This is with 2.4.18

Re: Enterprise patch needed - please help

[Andrew Patterson]

On Thu, 2002-05-30 at 06:43, Michael Clark wrote:
> 
> On 05/30/02 20:38, Alan Cox wrote:
> 
> >On Thu, 2002-05-30 at 05:46, Michael Clark wrote:
> >  
> >
> >>Also, some devices need a BLIST_SPARSELUN added in scsi_scan.c - even if 
> >>the device
> >>reports SCSI-3, the scanning code by defaults stops when it finds a lun 
> >>that doesn't
> >>respond. It is quite common with enterpise storage to have sparse 
> >>between luns.
> >>    
> >>

The following entries in the device_list array of scsi_scan.c should do
the trick for HP arrays.

   {"HP", "A6188A", "*", BLIST_SPARSELUN},      // HP Va7100 Array
   {"HP", "A6189A", "*", BLIST_SPARSELUN},      // HP Va7400 Array
   {"HP", "A6189B", "*", BLIST_SPARSELUN},      // HP Va7410 Array
   {"HP", "OPEN-", "*", BLIST_SPARSELUN},       // HP XP Arrays

Note that you must have a LUN at LUN number 0, to detect sparse LUN's
above LUN number 7.  

Andrew Patterson

    

> >
> >If we use report luns should we even be checking BLIST_SPARSELUN I
> >wonder
> >
> >  
> >
> Oh, is this new or maybe my device doesn't report luns as I've needed
> the sparse lun hint even though device was correctly detected as SCSI-3.
> This is with 2.4.18
> 
> -
> 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
> 

RE: Enterprise patch needed - please help

[HINCHMAN,PAUL (HP-Roseville,ex1)]

Thank you all for your response.  Actually, the SPARSELUN problem is yet a
different thing which, if I remember right, Kurt Garloff had a hand in
fixing scsi_scan.c.  What I'm really talking about is (I think) in
/usr/src/<linux>/drivers/scsi/hosts.h, where CONFIG_SD_EXTRA_DEVS is 2
(NOTE: the path to this parameter in xconfig/menuconfig is set to 40).
Either way, we've been able to manually change hosts.h and/or change
"maximum number of SCSI disks that can be loaded as modules" (which
supposedly writes to CONFIG_SD_EXTRA_DEVS)in xconfig/menuconfig, and it all
works fine.  The problem comes in when our customers do this, they lose the
support of the distribution vendor, because they/we have to recompile to get
the changes effected.  I like the idea of a loadable module, taking into
account that our root file system is on a scsi disk, so this would truly be
an extra_dev thing.  Also, we'd need help to develope it.  
Once again, thanks to all!
R/
Paul Hinchman  

-----Original Message-----
From: Andrew Patterson [mailto:andrew@fc.hp.com]
Sent: Thursday, May 30, 2002 7:40 AM
To: Michael Clark
Cc: Alan Cox; HINCHMAN,PAUL " "(HP-Roseville,ex1);
'linux-scsi@vger.kernel.org'
Subject: Re: Enterprise patch needed - please help


On Thu, 2002-05-30 at 06:43, Michael Clark wrote:
> 
> On 05/30/02 20:38, Alan Cox wrote:
> 
> >On Thu, 2002-05-30 at 05:46, Michael Clark wrote:
> >  
> >
> >>Also, some devices need a BLIST_SPARSELUN added in scsi_scan.c - even if

> >>the device
> >>reports SCSI-3, the scanning code by defaults stops when it finds a lun 
> >>that doesn't
> >>respond. It is quite common with enterpise storage to have sparse 
> >>between luns.
> >>    
> >>

The following entries in the device_list array of scsi_scan.c should do
the trick for HP arrays.

   {"HP", "A6188A", "*", BLIST_SPARSELUN},      // HP Va7100 Array
   {"HP", "A6189A", "*", BLIST_SPARSELUN},      // HP Va7400 Array
   {"HP", "A6189B", "*", BLIST_SPARSELUN},      // HP Va7410 Array
   {"HP", "OPEN-", "*", BLIST_SPARSELUN},       // HP XP Arrays

Note that you must have a LUN at LUN number 0, to detect sparse LUN's
above LUN number 7.  

Andrew Patterson

    

> >
> >If we use report luns should we even be checking BLIST_SPARSELUN I
> >wonder
> >
> >  
> >
> Oh, is this new or maybe my device doesn't report luns as I've needed
> the sparse lun hint even though device was correctly detected as SCSI-3.
> This is with 2.4.18
> 
> -
> 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
> 

Mounting multiple LUNs on a single SCSI device

[Alan Dayley]

I am having problems mounting a second LUN on a dual slot PCMCIA SCSI 
device.  I can mount the first LUN by typing mount -t msdos /dev/sda1 
/mnt/card.  When I try /dev/sdb1, I rcv a error message stating mount: 
/dev/sdb1 is not a valid block device.

My OS is Linux RH 7.2.  Thank you for any help you can give.
-
/------------------------------------------
|Alan Dayley                 www.adtron.com
|Staff Software Engineer  602-735-0300 x331
|ADayley@adtron.com
|
|Adtron Corporation
|3710 E. University Drive, Suite 5
|Phoenix, AZ  85034
\-------------------------------------------

Re: Mounting multiple LUNs on a single SCSI device

[Kurt Garloff]

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

On Thu, May 30, 2002 at 10:30:25AM -0700, Alan Dayley wrote:
> I am having problems mounting a second LUN on a dual slot PCMCIA SCSI 
> device.  I can mount the first LUN by typing mount -t msdos /dev/sda1 
> /mnt/card.  When I try /dev/sdb1, I rcv a error message stating mount: 
> /dev/sdb1 is not a valid block device.

Look at the kernel log: Is the second hard drive detected? If yes: Is it
partitioned?
If no: Did you try max_scsi_luns=7 boot/module parameter?

Regards,
-- 
Kurt Garloff                   <kurt@garloff.de>         [Eindhoven, NL]
Physics: Plasma simulations    <K.Garloff@TUE.NL>     [TU Eindhoven, NL]
Linux: SCSI, Security          <garloff@suse.de>    [SuSE Nuernberg, DE]
 (See mail header or public key servers for PGP2 and GPG public keys.)

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