5

Last week I updated my kernel using the regular DNF update process. On reboot, none of the drives in my mdadm arrays were detected. I narrowed down the issue to a problem with the kernel and used an older kernel to boot. I waited a week for the next kernel update and ran the process again, hoping it was just a bad kernel, but the problem has not been resolved. Dmesg shows kernel: mpt2sas_cm0: failure at drivers/scsi/mpt3sas/mpt3sas_scsih.c:10790/_scsih_probe()! on both 5.8 kernels. After some research, I'm pretty sure that Fedora has dropped support for sas2116 controllers (https://access.redhat.com/discussions/3722151?page=2), so I either need to find drivers for this card or replace it with a 12gb/s card.

What do you suggest? Where can I find drivers for this card for Fedora 32 and how do I install them, or what would be a good 12gb/s card to replace it with (the card currently drives a 24 bay supermicro backplane with 12 drives installed)? The card I currently use is a LSI 9201-16e.

RedTedRedemption
  • 63
  • 2
  • Nothing in that link discusses Fedora, and I can't find any reason to think that Fedora dropped support for this device. This looks more like a bug, or possibly a hardware failure. If it works on a 5.7 kernel, then it'll be a bug, and you should consider reporting it as such. – Michael Hampton Sep 09 '20 at 18:38
  • I looked in Red Hat's Bugzilla (used for Fedora issues as well) and didn't find an open bug, but I am experiencing the problem too, on my LSI 9201-16e, which is a SAS2116 based card. [RHBZ 1878332](https://bugzilla.redhat.com/show_bug.cgi?id=1878332) It works on 5.7.17-200, but not on any 5.8 series kernel. Follow the bug to see Fedora & Red Hat progress.. – Liczyrzepa Sep 12 '20 at 03:06

1 Answers1

4

The issue is related to how the driver for the newer Broadcom/LSI Tri-Mode cards allocate large amounts of DMA memory for the very high 32455 default queue depth in the latest driver. This is problematic for these older cards as they use the same driver, but do not perform the logic to release all DMA queues then re-request on 32-bit boundary if the original DMA request is not fully allocated. To work around the issue you can set the kernel argument to lower the queue depth to 10000:

grubby --update-kernel=ALL --args="mpt3sas.max_queue_depth=10000"

You can find more details here: https://bugzilla.kernel.org/show_bug.cgi?id=209177

Andrew Schulman
  • 8,561
  • 21
  • 31
  • 47
Dave Johnson
  • 76
  • 5
  • While that command will work on some systems, the general answer here is to set the parameter 'mpt3sas.max_queue_depth' equal to 10000 or less, by some means, by the OS loader (likely GRUB). The parameter is a kernel parameter, a parameter used by the kernel to decide how exactly how the kernel interacts with the hardware (its only job). Generally the string 'mpt3sas.max_queue_depth=10000' will appear in the grub.cfg file. – J Collins Aug 23 '22 at 11:11
  • Yes, as my answer states, `To work around the issue you can set the kernel argument to lower the queue depth to 10000: […] args="mpt3sas.max_queue_depth=10000"’. Which is self evident what the workaround is for any Linux system. This question was for Fedora 32, not general Linux, hence answered as such. – Dave Johnson Aug 24 '22 at 14:14