On Thursday, December 31, 2020 11:24 AM, Lamar Owen <lowen at pari.edu> wrote: > On 12/31/20 7:49 AM, Nico Kadel-Garcia wrote: > > > If they cost you that much work, consider buying modest Adaptec RAID > > controllers. MegaRAID had a bad habit of doing a lot of the RAID work > > in the kernel, not on the attached hardware, which was why the kernel > > modules were so critical. ...I'm very surprised if you have hardware > > that actually needs that third-party driver, though it may take work > > to get the latest kernel into a bootable ISO or PXE image. > > Well: > [root at grymonia ~]# lspci|grep RAID > 03:00.0 RAID bus controller: Broadcom / LSI MegaRAID SAS 2108 > [Liberator] (rev 05) > [root at grymonia ~]# lspci -n|grep 03.00.0 > 03:00.0 0104: 1000:0079 (rev 05) > > See http://elrepo.org/tiki/DeviceIDs and > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/considerations_in_adopting_rhel_8/hardware-enablement_considerations-in-adopting-rhel-8#removed-adapters_hardware-enablement > > Note especially the wording in the latter link: " The following adapters > from the megaraid_sas driver have been removed: ... SAS0079GEN2, PCI ID > 0x1000:0x0079 ...." The problem is NOT that megaraid_sas has been > removed (it hasn't, see below); the problem is that PCI ID 0x1000:0x0079 > has been removed from the in-kernel megaraid_sas driver. Yes, the > released kernel HAS a megaraid_sas.ko.xz module, but the PCI ID of the > controller in the R710 is removed by Red Hat's patches from the released > module. (This is not the only hardware for which this situation is true; > it honestly looks like Red Hat asked Dell what Dell wanted supported and > Dell cut off anything that Dell considers to be "too old.") Here's what > the modules tree looks like, along with a listing of the contents of the > ELrepo kmod-megaraid_sas package: > > [root at grymonia modules]# find /usr/lib/modules -name megaraid_sas* -print > /usr/lib/modules/4.18.0-193.el8.x86_64/extra/megaraid_sas > /usr/lib/modules/4.18.0-193.el8.x86_64/extra/megaraid_sas/megaraid_sas.ko > /usr/lib/modules/4.18.0-193.14.2.el8_2.x86_64/kernel/drivers/scsi/megaraid/megaraid_sas.ko.xz > /usr/lib/modules/4.18.0-193.14.2.el8_2.x86_64/weak-updates/megaraid_sas > /usr/lib/modules/4.18.0-193.14.2.el8_2.x86_64/weak-updates/megaraid_sas/megaraid_sas.ko > /usr/lib/modules/4.18.0-193.19.1.el8_2.x86_64/kernel/drivers/scsi/megaraid/megaraid_sas.ko.xz > /usr/lib/modules/4.18.0-193.19.1.el8_2.x86_64/weak-updates/megaraid_sas > /usr/lib/modules/4.18.0-193.19.1.el8_2.x86_64/weak-updates/megaraid_sas/megaraid_sas.ko > /usr/lib/modules/4.18.0-193.28.1.el8_2.x86_64/kernel/drivers/scsi/megaraid/megaraid_sas.ko.xz > /usr/lib/modules/4.18.0-193.28.1.el8_2.x86_64/weak-updates/megaraid_sas > /usr/lib/modules/4.18.0-193.28.1.el8_2.x86_64/weak-updates/megaraid_sas/megaraid_sas.ko > [root at grymonia modules]# rpm -ql kmod-megaraid_sas > /etc/depmod.d/kmod-megaraid_sas.conf > /lib/modules/4.18.0-193.el8.x86_64 > /lib/modules/4.18.0-193.el8.x86_64/extra > /lib/modules/4.18.0-193.el8.x86_64/extra/megaraid_sas > /lib/modules/4.18.0-193.el8.x86_64/extra/megaraid_sas/megaraid_sas.ko > /usr/share/doc/kmod-megaraid_sas-07.710.50.00 > /usr/share/doc/kmod-megaraid_sas-07.710.50.00/GPL-v2.0.txt > /usr/share/doc/kmod-megaraid_sas-07.710.50.00/greylist.txt > [root at grymonia modules]# > > It's not a 3rd party driver if the driver is in the released > kernel.... this is the point that seems to continue to be glossed over, > that some of these point-release-dependent drivers are restoring > functionality to already in-kernel modules where that functionality has > been intentionally removed by Red Hat because Red Hat won't support that > hardware. If Red Hat is patching out those PCI IDs for RHEL, it's > highly likely, in my opinion, that Red Hat isn't going to not patch them > out in the Stream kernels (yes, I know, double negative, but all Red Hat > has to do is not patch out the support for that PCI ID to restore support). Given what I know about Dell, I think it is likely that Dell bought an OEM specified custom flavor of the Megaraid to be one of their Dell PERC. At some point a RHEL customer requested assistance with a serious problem with their MegaRAID/PERC. RHEL support was not able to resolve the issue directly as it required a firmware update. So since Dell is a Red Hat partner, they reached out to Dell. Dell then probably said something about no longer having a contract to get firmware updates from the vendor. RHEL support then responded to the customer that they are unable to provide a solution. The customer then gets upset about the PERC being listed as "supported" and asks why. The response would then be that RHEL is committed to attempting to support the same hardware through the entire life-cycle of RHEL 7.x but they are still limited by what the hardware/firmware vendor is willing to assist. However, based on feedback from their customers, they will remove support in the next major release (RHEL 8.0) to make the situation more clear to customers. I can't prove any of that is what really took place but based on my experiences in the past, I think it is a possible explanation. My understanding of Stream is RHEL packages should largely come as-is from packages previously released on Stream. Hence, Stream might get Technology Preview drivers before RHEL. However, the policy of deprecation/removal of hardware will also be reflected in Stream. You might be able to use kernel boot arguments or tricks involving dracut and echo'ing the pci-id into /sys to working around the removal. But I haven't actually tried it with a Dell PERC.