Bugzilla – Bug 146542
Installation to PERC 2/DC Megaraid controller fails
Last modified: 2010-12-10 14:22:44 UTC
My system has a SCSI RAID controlled by a Dell PERC 2/DC PCI controller, which is a rebranded AMI (now LSI Logic) Megaraid 467 controller. LSI's recent Linux drivers dropped support for legacy Megaraid controllers such as mine. When the system installation runs, it detects a Megaraid controller and tries to use the megaraid kernel module, but the module fails and the system locks up. There is a megaraid_legacy module floating around (though I'm not sure of its exact name) that would support my hardware, but until recently it might have conflicted with the new megaraid module if they were both loaded at the same time. I think the conflicts have been resolved. There should be some way to install Suse Linux to my RAID! Windows can do it, and FreeBSD can do it. It's a problem in a lot of Linux distros because of LSI, but I've seen fixes floating around, I'm just not up to the task of compiling the module from source, especially when I can't even install the system I would need to use to do the compiling.
no yast issue but request for a driver
I am very sorry, but we are restricting the number of out of tree kernel modules we will ship in Suse Linux. If you are interested in support for these, please try to help these folks get their legacy support module into the mainline kernel. Eric, any chance for LSI to fix the support for these controllers?
*** Bug 146541 has been marked as a duplicate of this bug. ***
Answering the question asked under related issue 146541, here are the Hardware IDs reported by Windows 2003 Server Device Manager for the Dell PERC 2/DC RAID Controller: PCI\VEN_8086&DEV_1960&SUBSYS_04671028&REV_01 PCI\VEN_8086&DEV_1960&SUBSYS_04671028 PCI\VEN_8086&DEV_1960&CC_0E0001 PCI\VEN_8086&DEV_1960&CC_0E00 If it helps, I have found that support for this controller is built into Fedora Core 4 (Linux 2.6.11) but I don't know what customizations were required to add the support.
This appears to be megaraid. Reassign to Seokmann Ju.
I've verified the source on SLES 10 (2.6.16-rc1), and found that the driver 'megaraid' should support the controller as expected. From the megaraid.[ch] file, you will find follwing: --- megaraid.h ... #ifndef PCI_VENDOR_ID_INTEL #define PCI_VENDOR_ID_INTEL 0x8086 #endif ... #ifndef PCI_DEVICE_ID_AMI_MEGARAID3 #define PCI_DEVICE_ID_AMI_MEGARAID3 0x1960 #endif ... magaraid.c ... static struct pci_device_id megaraid_pci_tbl[] = { ..., {PCI_VENTOR_ID_INTEL, PCI_DEVICE_ID_AMI_MEGARAID3, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, ..., } ---
As the module locks the system up I doubt that this is a YaST bug. Nevertheless, please provide the logs see: http://en.opensuse.org/Bug_Reporting_FAQ#YaST
Created attachment 68691 [details] messages received during installation, ending in megaraid errors Please let me know if you need additional information and how I can get it. The attached file explains why I couldn't send complete logs.
I've tested 'megaraid.ko' on SLES 10 (kernel 2.6.16-rc1-git3-7-default) and I'm getting strange behaviour during loading. After loading completes (with manually thorouth 'insmod ./megaraid.ko'), the kenel lists 'megaraid' as module loaded when I do 'lsmod'. However, there is NO messages from the driver during loading. I've hook up message in _init function, but it doesn't displayed. This driver has been verified on one of GIT kernel (2.6.16-rc1) couple of weeks back. Any clues? The other driver 'megaraid_mm/megaraid_mbox.ko' module works fine.
The provided kernel messages show that it's really the kernel that hangs (as suspected) - nothing we can do from the YaST2 side. Kernel maintainers, from comment #2 I take it this is a WONTFIX for you?!
Seokmann Ju, does this mean the messages do not get displayed on the console, or that they do not end up in the dmesg output at all?
There is NO message from both console and dmesg. Just to make it clear, the controller has PCI IDs that the driver supports and they are, VID/DID/SSVID/SSID = 0x8086/0x1960/0x101E/0x0467
I2O modules are getting loaded first; most likely they grab the drive. Thus the megaraid driver doesn't find an unclaimed device. Steffen, can we change the driver loading sequence? Seokman Ju, I fear you have to check how you can cooperate with i2o modules.
Hannes, The controller has two mode that can be toggled and they are I2O and mass storage. By setting the controller as mass storage mode, it won't act as I2O module so that there is NO response to I2O OSM requests. That is what I have to concern, in my opinion. The question here is that why _init doesn't get called for the controller listed as supported? I'm not sure what do I need to do from driver side on this type of situation. Any comment would be appreciated.
ad 13: AFAIK there is no way you can force a specific loading order except adding various 'insmod=foo' during installation. But it's not sure this will make it into the installed system.
I've picked up latest GIT kernel 2.6.16-rc3 which I believe same kernel as SLES10, compiled kernel and loaded the driver successfully without any problem. To me, this issue is happening on SLES10 only. Any comment/clue would be appreciated.
The issue still exists in OpenSuse 10.1 beta 9. It seems that even though the kernel (2.6.16) supports the new megaraid_legacy driver, the driver is not included in the beta 9 distribution.
We will not fix this bug for 10.0 anymore. If the bug still exists in openSUSE 10.3, please reopen and change the product. If it's a case of a driver not enabled in the config, please reassign to the default owner of the component (or create a complete new bugreport).
Closing old resolved,invalid or won't fix bugs.