RE: Why are MegaRAID drivers mutually exclusive?

RE: Why are MegaRAID drivers mutually exclusive?

[Bagalkote, Sreenivas]

The new and old drivers are mutually exclusive to the extent that
both cannot be loaded simultaneously as they both work on same
hardware. It only seems logical that this exclusivity is represented
in Kconfig as well.

Thanks,
Sreenivas 
LSI Logic

>-----Original Message-----
>From: Chris Adams [mailto:cmadams@hiwaay.net] 
>Sent: Wednesday, November 10, 2004 12:05 PM
>To: linux-scsi@vger.kernel.org
>Subject: Why are MegaRAID drivers mutually exclusive?
>
>I've got some systems that need the old megaraid driver with 
>Fedora Core 3, however it isn't being built.  Looking at 
>Kconfig.megaraid, I see that the new and old drivers are 
>mutually exclusive?  Is there a reason for that?  It means 
>that packagers can't build both as modules.
>
>Is there a good reason not to do:
>
>diff -urN 
>linux-2.6.9-dist/drivers/scsi/megaraid/Kconfig.megaraid 
>linux-2.6.9/drivers/scsi/megaraid/Kconfig.megaraid
>--- linux-2.6.9-dist/drivers/scsi/megaraid/Kconfig.megaraid	
>2004-10-18 16:53:22.000000000 -0500
>+++ linux-2.6.9/drivers/scsi/megaraid/Kconfig.megaraid	
>2004-11-10 10:33:26.748570929 -0600
>@@ -63,7 +63,6 @@
> 	To compile this driver as a module, choose M here: the
> 	module will be called megaraid_mbox
> 
>-if MEGARAID_NEWGEN=n
> config MEGARAID_LEGACY
> 	tristate "LSI Logic Legacy MegaRAID Driver"
> 	depends on PCI && SCSI
>@@ -74,4 +73,3 @@
> 
> 	To compile this driver as a module, choose M here: the
> 	module will be called megaraid
>-endif
>
>
>I looked in MAINTAINERS, CREDITS, megaraid.txt, and 
>ChangeLog.megaraid, but I didn't see that there was any more 
>specific list to use for the megaraid driver (other than three 
>author addresses listed in megaraid_mbox.c).
>
>--
>Chris Adams <cmadams@hiwaay.net>
>Systems and Network Administrator - HiWAAY Internet Services I 
>don't speak for anybody but myself - that's enough trouble.
>-
>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: Why are MegaRAID drivers mutually exclusive?

[Chris Adams]

Once upon a time, Bagalkote, Sreenivas <sreenib@lsil.com> said:
> The new and old drivers are mutually exclusive to the extent that
> both cannot be loaded simultaneously as they both work on same
> hardware. It only seems logical that this exclusivity is represented
> in Kconfig as well.

That then means they cannot be both built as modules, which is a valid
configuration, because then you can choose to either load the old or new
driver at module load time (and even switch between the two drivers
without having the reconfigure and rebuild the kernel).

They don't both work on the same hardware either; that is the source of
the problem.  megaraid_mbox works on a subset of hardware that megaraid
works on.
-- 
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: Why are MegaRAID drivers mutually exclusive?

[Matt Domsch]

On Wed, Nov 10, 2004 at 02:24:06PM -0500, Bagalkote, Sreenivas wrote:
> The new and old drivers are mutually exclusive to the extent that
> both cannot be loaded simultaneously as they both work on same
> hardware. It only seems logical that this exclusivity is represented
> in Kconfig as well.

There are three issues here that need to be addressed.
1) megaraid_mbox doesn't currently handle all of Chris's hardware.
   It's missing some PCI IDs which it should be able to handle.
   101e:1960 101e:0475, aka PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID3
			    PCI_DEVICE_ID_AMI, PCI_SUBSYS_ID_PERC3_SC 

2) megaraid_mbox doesn't handle other sets of hardware it should be
   able to handle (Dell PERC2/{SC,DC}).  I am not sure why.

3) no megaraid_ioport driver has ever been produced, which was the
   original reason for splitting megaraid_mm and megaraid_mbox.  This
   driver is necessary for Chris's other older hardware.
   PCI 101e:9010, aka PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_MEGARAID


Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

RE: Why are MegaRAID drivers mutually exclusive?

[Mukker, Atul]

> How about you remove all the PCI IDs from the 2.00.3 driver 
> that the 2.20 driver handles, so that they're mutually 
> exclusive again?
That's a good suggestion, but still wouldn't take care of the 'apps do not
work with multiple drivers concern'. One conceivable option, and this is
just a suggestion :-), is to actually write a megaraid_{ioport|legacy}
driver as suggested by you earlier and let it stack under 2.20 mgmt module
and remove the legacy driver completely from the kernel. Hmm...

