RE: [PATCH][BUGFIX] : megaraid patch for 2.10.1 (irq disable bug fix)

RE: [PATCH][BUGFIX] : megaraid patch for 2.10.1 (irq disable bug fix)

[Mukker, Atul]

> > controllers and also a single code base, with a very small 
> footprint patch -
> > if at all required, to support various kernels.
> 
> I didn't say "no".  I'm just warning you that you've chosen a 
> hard road
> to hoe, particularly with the limited life of 2.4.

In my opinion, maintaining support for 2.4 drivers and adding new
controllers to it would be crucial for a considerable time to come even
while lk 2.6 becomes mainstream. As support, we would want to provide
support for as many kernels and controllers as possible.

>From a developer standpoint, It is very difficult to maintain two drivers. I
am willing to fork iff the code is too hairy - but right now it seems very
manageable.

> "An important MegaRAID feature is to be able to boot from any logical
> drive on
> If you require this functionality in 2.6, you should look at plugging
> into the udev infrastructure.

Now, this is some new information for me. I am not sure what is Dell's stand
on this option. Matt, Arjan?

Do we want to discover controllers and devices directed solely by kernel and
should driver interfere a little bit.

> This is unacceptable:
> 
> #if defined (__x86_64__)
> 		/*
> 		 * Register the 32-bit ioctl conversion
> 		 */
> 		register_ioctl32_conversion(MEGAIOCCMD, sys_ioctl)
> #endif
Ok.. Let us find a better solution. 

Re: [PATCH][BUGFIX] : megaraid patch for 2.10.1 (irq disable bug fix)

[Arjan van de Ven]

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

On Tue, Feb 24, 2004 at 04:02:34PM -0500, Mukker, Atul wrote:
> > > controllers and also a single code base, with a very small 
> > footprint patch -
> > > if at all required, to support various kernels.
> > 
> > I didn't say "no".  I'm just warning you that you've chosen a 
> > hard road
> > to hoe, particularly with the limited life of 2.4.
> 
> In my opinion, maintaining support for 2.4 drivers and adding new
> controllers to it would be crucial for a considerable time to come even

there is a difference between just adding a pci id and adding all new
features.

> Do we want to discover controllers and devices directed solely by kernel and
> should driver interfere a little bit.

I always considered the megaraid code here extremely hairy... I'd love to
see it go when we can 

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

RE: [PATCH][BUGFIX] : megaraid patch for 2.10.1 (irq disable bug fix)

[Mukker, Atul]

> 
> I really don't think this will be such a good idea since you don't
> currently have a unified driver.  2.4 is approaching end of 
> life as far
> as major driver updates go and the 2.6 APIs are quite a bit 
> different. 
> You'll find it's a lot of work for a driver that will carry 
> you at most
> six months before the distributions all switch to 2.6 and you find the
> 2.4 compatibility layer to be more of a hindrance than a help.

Wow! That's a lot of no-no. But we'll let the code speak for itself. The
major driving force behind the unified design is support for MPT raid
controllers and also a single code base, with a very small footprint patch -
if at all required, to support various kernels.

In this driver, the base kernel is assumed to be a lk 2.6.x with appropriate
APIs added for lk 2.4.x.

I recommend reading the concise design document, mraid_hotplug.doc, which
explains the overall layout of the driver and some design concerns. This
document is part of the driver package.

Obviously we are open to all suggestions and ready to modify the code if
there is a general feeling in that direction. Also, this driver would
required to sit in a directory because of a split in files

The driver package is available in usual location, too big to be inlined :-)
ftp://ftp.lsil.com/pub/linux-megaraid/drivers/version-unified-2.20.0.0.02.24
.2004-alpha1/


Enjoy!

Best Regards
-Atul Mukker
LSI Logic Corporation

RE: [PATCH][BUGFIX] : megaraid patch for 2.10.1 (irq disable bug fix)

[James Bottomley]

On Tue, 2004-02-24 at 10:04, Mukker, Atul wrote:
> Wow! That's a lot of no-no. But we'll let the code speak for itself. The
> major driving force behind the unified design is support for MPT raid
> controllers and also a single code base, with a very small footprint patch -
> if at all required, to support various kernels.

I didn't say "no".  I'm just warning you that you've chosen a hard road
to hoe, particularly with the limited life of 2.4.

> In this driver, the base kernel is assumed to be a lk 2.6.x with appropriate
> APIs added for lk 2.4.x.
> 
> I recommend reading the concise design document, mraid_hotplug.doc, which
> explains the overall layout of the driver and some design concerns. This
> document is part of the driver package.

