[SUBJECT CHANGE]: megaraid unified driver version 2.20.0.0-alpha1

[SUBJECT CHANGE]: megaraid unified driver version 2.20.0.0-alpha1

[Mukker, Atul]

All,

Here is the list of enhancements this driver has build over the current
2.10.1 driver. Please list you specific concerns so that the driver can be
modified accordingly. This is an updated version of the current driver in lk
2.6, which should take all your fixes, instead of current 2.00.3 in 2.6.2


1.	Support for upcoming MPT *RAID* controllers. These are not the
currently in kernel fusion-mpt controllers we are talking about.

2.	Controller and device re-ordering on both lk 2.4 and lk 2.6. If this
is not desired, the driver code would be modified to make it PCI ordered
detection. The driver also re-orders the drives, based on which one is
chosen as boot drive. Matt, please add your comments here.

3.	Support for DPC using tasklets. This is currently available for
traditional mailbox controllers only.

4.	Native hot-plug support for both lk 2.4 and lk 2.6

5.	Single code for lk 2.4 and lk 2.6. We would like to keep the driver
this way but again if general kernel rules are against this, this is the
right inflection point, we will fork the driver.

6.	Single code to support *all* x86-32, IA64, and x86-64 platforms

7.	Exports physical devices on their actual addresses instead 2.10.1
scheme of exporting logical drives first and than exporting physical devices
on virtual channels.

8.	Support for up to 256 commands (configurable) per mailbox based
adapter instead of 127 for 2.10.1 driver.

9.	"mbox_fast_load" module parameter allows the driver to load much
faster than 2.10.1.

10.	Efficient algorithm to translate mid-layer device address to
megaraid device addresses.


Thanks
-Atul Mukker
LSI Logic Corporation

> -----Original Message-----
> From: Arjan van de Ven [mailto:arjanv@redhat.com]
> Sent: Tuesday, February 24, 2004 4:14 PM
> To: Mukker, Atul
> Cc: 'James Bottomley'; 'matt_domsch@dell.com'; 'Paul Wagland'; Matthew
> Wilcox; 'linux-kernel@vger.kernel.org'; 'linux-scsi@vger.kernel.org'
> Subject: Re: [PATCH][BUGFIX] : megaraid patch for 2.10.1 (irq disable
> bug fix)
> 
> 
> 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 
> 

Re: [SUBJECT CHANGE]: megaraid unified driver version 2.20.0.0-alpha1

[Matthew Wilcox]

On Tue, Feb 24, 2004 at 07:34:01PM -0500, Mukker, Atul wrote:
> 6.	Single code to support *all* x86-32, IA64, and x86-64 platforms

No.  Megaraid is a PCI card.  Therefore this one codebase should support
*all* PCI-capable architectures, not just these three.  Nobody's requiring
that you test on all the weird and wonderful architectures out there, just
that you don't do things like

#if defined(__x86_64__) || defined(__ia64__)
#endif

when you really mean

#ifdef CONFIG_COMPAT
#endif

-- 
"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: [SUBJECT CHANGE]: megaraid unified driver version 2.20.0.0-alpha1

['Christoph Hellwig']

On Tue, Feb 24, 2004 at 07:34:01PM -0500, Mukker, Atul wrote:
> 1.	Support for upcoming MPT *RAID* controllers. These are not the
> currently in kernel fusion-mpt controllers we are talking about.

given that they are completely different from the controller we know
as megaraid today this is an extremly bad idea.  Just put it into an driver
of their own, e.g. mptraid

> 2.	Controller and device re-ordering on both lk 2.4 and lk 2.6. If this
> is not desired, the driver code would be modified to make it PCI ordered
> detection. The driver also re-orders the drives, based on which one is
> chosen as boot drive. Matt, please add your comments here.

This is a bad thing for 2.6, don't do it.  For 2.4 just leave the probe code as
it is there currently - any change during the stable series just confuses
users.

> 4.	Native hot-plug support for both lk 2.4 and lk 2.6

hotplug scsi in 2.4 is impossible without a host template per controller
which you don't seem to do and I'd advice against.

> 6.	Single code to support *all* x86-32, IA64, and x86-64 platforms

Umm, it's a PCI card - if it doesn't work on any PCI supporting architecture
it's a driver bug (either in your driver or the architectures PCI subsysyem)

> 7.	Exports physical devices on their actual addresses instead 2.10.1
> scheme of exporting logical drives first and than exporting physical devices
> on virtual channels.

While this makes sense it's not a change that should go into 2.4 anymore
as it changes existing setups

Re: megaraid unified driver version 2.20.0.0-alpha1

