This originally was asking for help regarding QLA2200's, but I've since
discovered it's a kernel param problem that I'm not sure how to solve.
Using a default RH kernel (from SGI XFS installer) and passing
max_scsi_luns=128 in grub, and for scsi_mod, it seems to work.
But when I compile my own kernels, none of that stuff is modular, it's
all built in. I though that passing max_scsi_luns at boot time would
make the scsi subsystem just work with > 8 luns, but so far that doesn't
appear to be the case.
Can someone please tell me where I've gone wrong? I'm so deep into this,
I can't tell which way is up.
TIA
--
Austin Gonyou <[email protected]>
I'm really really sorry for asking such a seemingly stupid question, but
I'm having a very severe issue here and I can't seem to figure out the
fix.
If someone could exchange emails with me for a few mins I'd be very
grateful. I see that I have max_scsi_luns in my System.map, but I cannot
see luns > 8(0-7) with 2.4.19-pre10. The same driver set works with the
default RH installed kernel(2.4.9). So it leads me to believe that
putting max_scsi_luns=128 (or even 16) in grub.conf isn't being
effective.
Please help.
On Tue, 2002-06-25 at 19:46, Austin Gonyou wrote:
> This originally was asking for help regarding QLA2200's, but I've since
> discovered it's a kernel param problem that I'm not sure how to solve.
>
> Using a default RH kernel (from SGI XFS installer) and passing
> max_scsi_luns=128 in grub, and for scsi_mod, it seems to work.
>
> But when I compile my own kernels, none of that stuff is modular, it's
> all built in. I though that passing max_scsi_luns at boot time would
> make the scsi subsystem just work with > 8 luns, but so far that doesn't
> appear to be the case.
>
>
> Can someone please tell me where I've gone wrong? I'm so deep into this,
> I can't tell which way is up.
>
> TIA
> --
> Austin Gonyou <[email protected]>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Austin Gonyou <[email protected]>
I'm no expert on this bit but look in
drivers/scsi/scsi_scan.c for CONFIG_SCSI_MULTI_LUN
#ifdef CONFIG_SCSI_MULTI_LUN
static int max_scsi_luns = 8;
#else
static int max_scsi_luns = 1;
#endif
This is the variable you seem to want.
Note to SCSI maintainers. a quick vi `grep -l CONFIG_SCSI_MULTI_LUN`
here reveals lots of hardcoded values of 8. It seems to me
that perhaps a CONFIG_SCSI_MAX_LUN to replace
CONFIG_SCSI_MULTI_LUN would be in order.
I know Alan and others are planning to do major cleanup of
the scsi subsystem (hopefully after IDE stablizes?)
On Tue, Jun 25, 2002 at 08:50:35PM -0500, Austin Gonyou wrote:
> I'm really really sorry for asking such a seemingly stupid question, but
> I'm having a very severe issue here and I can't seem to figure out the
> fix.
>
> If someone could exchange emails with me for a few mins I'd be very
> grateful. I see that I have max_scsi_luns in my System.map, but I cannot
> see luns > 8(0-7) with 2.4.19-pre10. The same driver set works with the
> default RH installed kernel(2.4.9). So it leads me to believe that
> putting max_scsi_luns=128 (or even 16) in grub.conf isn't being
> effective.
>
> Please help.
>
> On Tue, 2002-06-25 at 19:46, Austin Gonyou wrote:
> > This originally was asking for help regarding QLA2200's, but I've since
> > discovered it's a kernel param problem that I'm not sure how to solve.
> >
> > Using a default RH kernel (from SGI XFS installer) and passing
> > max_scsi_luns=128 in grub, and for scsi_mod, it seems to work.
> >
> > But when I compile my own kernels, none of that stuff is modular, it's
> > all built in. I though that passing max_scsi_luns at boot time would
> > make the scsi subsystem just work with > 8 luns, but so far that doesn't
> > appear to be the case.
> >
> >
> > Can someone please tell me where I've gone wrong? I'm so deep into this,
> > I can't tell which way is up.
> >
> > TIA
> > --
> > Austin Gonyou <[email protected]>
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> --
> Austin Gonyou <[email protected]>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [email protected]
Remember Cernan and Schmitt
On Tue, 2002-06-25 at 21:48, jw schultz wrote:
> I'm no expert on this bit but look in
> drivers/scsi/scsi_scan.c for CONFIG_SCSI_MULTI_LUN
>
> #ifdef CONFIG_SCSI_MULTI_LUN
> static int max_scsi_luns = 8;
> #else
> static int max_scsi_luns = 1;
> #endif
This is, but there seems to be something more fundamental here. I'm
using the -aa patches, and the static int max_scsi_luns = 8; is actually
static int max_scsi_luns = MAX_SCSI_LUNS;
where above is: #define MAX_SCSI_LUNS 0xFFFFFFFF;
but I'm not sure if this syntax is 0xFFFFFFFF == 8 or 2^n.
To me, it seems like 8. I'm using pre10-aa2, I'm going to try pre10-aa4
as well, but if I must I'm going to hard-code the kernel bits I need I
supposed to make static int max_scsi_luns = MAX_SCSI_LUNS; into static
int max_scsi_luns = 16; to ensure it works at the level I need.
> This is the variable you seem to want.
>
> Note to SCSI maintainers. a quick vi `grep -l CONFIG_SCSI_MULTI_LUN`
> here reveals lots of hardcoded values of 8. It seems to me
> that perhaps a CONFIG_SCSI_MAX_LUN to replace
> CONFIG_SCSI_MULTI_LUN would be in order.
Agreed. I've always wondered why one cannot set this by hand, or even
simpler perhaps is a CONFIG_SCSI_MAX_LUN where values are set to one of
small, medium, large?
Thanks much J.W.
> ________________________________________________________________
> J.W. Schultz Pegasystems Technologies
> email address: [email protected]
>
> Remember Cernan and Schmitt
--
Austin Gonyou <[email protected]>
On Tue, Jun 25, 2002 at 10:05:39PM -0500, Austin Gonyou wrote:
> On Tue, 2002-06-25 at 21:48, jw schultz wrote:
> > I'm no expert on this bit but look in
> > drivers/scsi/scsi_scan.c for CONFIG_SCSI_MULTI_LUN
> >
> > #ifdef CONFIG_SCSI_MULTI_LUN
> > static int max_scsi_luns = 8;
> > #else
> > static int max_scsi_luns = 1;
> > #endif
>
> This is, but there seems to be something more fundamental here. I'm
> using the -aa patches, and the static int max_scsi_luns = 8; is actually
> static int max_scsi_luns = MAX_SCSI_LUNS;
>
> where above is: #define MAX_SCSI_LUNS 0xFFFFFFFF;
> but I'm not sure if this syntax is 0xFFFFFFFF == 8 or 2^n.
>
> To me, it seems like 8. I'm using pre10-aa2, I'm going to try pre10-aa4
> as well, but if I must I'm going to hard-code the kernel bits I need I
> supposed to make static int max_scsi_luns = MAX_SCSI_LUNS; into static
> int max_scsi_luns = 16; to ensure it works at the level I need.
>
I don't have -aa but that is -1. I would suggest a bit of
greping.
I seriously doubt changing it to 16 would cause data
corruption. It will either work or not. If it doesn't you
will crash on boot/init.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [email protected]
Remember Cernan and Schmitt
On Tue, 2002-06-25 at 22:47, jw schultz wrote:
...
> I don't have -aa but that is -1. I would suggest a bit of
> greping.
>
> I seriously doubt changing it to 16 would cause data
> corruption. It will either work or not. If it doesn't you
> will crash on boot/init.
>
yeah...I hear that. I tried some grepping, but didn't come up with much
since #define MAX_SCSI_LUNS 0xFFFFFFFF; replaced 8, and then it's seems
nothing like the mainline code, so it's much different.
If Andrea is listening, can you tell us if that's correct or not? Also,
it seems that passing max_scsi_luns=128 or even 10 or something at boot
time does not get parsed by scsi_mod, if CONFIG_SCSI=y.
Can someone shed some light on that?
>
> --
> ________________________________________________________________
> J.W. Schultz Pegasystems Technologies
> email address: [email protected]
>
> Remember Cernan and Schmitt
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Austin Gonyou <[email protected]>
Can someone tell me what I'm supposed to do to get a compiled in scsi
subsystem to recognize > 8 luns with 2.4.19-pre10-aa4?
I'm going to go to sleep for now, but if anyone can reply with some info
regarding this, I'd greatly appreciate it. I've got a TB size DB to
create tomorrow and I need all my luns. In the -aa kernel I was going to
go into drivers/scsi/hosts.c and modify max_lun = 8 to 16, recompile and
see what that does. If anyone could tell me I'm wrong or what I'd
appreciate that too. Ultimately, I'd like to know if the -aa series even
looks at max_scsi_luns=xxx at boot time at all when CONFIG_SCSI=y.
Thanks much.
--
Austin Gonyou <[email protected]>
Hi Austin,
enough guesses have been there not answering your questions ...
On Tue, Jun 25, 2002 at 07:46:25PM -0500, Austin Gonyou wrote:
> This originally was asking for help regarding QLA2200's, but I've since
> discovered it's a kernel param problem that I'm not sure how to solve.
>
> Using a default RH kernel (from SGI XFS installer) and passing
> max_scsi_luns=128 in grub, and for scsi_mod, it seems to work.
In 2.4.19pre1 a patch was merged into mainline which introduced a flag
BLIST_LARGELUN and set it for EMC Symmetrix devices. Some distributors
(incl. RH and SuSE) did ship kernels with this patch included.
http://van-dijk.net/linuxkernel/200206/0347.html
(An older patch for 2.4.16 exists as well.)
The flag does allow a device to use more than 8 LUNs despite it reporting
as SCSI Version 2 devices (which can not support more than 8 LUNs normally
...)
The flag also needs to be set for some more devices, look for DGC, DELL, CMD
and CNSi/CNSI devices that already have the BLIST_SPARSELUN flag.
But as you did not post the output of /proc/scsi/scsi nor the syslog
meesages from your SCSI subsystem nobody knows what devices you're using or
what actually happens. Just speculations ...
PS: The better list for such questions is [email protected]
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE Linux AG, Nuernberg, DE SCSI, Security
On Wed, 2002-06-26 at 07:33, Kurt Garloff wrote:
> Hi Austin,
>
> enough guesses have been there not answering your questions ...
Sure I hear that. But I posted an earlier question about QLA2200 and a
PV 660F and not seeing > 8 luns with 2.4.19-pre10.
> On Tue, Jun 25, 2002 at 07:46:25PM -0500, Austin Gonyou wrote:
> > This originally was asking for help regarding QLA2200's, but I've since
> > discovered it's a kernel param problem that I'm not sure how to solve.
> >
> > Using a default RH kernel (from SGI XFS installer) and passing
> > max_scsi_luns=128 in grub, and for scsi_mod, it seems to work.
>
> In 2.4.19pre1 a patch was merged into mainline which introduced a flag
> BLIST_LARGELUN and set it for EMC Symmetrix devices. Some distributors
> (incl. RH and SuSE) did ship kernels with this patch included.
> http://van-dijk.net/linuxkernel/200206/0347.html
> (An older patch for 2.4.16 exists as well.)
I'll take a look at that, and see if I can merge it into -aa4.
> The flag does allow a device to use more than 8 LUNs despite it reporting
> as SCSI Version 2 devices (which can not support more than 8 LUNs normally
> ...)
> The flag also needs to be set for some more devices, look for DGC, DELL, CMD
> and CNSi/CNSI devices that already have the BLIST_SPARSELUN flag.
This would be a DELL device, so I'll see about changing it from
SPARESLUN to LARGELUN?
> But as you did not post the output of /proc/scsi/scsi nor the syslog
> meesages from your SCSI subsystem nobody knows what devices you're using or
> what actually happens. Just speculations ...
There's nothing to post from /proc/scsi/scsi or the syslog other than
there's no more than 8 devices on my FC chain. I guess the real point
here is that if you're using FC, you're probably going to use more than
8 luns, even if not immediately. Especially for large Databases.
> PS: The better list for such questions is [email protected]
That makes sense I'll post to that list immediately and see what I can
get. Sorry for the confusion.
> Regards,
> --
> Kurt Garloff <[email protected]> Eindhoven, NL
> GPG key: See mail header, key servers Linux kernel development
> SuSE Linux AG, Nuernberg, DE SCSI, Security
--
Austin Gonyou <[email protected]>
On Wed, 2002-06-26 at 07:33, Kurt Garloff wrote:
> Hi Austin,
>
> enough guesses have been there not answering your questions ...
>
> On Tue, Jun 25, 2002 at 07:46:25PM -0500, Austin Gonyou wrote:
> > This originally was asking for help regarding QLA2200's, but I've since
> > discovered it's a kernel param problem that I'm not sure how to solve.
> >
> > Using a default RH kernel (from SGI XFS installer) and passing
> > max_scsi_luns=128 in grub, and for scsi_mod, it seems to work.
>
> In 2.4.19pre1 a patch was merged into mainline which introduced a flag
> BLIST_LARGELUN and set it for EMC Symmetrix devices. Some distributors
> (incl. RH and SuSE) did ship kernels with this patch included.
> http://van-dijk.net/linuxkernel/200206/0347.html
> (An older patch for 2.4.16 exists as well.)
Ahh...I see now. I looked for DELL in the scsi_scan.c and saw the
symmetrix there right above it. I should be able to add LARGELUN, since
it's #defined above and go for it. I'll see what this does, it's
starting to make sense now. TIA.
> The flag does allow a device to use more than 8 LUNs despite it reporting
> as SCSI Version 2 devices (which can not support more than 8 LUNs normally
> ...)
> The flag also needs to be set for some more devices, look for DGC, DELL, CMD
> and CNSi/CNSI devices that already have the BLIST_SPARSELUN flag.
>
> But as you did not post the output of /proc/scsi/scsi nor the syslog
> meesages from your SCSI subsystem nobody knows what devices you're using or
> what actually happens. Just speculations ...
>
> PS: The better list for such questions is [email protected]
>
> Regards,
> --
> Kurt Garloff <[email protected]> Eindhoven, NL
> GPG key: See mail header, key servers Linux kernel development
> SuSE Linux AG, Nuernberg, DE SCSI, Security
--
Austin Gonyou <[email protected]>
Hi Austin,
On Wed, Jun 26, 2002 at 09:18:45AM -0500, Austin Gonyou wrote:
> On Wed, 2002-06-26 at 07:33, Kurt Garloff wrote:
> > enough guesses have been there not answering your questions ...
>
> Sure I hear that. But I posted an earlier question about QLA2200 and a
You don't think that somebody who reads your message and tries to post a
helpful comment scans the list for earlier messages of yours, do you?
> PV 660F and not seeing > 8 luns with 2.4.19-pre10.
^^^^^^^
This device needs BLIST_LARGELUN.
> I'll take a look at that, and see if I can merge it into -aa4.
The patch should be in there, just not the additional devices that need
BLIST_LARGELUN.
> > The flag does allow a device to use more than 8 LUNs despite it reporting
> > as SCSI Version 2 devices (which can not support more than 8 LUNs normally
> > ...)
> > The flag also needs to be set for some more devices, look for DGC, DELL, CMD
> > and CNSi/CNSI devices that already have the BLIST_SPARSELUN flag.
>
> This would be a DELL device, so I'll see about changing it from
> SPARESLUN to LARGELUN?
No. Add " | BLIST_LARGELUN" .
> > But as you did not post the output of /proc/scsi/scsi nor the syslog
> > meesages from your SCSI subsystem nobody knows what devices you're using or
> > what actually happens. Just speculations ...
>
> There's nothing to post from /proc/scsi/scsi or the syslog other than
> there's no more than 8 devices on my FC chain. I guess the real point
> here is that if you're using FC, you're probably going to use more than
> 8 luns, even if not immediately. Especially for large Databases.
People could have seen what SCSI device you're using.
So I could have told you instead of guessing and risking to add to the noise
myself.
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE Linux AG, Nuernberg, DE SCSI, Security
On Wed, 2002-06-26 at 11:07, Kurt Garloff wrote:
> Hi Austin,
>
> On Wed, Jun 26, 2002 at 09:18:45AM -0500, Austin Gonyou wrote:
> > On Wed, 2002-06-26 at 07:33, Kurt Garloff wrote:
> > > enough guesses have been there not answering your questions ...
> >
> > Sure I hear that. But I posted an earlier question about QLA2200 and a
>
> You don't think that somebody who reads your message and tries to post a
> helpful comment scans the list for earlier messages of yours, do you?
>
Well, I do, especially if someone says it's an urgent thing to try and
get the whole story. If I don't have time, I'll ask someone to give more
info, which you did and I respect that and thank you.
> > PV 660F and not seeing > 8 luns with 2.4.19-pre10.
> ^^^^^^^
>
> This device needs BLIST_LARGELUN.
I got that from your earlier post and addressed it directly. Thanks for
the pointer. I didn't know the 660 was defined explicitly in the
scsi_scan.c I've since recompiled several kernel versions to assert this
as being true with the BLIST_LARGELUN option and it's definitely fixed
my problems there.
> > I'll take a look at that, and see if I can merge it into -aa4.
>
> The patch should be in there, just not the additional devices that need
> BLIST_LARGELUN.
>
> > > The flag does allow a device to use more than 8 LUNs despite it reporting
> > > as SCSI Version 2 devices (which can not support more than 8 LUNs normally
> > > ...)
> > > The flag also needs to be set for some more devices, look for DGC, DELL, CMD
> > > and CNSi/CNSI devices that already have the BLIST_SPARSELUN flag.
> >
> > This would be a DELL device, so I'll see about changing it from
> > SPARESLUN to LARGELUN?
>
> No. Add " | BLIST_LARGELUN" .
Yep, Did that. Again Thanks!
> > > But as you did not post the output of /proc/scsi/scsi nor the syslog
> > > meesages from your SCSI subsystem nobody knows what devices you're using or
> > > what actually happens. Just speculations ...
> >
> > There's nothing to post from /proc/scsi/scsi or the syslog other than
> > there's no more than 8 devices on my FC chain. I guess the real point
> > here is that if you're using FC, you're probably going to use more than
> > 8 luns, even if not immediately. Especially for large Databases.
>
> People could have seen what SCSI device you're using.
> So I could have told you instead of guessing and risking to add to the noise
> myself.
I hear you loud and clear. I wouldn't have made so much noise myself had
it not been a *top* priority item that I couldn't find info on anywhere
else, plus the boss putting pressure too. Soon, this system will be a
6650 with PV 660F, 8GB RAM, using Linux with Oracle8.1.7.2, XFS, 0(1)
scheduler and nearly a TB of total DB.
I have some results from my benchmarking which are quite astounding too.
> Regards,
> --
> Kurt Garloff <[email protected]> Eindhoven, NL
> GPG key: See mail header, key servers Linux kernel development
> SuSE Linux AG, Nuernberg, DE SCSI, Security
--
Austin Gonyou <[email protected]>