OK, I read it.

This is worrying:

"Even though the use of pure hotplug APIs is very appealing, I want to
propose
some deviation from this approach. If drivers rely on the PCI framework
to
discover adapters, we lose flexibility of registering controllers in a
particular order with the operating system."

Anything relying on discovery ordering in 2.6 is broken.

And so is this:

"An important MegaRAID feature is to be able to boot from any logical
drive on
any controller. Since persistent device naming is not prevalent in Linux
world
as of this writing, the order in which the devices are discovered is
very
important. We would like to continue to give users flexibility to
designate
any logical drive on any controller as the boot drive. As long as the
BIOS on
this controller is enabled, and only on this one :-), the chosen disk
would be
exported to the OS before any other disk."

If you require this functionality in 2.6, you should look at plugging
into the udev infrastructure.

> Obviously we are open to all suggestions and ready to modify the code if
> there is a general feeling in that direction. Also, this driver would
> required to sit in a directory because of a split in files

Well, I cast a brief glance over it, the #ifdef structure is horrible
(and basically a product of trying to support 2.4).

This is unacceptable:

#if defined (__x86_64__)
		/*
		 * Register the 32-bit ioctl conversion
		 */
		register_ioctl32_conversion(MEGAIOCCMD, sys_ioctl)
#endif

The best thing to do would be to design the API to be 32/64 agnostic,
but if you can't do that, at least use the CONFIG_COMPAT infrastructure
that already exists.

James

Re: [PATCH][BUGFIX] : megaraid patch for 2.10.1 (irq disable bug fix)

[Christoph Hellwig]

On Tue, Feb 24, 2004 at 11:04:21AM -0500, Mukker, Atul wrote:
> The driver package is available in usual location, too big to be inlined :-)
> ftp://ftp.lsil.com/pub/linux-megaraid/drivers/version-unified-2.20.0.0.02.24
> .2004-alpha1/

James already mentioned the probing issue and looking further through the
driver there's lots of need for improvement.  I think we should try to get
2.6 merged up with all the changes from the last unified driver and additional
fixes posted to the list (e.g. the dma_sync thing, did you have a chance to
look at it?) so that we have a proben base until we look into it.

P.S. from  a sort look the fusion-based adapters seem to be completely
different from existing megaraid adapters.  What non-trivial code is
actually shared?

RE: [PATCH][BUGFIX] : megaraid patch for 2.10.1 (irq disable bug fix)

[Mukker, Atul]

> >> The following patch fixes a bug in megaraid driver version 2.10.1
> >> where irq was erroneously being disabled.
> >
> > Could we have a later version than 2.00.3 in 2.6 please?
We are in process of releasing a unified driver, which will natively support
the 2.4.x and 2.6.x kernels. 

Thanks
-Atul Mukker

Re: [PATCH][BUGFIX] : megaraid patch for 2.10.1 (irq disable bug fix)

[Matthew Wilcox]

On Tue, Feb 24, 2004 at 09:47:06AM -0500, Mukker, Atul wrote:
> > > Could we have a later version than 2.00.3 in 2.6 please?
> We are in process of releasing a unified driver, which will natively support
> the 2.4.x and 2.6.x kernels. 

In the past, this has generally been a very bad idea.  It's led to some
excessively ugly drivers (see aic7xxx for one) and generally doesn't work
terribly well.  If you insist on going down this road, could you at least
make sure it's written to the newest 2.6 APIs and every other supported
kernel version emulates the 2.6 APIs?  The awful "kernel neutral API"s
used in some drivers really suck.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

RE: [PATCH][BUGFIX] : megaraid patch for 2.10.1 (irq disable bug fix)

[James Bottomley]

On Tue, 2004-02-24 at 08:47, Mukker, Atul wrote:
> We are in process of releasing a unified driver, which will natively support
> the 2.4.x and 2.6.x kernels. 

I really don't think this will be such a good idea since you don't
currently have a unified driver.  2.4 is approaching end of life as far
as major driver updates go and the 2.6 APIs are quite a bit different. 
You'll find it's a lot of work for a driver that will carry you at most
six months before the distributions all switch to 2.6 and you find the
2.4 compatibility layer to be more of a hindrance than a help.

James

Re: [PATCH][BUGFIX] : megaraid patch for 2.10.1 (irq disable bug fix)

[Matt Domsch]

