Hello,
I've noticed that since recent kernel versions, it's not possible
anymore to use simultaneously new and old megaraid driver.
It seems to have been introduced by that changeset:
http://linux.bkbits.net:8080/linux-2.5/diffs/drivers/scsi/megaraid/[email protected]??nav=index.html|src/.|src/drivers|src/drivers/scsi|src/drivers/scsi/megaraid|hist/drivers/scsi/megaraid/Kconfig.megaraid
It particularly makes life of people developing kernel for distro
difficult as it forces them to drop support for legacy hardware which is
working just fine with 2.6, or to patch their own kernel build.
As well it prevents simultaneous usage of new and old cards in the same
system.
Would you consider to apply the following patch proposed by Thierry
Vignaud as a solution for the MandrakeSoft kernel in the mainstream 2.6
kernel ?
Thanks in advance,
Bruno.
--- ./drivers/scsi/megaraid/Kconfig.megaraid 2005-03-02
08:37:49.000000000 +0100
+++ ./drivers/scsi/megaraid/Kconfig.megaraid 2005-03-25
18:36:37.809994244 +0100
@@ -64,7 +64,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
@@ -75,4 +74,3 @@
To compile this driver as a module, choose M here: the
module will be called megaraid
-endif
--
Linux Solution Consultant / Open Source Evangelist \ HP C&I EMEA ISG
HP/Intel Solution Center http://hpintelco.net Hewlett-Packard Grenoble/France
Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux
La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org
On Fri, 2005-03-25 at 19:22 +0100, Bruno Cornec wrote:
> Would you consider to apply the following patch proposed by Thierry
> Vignaud as a solution for the MandrakeSoft kernel in the mainstream 2.6
> kernel ?
Well, to be considered you'd need to cc the megaraid maintainers and the
linux-scsi mailing list.
> -if MEGARAID_NEWGEN=n
No, this is wrong it would break allyes configs and I'd get shot.
James
On Fri, Mar 25, 2005 at 12:39:52PM -0600, James Bottomley wrote:
> On Fri, 2005-03-25 at 19:22 +0100, Bruno Cornec wrote:
> > Would you consider to apply the following patch proposed by Thierry
> > Vignaud as a solution for the MandrakeSoft kernel in the mainstream 2.6
> > kernel ?
>
> Well, to be considered you'd need to cc the megaraid maintainers and the
> linux-scsi mailing list.
>
> > -if MEGARAID_NEWGEN=n
>
> No, this is wrong it would break allyes configs and I'd get shot.
Why? The megaraid drivers shouldn't have any conflicting non-static
symbols
On Fri, 2005-03-25 at 18:47 +0000, Christoph Hellwig wrote:
> On Fri, Mar 25, 2005 at 12:39:52PM -0600, James Bottomley wrote:
> > On Fri, 2005-03-25 at 19:22 +0100, Bruno Cornec wrote:
> > > Would you consider to apply the following patch proposed by Thierry
> > > Vignaud as a solution for the MandrakeSoft kernel in the mainstream 2.6
> > > kernel ?
> >
> > Well, to be considered you'd need to cc the megaraid maintainers and the
> > linux-scsi mailing list.
> >
> > > -if MEGARAID_NEWGEN=n
> >
> > No, this is wrong it would break allyes configs and I'd get shot.
>
> Why? The megaraid drivers shouldn't have any conflicting non-static
> symbols
You get a kernel with two drivers trying to claim some of the same set
of cards. The winner will be the driver that gets its init routines
called first, but this isn't a desirable outcome.
I wouldn't object to a patch that allows both *modules* to be built,
which is all I think the distros are after.
James
On Fri, Mar 25, 2005 at 01:04:37PM -0600, James Bottomley wrote:
> You get a kernel with two drivers trying to claim some of the same set
> of cards. The winner will be the driver that gets its init routines
> called first, but this isn't a desirable outcome.
>
> I wouldn't object to a patch that allows both *modules* to be built,
> which is all I think the distros are after.
The new megaraid driver doesn't support old hardware. Maybe we should
drop the overlapping pci ids from the old driver?
Can someone please remove me from these mailing lists?
I don't remember signing up ffor them and it's filling
my inbox too quickly.
On Fri, 25 Mar 2005, Christoph Hellwig wrote:
> On Fri, Mar 25, 2005 at 01:04:37PM -0600, James Bottomley wrote:
>> You get a kernel with two drivers trying to claim some of the same set
>> of cards. The winner will be the driver that gets its init routines
>> called first, but this isn't a desirable outcome.
>>
>> I wouldn't object to a patch that allows both *modules* to be built,
>> which is all I think the distros are after.
>
> The new megaraid driver doesn't support old hardware. Maybe we should
> drop the overlapping pci ids from the old driver?
>
> -
> 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/
>
>
On Fri, 2005-03-25 at 19:07 +0000, Christoph Hellwig wrote:
> The new megaraid driver doesn't support old hardware. Maybe we should
> drop the overlapping pci ids from the old driver?
That works for me too ... but the people who get to decide what to do
should be the driver maintainers.
James
Hello,
After a first attempt of discussion on lkml, I'd like to get your
feedback on the following points.
I've noticed that since recent kernel versions, it's not possible
anymore to use simultaneously new and old megaraid driver.
It seems to have been introduced by that changeset:
http://linux.bkbits.net:8080/linux-2.5/diffs/drivers/scsi/megaraid/Kconfig.megar
[email protected]??nav=index.html|src/.|src/drivers|src/drivers/scsi|src/drivers/scsi/mega
raid|hist/drivers/scsi/megaraid/Kconfig.megaraid
It particularly makes life of people developing kernel for distro
difficult as it forces them to drop support for legacy hardware which is
working just fine with 2.6, or to patch their own kernel build.
As well it prevents simultaneous usage of new and old cards in the same
system.
As notes by James Bottomley and Christoph Hellwig the best thing to do
is probably to remove support for cards in the old driver that are still
supported by the new driver.
I'd like to propose a patch but looking at the code I have the following
question: the card id 101E:1960 seems to be supported by the new driver
as per the header of megaraid_mbox.c but in reality I was unable to boot
my system which uses that precise card with the new driver.
Are they mistakes in the header file ? Should they be removed from the
new driver (if they don't work) or from the old if they work ?
My current status is the following (just for discussion)
diff -Nru drivers/scsi/megaraid/Kconfig.megaraid
drivers.new/scsi/megaraid/Kconfig.megaraid
--- drivers/scsi/megaraid/Kconfig.megaraid Fri Mar 25 20:34:06 2005
+++ drivers.new/scsi/megaraid/Kconfig.megaraid Fri Mar 25 20:53:37 2005
@@ -64,15 +64,12 @@
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
help
This driver supports the LSI MegaRAID 418, 428, 438, 466, 762,
490
- and 467 SCSI host adapters. This driver also support the all
U320
- RAID controllers
+ and 467 SCSI host adapters.
To compile this driver as a module, choose M here: the
module will be called megaraid
-endif
diff -Nru drivers/scsi/megaraid.c drivers.new/scsi/megaraid.c
--- drivers/scsi/megaraid.c Fri Mar 25 20:28:29 2005
+++ drivers.new/scsi/megaraid.c Fri Mar 25 20:57:25 2005
@@ -5033,12 +5033,6 @@
}
static struct pci_device_id megaraid_pci_tbl[] = {
- {PCI_VENDOR_ID_DELL, PCI_DEVICE_ID_DISCOVERY,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {PCI_VENDOR_ID_DELL, PCI_DEVICE_ID_PERC4_DI,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, BOARD_64BIT},
- {PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_PERC4_QC_VERDE,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, BOARD_64BIT},
{PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID2,
diff -Nru drivers/scsi/megaraid.h drivers.new/scsi/megaraid.h
--- drivers/scsi/megaraid.h Fri Mar 25 20:28:25 2005
+++ drivers.new/scsi/megaraid.h Fri Mar 25 20:57:03 2005
@@ -73,10 +73,6 @@
#define PCI_DEVICE_ID_AMI_MEGARAID3 0x1960
#endif
-#define PCI_DEVICE_ID_DISCOVERY 0x000E
-#define PCI_DEVICE_ID_PERC4_DI 0x000F
-#define PCI_DEVICE_ID_PERC4_QC_VERDE 0x0407
-
/* Sub-System Vendor IDs */
#define AMI_SUBSYS_VID 0x101E
#define DELL_SUBSYS_VID 0x1028
--
Linux Solution Consultant / Open Source Evangelist \ HP C&I EMEA ISG
HP/Intel Solution Center http://hpintelco.net Hewlett-Packard Grenoble/France
Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux
La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org
James Bottomley <[email protected]> writes:
> > > > Would you consider to apply the following patch proposed by
> > > > Thierry Vignaud as a solution for the MandrakeSoft kernel in
> > > > the mainstream 2.6 kernel ?
> > >
> > > Well, to be considered you'd need to cc the megaraid maintainers
> > > and the linux-scsi mailing list.
> > >
> > > > -if MEGARAID_NEWGEN=n
> > >
> > > No, this is wrong it would break allyes configs and I'd get shot.
> >
> > Why? The megaraid drivers shouldn't have any conflicting
> > non-static symbols
>
> You get a kernel with two drivers trying to claim some of the same
> set of cards. The winner will be the driver that gets its init
> routines called first, but this isn't a desirable outcome.
well, this is not the first occurence:
- one can build both oss and alsa drivers which claimed quite the same
ids set.
eg, one example from modules.pcimap:
snd-intel8x0 0x00001039 0x00007012 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0
i810_audio 0x00001039 0x00007012 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0
- at one point, atiixp and sata_sil used to overlap on one sata
controller
- tg3 and bcm5700 totally overlap
- the same for e100 and eepro100, e1000 and eepro1000
- sata drivers ahci and ata_piix used to overlap too on a cople of
devices
- b44 and bcm4400 totally overlap
- 8139too and 8139cp overlap
- i2c-ali15x3 and i2c-ali1535 overlap too
- qla6322 and qla6312 used to overlap in the past
- via-ircc and i2c-viapro overlaps
- dvb
- saa7134 and saa7134-dvb overlap
- sonypi and i2c-piix4 overlap
- cx88 and cx88-dvb overlap
- radio-gemtek-pci and radio-maxiradio overlap too
- ...
so this argument looks totally bogus for me since few of these drivers
prevent them being build in-core at both time b/c there're quite a lot
of other driver that will "break" allyes configs
> I wouldn't object to a patch that allows both *modules* to be built,
> which is all I think the distros are after.
indeed. but the first patch should have been accpeted as this.
the in fact policy isn't currently to prevent overlapping drivers to
being compiled in-core at the same time, so i think we shouldn't
prevent it but convert all these drivers' build rules so that they
allow to be built as modules at the same time, but not in core at the
same time
> - tg3 and bcm5700 totally overlap
bcm5700 isn't in the tree.
> - the same for e100 and eepro100, e1000 and eepro1000
there's no eepro1000
> - sata drivers ahci and ata_piix used to overlap too on a cople of
> devices
> - b44 and bcm4400 totally overlap
bcm4000 isn't in the tree