Thanks
-Atul Mukker

RE: Why are MegaRAID drivers mutually exclusive?

[Mukker, Atul]

> There are three issues here that need to be addressed.
> 1) megaraid_mbox doesn't currently handle all of Chris's hardware.
>    It's missing some PCI IDs which it should be able to handle.
>    101e:1960 101e:0475, aka PCI_VENDOR_ID_AMI, 
> PCI_DEVICE_ID_AMI_MEGARAID3
> 			    PCI_DEVICE_ID_AMI, PCI_SUBSYS_ID_PERC3_SC 

Initial idea was to support only the newest U320 controllers on the 2.20
stack because these controllers are heavily tested in LSI labs with the 2.20
driver. For older controllers, we recommended to use legacy drivers.  We
agreed to add the Dell's branded PERC3s since there is a lot of value in
that generation of controllers. We agree to add the support for AMI branded
475/493/471 as well now. There should be patch from Sreenivas soon for this.

> 
> 2) megaraid_mbox doesn't handle other sets of hardware it should be
>    able to handle (Dell PERC2/{SC,DC}).  I am not sure why.

Same reason. The bottom-line for any controllers to be supported on this
stack was, it should be actively tested in LSI labs. Other main reason not
to support these controller is their lack of capability to do 64-bit DMA.

> 
> 3) no megaraid_ioport driver has ever been produced, which was the
>    original reason for splitting megaraid_mm and megaraid_mbox.  This
>    driver is necessary for Chris's other older hardware.
>    PCI 101e:9010, aka PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_MEGARAID
> 
This is not entirely correct. We initially planned to have SAS RAID drivers
under the 2.20 umbrella, not IO based controllers.

Now coming back to the original question of non-flexibility of having both
drivers:

We do not want to have someone configure both drivers to load since legacy
megaraid not only supports the older controllers, it _can_ take ownership of
the newer ones as well, causing 2.20 to fail to load for those controllers.
Also, management applications are written with a view of only one driver
concept. These cannot interface with 2 drivers. So, in order to force one
driver - Kconfig is written in this particular way.

Now, this can be easily changed, and we are definitely flexible to let user
compile both drivers. This should work as long as user makes sure to load
-_only one_ of these at any time. (suggestions?)

Thanks
-Atul Mukker

Re: Why are MegaRAID drivers mutually exclusive?

[Matt Domsch]

On Wed, Nov 10, 2004 at 04:25:14PM -0500, Mukker, Atul wrote:
> >    original reason for splitting megaraid_mm and megaraid_mbox.  This
> >    driver is necessary for Chris's other older hardware.
> >    PCI 101e:9010, aka PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_MEGARAID
> > 
> This is not entirely correct. We initially planned to have SAS RAID drivers
> under the 2.20 umbrella, not IO based controllers.

I stand corrected, thanks.

 
> Now coming back to the original question of non-flexibility of having both
> drivers:
> 
> We do not want to have someone configure both drivers to load since legacy
> megaraid not only supports the older controllers, it _can_ take ownership of
> the newer ones as well, causing 2.20 to fail to load for those controllers.
> Also, management applications are written with a view of only one driver
> concept. These cannot interface with 2 drivers. So, in order to force one
> driver - Kconfig is written in this particular way.
> 
> Now, this can be easily changed, and we are definitely flexible to let user
> compile both drivers. This should work as long as user makes sure to load
> -_only one_ of these at any time. (suggestions?)

How about you remove all the PCI IDs from the 2.00.3 driver that the
2.20 driver handles, so that they're mutually exclusive again?

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

Re: Why are MegaRAID drivers mutually exclusive?

[Arjan van de Ven]

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

On Wed, 2004-11-10 at 16:08 -0600, Matt Domsch wrote:

> How about you remove all the PCI IDs from the 2.00.3 driver that the
> 2.20 driver handles, so that they're mutually exclusive again?

Are they mutually exclusive in other places too? (eg in the /proc stuff
it creates... well I guess the new driver only does (or should do) sysfs
of course)


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Why are MegaRAID drivers mutually exclusive?

[Chris Adams]

Once upon a time, Arjan van de Ven <arjanv@redhat.com> said:
> On Wed, 2004-11-10 at 16:08 -0600, Matt Domsch wrote:
> > How about you remove all the PCI IDs from the 2.00.3 driver that the
> > 2.20 driver handles, so that they're mutually exclusive again?
> 
> Are they mutually exclusive in other places too? (eg in the /proc stuff
> it creates... well I guess the new driver only does (or should do) sysfs
> of course)

It looks like the only place they overlap is in the device node.

I don't see this as being all that different from when there were
multiple sym53c8xx SCSI or tulip network drivers in the kernel.
-- 
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: Why are MegaRAID drivers mutually exclusive?