On Tue, Feb 24, 2004 at 09:06:43AM -0600, James Bottomley wrote:
> On Tue, 2004-02-24 at 08:47, Mukker, Atul wrote:
> > We are in process of releasing a unified driver, which will natively support
> > the 2.4.x and 2.6.x kernels. 
> 
> I really don't think this will be such a good idea since you don't
> currently have a unified driver.  2.4 is approaching end of life as far
> as major driver updates go and the 2.6 APIs are quite a bit different. 
> You'll find it's a lot of work for a driver that will carry you at most
> six months before the distributions all switch to 2.6 and you find the
> 2.4 compatibility layer to be more of a hindrance than a help.

Distributions with 2.4 kernels will continue to live on for quite a
while. Red Hat Enterprise Linux has a 5-year support life, during
which we would expect LSI to release new hardware, and we would want
to be able to have that hardware work on that OS somehow.  The driver
source for 2.4 and 2.6 need not be identical, but there *will* be
ongoing maintenance for drivers on 2.4 kernels for the next several
years.  We're <6 months into the RHEL3 supported lifetime.

While I understand the concerns with keeping 2.4 and 2.6 drivers
separate, we can't ignore the maintenance for 2.4 drivers.  If that's
done on a 2.4-only stream, or cleanly with a joint 2.4/2.6 driver, I
don't care, but agree it's difficult to do a clean joint driver,
especially with all the SCSI subsystem changes.

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

[PATCH][BUGFIX] : megaraid patch for 2.10.1 (irq disable bug fix)

[Bagalkote, Sreenivas]

Hello all,

The following patch fixes a bug in megaraid driver version 2.10.1
where irq was erroneously being disabled.

Thanks,
Sreenivas

diff -Naur current/drivers/scsi/megaraid.c patched/drivers/scsi/megaraid.c
--- current/drivers/scsi/megaraid.c	2004-02-23 23:56:10.000000000 -0500
+++ patched/drivers/scsi/megaraid.c	2004-02-23 23:56:18.000000000 -0500
@@ -2474,7 +2474,9 @@
 	memset(raw_mbox, 0, sizeof(raw_mbox));
 	raw_mbox[0] = FLUSH_ADAPTER;
 
-	irq_disable(adapter);
+	if( adapter->flag & BOARD_IOMAP ) 
+		irq_disable(adapter);
+
 	free_irq(adapter->host->irq, adapter);
 
 	/* Issue a blocking (interrupts disabled) command to the card */
@@ -4040,7 +4042,9 @@
 		memset(raw_mbox, 0, sizeof(raw_mbox));
 		raw_mbox[0] = FLUSH_ADAPTER;
 
-		irq_disable(adapter);
+		if( adapter->flag & BOARD_IOMAP ) 
+			irq_disable(adapter);
+
 		free_irq(adapter->host->irq, adapter);
 
 		/*

Re: [PATCH][BUGFIX] : megaraid patch for 2.10.1 (irq disable bug fix)

[Matthew Wilcox]

On Mon, Feb 23, 2004 at 12:24:31PM -0500, Bagalkote, Sreenivas wrote:
> Hello all,
> 
> The following patch fixes a bug in megaraid driver version 2.10.1
> where irq was erroneously being disabled.

Could we have a later version than 2.00.3 in 2.6 please?

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: [PATCH][BUGFIX] : megaraid patch for 2.10.1 (irq disable bug fix)

[Paul Wagland]

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


On Feb 23, 2004, at 18:29, Matthew Wilcox wrote:

> On Mon, Feb 23, 2004 at 12:24:31PM -0500, Bagalkote, Sreenivas wrote:
>> Hello all,
>>
>> The following patch fixes a bug in megaraid driver version 2.10.1
>> where irq was erroneously being disabled.
>
> Could we have a later version than 2.00.3 in 2.6 please?

In an interesting twist of fate, that is exactly what I am currently 
working on planning, see the patches that I pushed through last week, 
according to my estimates, I am about 1/3 of the way through 
modernising the 2.6 driver. However, as of yet I have received no 
comment from LSI about the modifications to the drivers that I have 
made. I have received a response from Jeff Garzik that it appears that 
I am on the right track.

As a side issue, the comment in the 2.6 driver that says that it is 
2.00.3 is just plain wrong. Look at the driver  from 2.6 and the 2.00.3 
release, there are a lot of differences there! The problem is that the 
2.6 and 2.4 drivers diverged a little at some point in the past, and 
then quite a lot in 2.6.1, hence the reason for taking so long to 
forward port the changes.

Cheers,
Paul

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