PowerEdge 1850, PERC 4e/Si not visible in OMSA

Brice Figureau brice+dell at daysofwonder.com
Thu Jul 2 07:24:29 CDT 2009


Hi again,

On Wed, 2009-07-01 at 12:24 +0200, Brice Figureau wrote:
> Hi,
> 
> I do have the same issues for a 1850 and a 2850 with respectively a
> Perc4/SI and a Perc4/DI adapters.
> 
> I don't think the commit you highlighted is the root cause, but maybe it
> would be worth to test by removing this commit.
> 

I performed the git bisection between 2.6.24 (working) and 2.6.25 (not
working), and found that you were right.
The issue is in the commit you sent:
commit 90a95af85f22c82f87e5fb714bac7ee06673b0ff
Author: Thomas Horsten <thomas at horsten.com>
Date:   Mon Feb 4 23:53:18 2008 -0800

    [SCSI] MegaRAID driver management char device moved to misc
    
    The MegaRAID driver's common management module (megaraid_mm.c)
creates a
    char device used by the management tool "megarc" from LSI Logic (and
    possibly other management tools).
    
    In 2.6 with udev, this device doesn't get created because it is not
    registered in sysfs.
    
    I first fixed this by registering a class "megaraid_mm", but
realized that
    this should probably be moved to misc devices, instead of taking up
a char
    major.  This is because only 1 device is used, even if there are
multiple
    adapters - the minor is never used (the adapter info is in the ioctl
block
    sent to the driver, not detected based on the minor number as one
might
    think).  So it is a complete waste to have an entire major taken by
this.
    
    So it now uses a misc device which I named "megadev0" (the name that
megarc
    expects), and has a dynamic minor (previoulsy a dynamic major was
used).
    
    I have tested this on my own system with the megarc tool, and it
works just
    as fine as before (only now the device gets created correctly by
udev).
    
    Acked-by: "Patro, Sumant" <Sumant.Patro at lsi.com>
    Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
    Signed-off-by: James Bottomley
<James.Bottomley at HansenPartnership.com>

Of course, the issue is not really in the commit but in the
ligmegalib.so library. 
I've straced the dataeng service, and found that it tries to locate the
device by using /proc/devices.

Before the aforementioned patch, since the kernel attributed a major to
the char device, it appeared in /proc/devices:
Character devices:
...
252 megadev

But with this patch, it doesn't anymore, since there is no major
allocated.
So libmegalib.so thinks the device is not there, even though a
correct /dev/megadev0 is created by udev.

The real question is how to fix OMSA?

If there are any Dell engineer/developper reading this, please please
fix your megalib code (in fact I even think this is code coming from
LSI).

Meanwhile, I think we can fix this issue, by either reverting this patch
(it should revert cleanly on debian kernels). Or maybe it'd be possible
to use LD_LIBRARY_PRELOAD to load a read interceptor that could
rewrite /proc/devices on the fly...

Meanwhile, I'll revert this patch in all my kernels,
Thanks,
-- 
Brice Figureau
My Blog: http://www.masterzen.fr/



More information about the Linux-PowerEdge mailing list