MPT Fusion drivers and linux kernel 3.x
 

I am building a new system that will include an LSI 3801E SAS host bus adapter. I've used this adapter in previous linux systems without issue; it uses LSI's MPT Fusion drivers. I'd like to use a flavor of linux with a 3.x kernel and have run into some issues.

I've installed Mageia 2, which uses kernel 3.4 (3.4.34-desktop-1.mga2). The HBA is immediately recognized by the OS:

I am also able to use LSI's tools to query the card:

So far so good. Then I noticed that the module that's been prebuilt into the kernel is still quite old:

The most recent version of mptlinux is 4.28.00.00 (released by LSI on 8/22/2011, available here) so I figured I'd update it. I've done this in the past on kernel 2.6 systems without issue (no problems on a Mandiva 2010.2 system with 2.6.33.7-desktop-2mnb, for example) and I hoped this would be no different.

The driver package uses DKMS to compile and install the modules. This worked beautifully on my kernel 2.6 system. Unfortunately, I can't get them to compile on my new system:

I'm assuming this is due to incompatibility with newer kernels, but I have no idea...and I'm hoping there's a solution. Has anyone encountered this and/or know of a solution? I'd really like to update this driver as I've experienced problems with the older version in the past. So far all I've been able to find on the internet are complaints that LSI hasn't committed a newer version of the drivers to the linux kernel in quite some time, but nothing about getting the latest drivers to compile under the latest kernels. I've included the output from the make.log file below in case it helps. Please help!!

Why not use the driver included in Linux kernel?

Because I know that the version 3.x driver is buggy. In a previous system I had that used it, disks in the JBOD that was attached via the LSI adapter would randomly time out and become inaccessible. After updating to the most recent version of the driver (at that time 4.26.00) the problem went away. The 3.x versions of the driver have known bugs in them that have been mostly shaken out in the 4.x versions. A lot of the googling I did before posting my question turned up lots of bug reports and discussion threads concerning issues related to the 3.x drivers; nearly all the discussions devolved into quickly written patches to solve problems and complaints about why the version included in the kernel is so old. Interestingly enough, the 3.x version currently included in the kernel isn't even the most recent 3.x version (on LSI's website they currently offer a 3.28.00 version). Updating to the most recent version to ensure stability, compatibility, and functionality with as many devices as possible only seems prudent.

It just seems very odd (and frankly, stupid) that the version included in the kernel is so far behind the most recent version (3.04.20 vs. 4.28.00). LSI provides packages and the source code for the drivers on their site, but they only offer precompiled binaries for RHEL and SLES. And as I noted above, I am able to get the drivers to compile and load successfully via DKMS on a 2.6.x kernel. I'm assuming the reason I can't get them to compile now is because I'm using a 3.4.x kernel, but I'm only guessing. I'd be happy if I could at least verify that this is indeed the reason it won't compile, and it would be even better if someone is able to determine exactly why it isn't compiling from the make.log file. Ideally, of course, this would all lead to a solution that would get it to compile.

Looking at kernel (3.8.2) source ... the code in kernel is provided by LSI, 2012.

Interesting. Are you able to tell which version of the drivers are included in that kernel? Is it a 3.x or a 4.x version of the drivers?

Also, not to press the issue, but do you think my suspicions regarding the compilation issue are correct? Does the make.log file lead you to believe that the reason it won't compile is because I'm using a 3.x kernel?

Well, after decades of using Linux I can tell following. Hardware manufacturers provide their drivers source until it is incorporated into the kernel (if they are willing to provide open source drivers that is). Latest LSI has in their website is from 2011. To me it tells their code was approved by Linux kernel maintainers and they stopped offering a separate driver package. No wonder the old code won't build with 3.x, because there is no need, the new code is already in kernel source tree.
Disclaimer: The above is strictly from generic experience, I haven't looked at the code.
Hint: You can download the latest kernel source from kernel.org and try it out, regardless what distro you are using.

The mptdriver in the kernel source tree is still the 3.x version.

As of 2013-May-20, drivers/message/fusion/mptbase.h shows:
#define MPT_LINUX_PACKAGE_NAME "@(#)mptlinux-3.04.20"

The 4.28 drivers are at least as old as Aug 2011 (http://www.lsi.com/products/storagec...SISAS1064.aspx) but they're ahead of whats in the kernel tree.

There were 3 issues with the driver.

pci_remove_bus_device - this method has been renamed.
https://lkml.org/lkml/2012/2/25/82

__devexit_p references - apparently these can simply be removed
http://communities.vmware.com/thread/432897

lock_kernel/unlock_kernel - this is critical to get right and I dont know if the patch is correct but it looks correct and it does compile :).
http://stackoverflow.com/questions/5...-device-driver

This patch was written for a friend who wants to use this controller (I dont have the hardware), so no warranty, use at own risk, and post here if it compiles/works for you.

https://gist.github.com/donpdonp/5722900

$ patch < gist.patch
patching file mptbase.c
patching file mptctl.c
patching file mptfc.c
patching file mptsas.c
patching file mptspi.c

The code appears to have compiled correctly:

Hooray! I now have a (potentially very stupid) question -- how do I go about installing the newly compiled module to see if it works? I was using DKMS before because it takes care of everything for you (compiling, installing, linking, loading, etc). In particular, how can I load the new module(s) and, if they work, make them the default modules so they load at boot each time? And if they don't work, how can I revert back to the older version? The source directory contains a bash script called "load" which looks like it might perform a one-time load of the modules (it basically appears to run modprobe and insmod on several different files) but I'm guessing this won't make the new modules run at boot. There's also an "update" bash script that looks like it removes the old modules outright and copies the new ones into /lib/modules/`uname -r`/kernel/drivers/message/fusion...doesn't look like there's any turning back at that point. Thoughts?

I wanted to provide an update. I recently updated from Mageia 2 to Mageia 3, and I am now using kernel 3.10.24. Unfortunately, the drivers don't compile anymore, even with the patch. My output from compiling is below:
The version of the drivers included in the kernel is still old and in fact has not changed since at least kernel 3.4. I would appreciate any help in getting the drivers to compile again. Thanks!

Hi, i need help.
I try to install fusion driver to centos 6.5 (kernel 3.4 for xen). I use patch. Now, what i need to do to make rpm-file (or load modules).

Hi Gorod,

Unfortunately, as you can see in all the comments above, I was never able to get the latest version of the fusion drivers to work/compile properly with a 3.x kernel. The 3.x kernels generally do come with the version 3.04 of the fusion drivers built in; unfortunately I haven't been able to get the 4.x version of the drivers to work. I will say that I've encountered much fewer problems with the 3.x drivers in the 3.x kernel, so perhaps the all-around better stability of the 3.x kernel means there's not much advantage to trying to get the 4.x drivers to work. Otherwise, sorry dude, hopefully someone else can throw up some ideas to get them to compile.