[elrepo] mpt3sas driver

[Phil Perry]

On 09/03/16 11:35, Roman Serbski wrote:
> On Tue, Mar 8, 2016 at 8:29 PM, Phil Perry <phil at elrepo.org> wrote:
>>
>> Great work.
>>
>> OK, I've had a look at the native 3.10 kernel driver versus the driver in
>> RHEL 7.2, and clearly RH have already backported a lot of patches to this
>> driver since the native 3.10 kernel driver in RHEL7.0.
>>
>> Thus I've taken the latest RHEL 7.2 driver from kernel-3.10.0-327.10.1.el7
>> and applied the above 2 patches. This will be available in the elrepo
>> testing repository shortly as:
>>
>> kmod-mpt3sas-0.0-1.el7.elrepo.x86_64.rpm
>> mpt3sas-kmod-0.0-1.el7.elrepo.src.rpm
>>
>> To install, please do:
>>
>> yum --enablerepo=elrepo-testing kmod-mpt3sas
>>
>> and reboot
>>
>> Then please test as you see fit to see if it fixes your problem. You should
>> be able to confirm the new driver is running by running 'modinfo mpt3sas'
>> and looking at the path in the filename field. Simply uninstall the kmod and
>> reboot to switch back to the native driver.
>>
>> Regards,
>>
>> Phil
>
> Bingo, I think it worked -- many thanks Phil!
>

Brilliant. Great detective work identifying the two patches and this 
makes great proof of principle evidence for your bug report to Red Hat 
to get them to backport those two patches to the current driver.

> After several reboots scsi labeling is still consistent and no more
> "device is not present" errors.  I also believe I'm using the right
> mpt3sas driver, since the signer is ELRepo:
>
> $ modinfo mpt3sas
> filename:       /lib/modules/3.10.0-327.el7.x86_64/extra/mpt3sas/mpt3sas.ko
> version:        04.100.00.00
> license:        GPL
> description:    LSI MPT Fusion SAS 3.0 Device Driver
> author:         Avago Technologies <MPT-FusionLinux.pdl at avagotech.com>
> rhelversion:    7.2
> srcversion:     1D1320B925944F640273074
> alias:          pci:v00001000d00000095sv*sd*bc*sc*i*
> alias:          pci:v00001000d00000094sv*sd*bc*sc*i*
> alias:          pci:v00001000d00000091sv*sd*bc*sc*i*
> alias:          pci:v00001000d00000090sv*sd*bc*sc*i*
> alias:          pci:v00001000d00000097sv*sd*bc*sc*i*
> alias:          pci:v00001000d00000096sv*sd*bc*sc*i*
> depends:        scsi_transport_sas,raid_class
> vermagic:       3.10.0-327.el7.x86_64 SMP mod_unload modversions
> signer:         The ELRepo Project (http://elrepo.org): ELRepo.org
> Secure Boot Key
> sig_key:        F3:65:AD:34:81:A7:B2:0E:34:27:B6:1B:2A:26:63:5B:83:FE:42:7B
> sig_hashalgo:   sha256
> parm:           logging_level: bits for enabling additional logging
> info (default=0)
> parm:           max_sectors:max sectors, range 64 to 32767
> default=32767 (ushort)
> parm:           missing_delay: device missing delay , io missing delay
> (array of int)
> parm:           max_lun: max lun, default=16895  (int)
> parm:           diag_buffer_enable: post diag buffers
> (TRACE=1/SNAPSHOT=2/EXTENDED=4/default=0) (int)
> parm:           disable_discovery: disable discovery  (int)
> parm:           prot_mask: host protection capabilities mask, def=7  (int)
> parm:           max_queue_depth: max controller queue depth  (int)
> parm:           max_sgl_entries: max sg entries  (int)
> parm:           msix_disable: disable msix routed interrupts (default=0) (int)
> parm:           max_msix_vectors: max msix vectors - (default=8) (int)
> parm:           mpt3sas_fwfault_debug: enable detection of firmware
> fault and halt firmware - (default=0)
>

Yes, that's the elrepo driver.

> I do get one error (warning?) at the very start of mpt3sas driver
> loading, but I guess it could be ignored?
>
> [    3.592801] mpt3sas: module verification failed: signature and/or
> required key missing - tainting kernel
>

Yes, it's safe to ignore those warnings - the driver is signed with a 
Secure Boot signing key for those who use Secure Boot. If you are not 
using Secure Boot then the kernel will produce those warning messages.

> If I manage to convince Red Hat to fix it, will it be automatically
> transferred to CentOS or I will have to ask CentOS separately (I do
> have bugs raised with both)?
>

Given the number of patches already backported to this driver over the 
lifetime of RHEL7, I would say you have an excellent chance as they are 
obviously actively updating this driver on a regular basis, especially 
given that you've narrowed it down to just two patches and have provided 
evidence that those patches fix the issue. You've done the hard work for 
them.

As others have said, CentOS is a direct rebuild of RHEL, so once the fix 
appears in RHEL it will automatically propagate to the CentOS kernel too.

Additionally, Akemi maintains the CentOSPlus kernel for CentOS, and she 
has confirmed she will add these patches to the next CentOSPlus kernel, 
presumably for the next CentOS 7 kernel update, so that gives you an 
additional option to access this fix sooner rather than later.

So you have 2 choices - you can use the kmod I built for you with the 
current CentOS kernel packages, or you can uninstall the kmod and switch 
to the CentOSPlus kernel package until Red Hat fixes the issue. In this 
case I would recommend you use the CentOSPlus kernel until it's fixed, 
as that way you will also get any other updates to this driver that may 
be in the pipeline, whereas if you use my kmod you wouldn't unless I 
checked for mpt3sas updates in every RHEL kernel release and built you a 
new package. So for simplicity of staying up to date and current, I'd 
recommend the CentOSPlus kernel in this instance.

Hopefully Akemi will confirm once the patches have been added to the 
CentOSPlus kernel,


> Again, many thanks for your time and efforts, especially for guiding
> me in the right direction!

You're welcome - you did a lot of the hard work tracking down the 
appropriate patches, the rest is relatively easy for us :-)