[Arjan van de Ven]

> It looks like the only place they overlap is in the device node.
> 
> I don't see this as being all that different from when there were
> multiple sym53c8xx SCSI or tulip network drivers in the kernel.

the difference is that in those situations the new driver supported all
old hw too; while here... well.. you legitamitly can have an old and new
megaraid card in the same server (say you had two and one got replaced 2
years later)
-- 

Re: Why are MegaRAID drivers mutually exclusive?

[Chris Adams]

Once upon a time, Arjan van de Ven <arjan@infradead.org> said:
> > I don't see this as being all that different from when there were
> > multiple sym53c8xx SCSI or tulip network drivers in the kernel.
> 
> the difference is that in those situations the new driver supported all
> old hw too; while here... well.. you legitamitly can have an old and new
> megaraid card in the same server (say you had two and one got replaced 2
> years later)

Then you use the old driver.  If you have an old card, you will be using
the old driver anyway; it should just keep working.

This would be an argument for not removing PCI IDs from the old driver;
leave it working for all cards (so if you have any combination of cards
that includes a card not supported by the new driver, you use the old
driver and only the old driver to run them all).
-- 
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: Why are MegaRAID drivers mutually exclusive?

[Arjan van de Ven]

On Thu, 2004-11-11 at 08:31 -0600, Chris Adams wrote:
> Once upon a time, Arjan van de Ven <arjan@infradead.org> said:
> > > I don't see this as being all that different from when there were
> > > multiple sym53c8xx SCSI or tulip network drivers in the kernel.
> > 
> > the difference is that in those situations the new driver supported all
> > old hw too; while here... well.. you legitamitly can have an old and new
> > megaraid card in the same server (say you had two and one got replaced 2
> > years later)
> 
> Then you use the old driver.  If you have an old card, you will be using
> the old driver anyway; it should just keep working.

but then the new controller doesn't work. because for that one you need
the new driver.

Re: Why are MegaRAID drivers mutually exclusive?

[Chris Adams]

Once upon a time, Arjan van de Ven <arjan@infradead.org> said:
> On Thu, 2004-11-11 at 08:31 -0600, Chris Adams wrote:
> > Once upon a time, Arjan van de Ven <arjan@infradead.org> said:
> > > the difference is that in those situations the new driver supported all
> > > old hw too; while here... well.. you legitamitly can have an old and new
> > > megaraid card in the same server (say you had two and one got replaced 2
> > > years later)
> > 
> > Then you use the old driver.  If you have an old card, you will be using
> > the old driver anyway; it should just keep working.
> 
> but then the new controller doesn't work. because for that one you need
> the new driver.

Currently, the old driver works for all cards, old and new.  Someone has
suggested removing the PCI IDs that the new driver handles from the old
driver; if that is _not_ done, the old driver will continue to work for
all cards, old and new.

-- 
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: Why are MegaRAID drivers mutually exclusive?

[Xose Vazquez Perez]

Chris Adams wrote:

> I've got some systems that need the old megaraid driver with Fedora Core
> 3, however it isn't being built.

drivers/scsi/megaraid.c is _not_ maintained by LSI !!

-- 
TLOZ OOT: worse than drugs.

Why are MegaRAID drivers mutually exclusive?

[Chris Adams]

I've got some systems that need the old megaraid driver with Fedora Core
3, however it isn't being built.  Looking at Kconfig.megaraid, I see
that the new and old drivers are mutually exclusive?  Is there a reason
for that?  It means that packagers can't build both as modules.

Is there a good reason not to do:

diff -urN linux-2.6.9-dist/drivers/scsi/megaraid/Kconfig.megaraid linux-2.6.9/drivers/scsi/megaraid/Kconfig.megaraid
--- linux-2.6.9-dist/drivers/scsi/megaraid/Kconfig.megaraid	2004-10-18 16:53:22.000000000 -0500
+++ linux-2.6.9/drivers/scsi/megaraid/Kconfig.megaraid	2004-11-10 10:33:26.748570929 -0600
@@ -63,7 +63,6 @@
 	To compile this driver as a module, choose M here: the
 	module will be called megaraid_mbox
 
-if MEGARAID_NEWGEN=n
 config MEGARAID_LEGACY
 	tristate "LSI Logic Legacy MegaRAID Driver"
 	depends on PCI && SCSI
@@ -74,4 +73,3 @@
 
 	To compile this driver as a module, choose M here: the
 	module will be called megaraid
-endif


I looked in MAINTAINERS, CREDITS, megaraid.txt, and ChangeLog.megaraid,
but I didn't see that there was any more specific list to use for the
megaraid driver (other than three author addresses listed in
megaraid_mbox.c).

-- 
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.