[Paul Wagland]

Hi,

One of my goals with the forward porting of the 2.10.1 changes to the
driver in lk2.6 was also to add a wider level of sysfs support. Is there
any plan to add this to the unified driver?

I am sure that other, more experienced, people will bring up other
points, but here are a few comments of mine;

1. I had a quick look through the code to check on "extended" sysfs
support, i.e. whether or not board specific abilities/information could
be accessed through the sysfs interface. At the moment, they are only
accessible through the /proc interface. Would it be possible to do
something like what I did in
http://marc.theaimsgroup.com/?l=linux-scsi&m=107724328420636&w=2 I.e.
split the information gathering into a separate module, and then use
that for both the /proc system, and the /sys system.

2. The Scsi_Host_Template should have a ".module = THIS_MODULE,"
initialiser, otherwise the device can be removed whilst it is still
accurate. Please see
http://marc.theaimsgroup.com/?l=linux-scsi&m=107692559912129&w=2

3. Longer term perhaps, but, if sysfs support is included, is it
possible/reasonable to include write support for some/all of the
attributes? For example, to be able to set the rebuild-rate without
using the LSI supplied binary.

Cheers,
Paul

Re: [SUBJECT CHANGE]: megaraid unified driver version 2.20.0.0-alpha1

[Matt Domsch]

On Wed, Feb 25, 2004 at 01:16:40PM +0000, 'Christoph Hellwig' wrote:
> On Tue, Feb 24, 2004 at 07:34:01PM -0500, Mukker, Atul wrote:
> > 2.	Controller and device re-ordering on both lk 2.4 and lk 2.6. If this
> > is not desired, the driver code would be modified to make it PCI ordered
> > detection. The driver also re-orders the drives, based on which one is
> > chosen as boot drive. Matt, please add your comments here.
> 
> This is a bad thing for 2.6, don't do it.  For 2.4 just leave the probe code as
> it is there currently - any change during the stable series just confuses
> users.

I agree with Christoph here.  megaraid is the only driver that I've
worked with that does this device reordering thing; none of the other
SCSI drivers we use regularly does, and it's not a feature that I've
advertised to customers when they come asking.  It would help greatly
if the firmware could export unique numbers akin to SCSI inquiry page
83 for each logical drive on each controller, such that we could
actually use udev and friends well.  I've asked for this feature for
several years, and I know it's not yet on the firmware roadmaps.

The list of PCI devices should be ordered in two buckets: ROMBs first,
then add in cards; secondarily, oldest to newest.  We do this with
aacraid today.

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: [SUBJECT CHANGE]: megaraid unified driver version 2.20.0.0-alpha1

[Matthew Wilcox]

On Wed, Feb 25, 2004 at 11:28:39AM -0600, Matt Domsch wrote:
> The list of PCI devices should be ordered in two buckets: ROMBs first,
> then add in cards; secondarily, oldest to newest.  We do this with
> aacraid today.

In 2.4, you can do what you like.  The list of PCI devices is in PCI
bus number order, and that's the order you get when you use the hotplug
interfaces.  Yes, this is a painful customer-visible change, but if
they use scsi discs, they must already be used to devices changing name
at random.

-- 
"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: [SUBJECT CHANGE]: megaraid unified driver version 2.20.0.0-alpha1

[Matt Domsch]

On Wed, Feb 25, 2004 at 05:35:40PM +0000, Matthew Wilcox wrote:
> On Wed, Feb 25, 2004 at 11:28:39AM -0600, Matt Domsch wrote:
> > The list of PCI devices should be ordered in two buckets: ROMBs first,
> > then add in cards; secondarily, oldest to newest.  We do this with
> > aacraid today.
> 
> In 2.4, you can do what you like.  The list of PCI devices is in PCI
> bus number order, and that's the order you get when you use the hotplug
> interfaces.

Ahh, yes, of course.  

> Yes, this is a painful customer-visible change, but if they use scsi
> discs, they must already be used to devices changing name at random.

Well, to be fair, most people count on it not changing, i.e. it is
deterministic at least, such that if you don't change hardware or add
logical drives, you won't see any changes between boots.  For most
users, file system labels serve quite well to keep things consistent.
For swap, raw devices, and the like, devlabel or udev are used, but at
least devlabel (sorry Greg, I haven't played with udev too much yet)
uses SCSI inquiry page 83 or 80 data if it's there, which megaraid
doesn't provide.

For the install scenario, EDD (which megaraid *does* provide) will
suffice, but I need to get distro installers to start using it. ;-)
Oh, and get it working on x86-64.  That should be easy, soon as I have
access to such a system for a few days.


-- 
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