1

The Broadcomm Linux PLX SDK 8.23 can be compiled and loaded on CentOS7, Alma Linux 8.8, openSUSE 15.5 or Ubuntu 20.04 computers essentially without problems (besides changing a mm->mmap_sem to mm->mmap_lock because some structures in the kernel may have been renamed, or replacing a down_read/up_read by a mmap_read_lock/mmap_read_unloc and a set of arguments inget_user_pages in SuppFunc.c if required). That compile and load (insmod) fails for Alma Linux 9.1 and 9.2 and ends up with a kernel panic (which automatically reboots the computer) somewhere in the Plx_dma_buffer_alloc() function in the init_module().

The problem is the same for the 8311 and the 9656 kernel object module, i.e. for two types of different cards we have been developing for PCI-extended/PCI-express mother boards.

I have not checked whether AlmaLinux 9.0 also has this problem.

It does not look like a generic kernel problem because I've even been installing this with 6.x Linux kernels under openSUSE Tumbleweed, and because the current openSUSE and Ubuntu kernels are all in the 5.14 versions. I even checked that I can compile the PLX SDK 8.23 under gcc-11 and load it under openSUSE leap 15.5 (gcc 7.5) without problems.

Is this a known problem for RedHat 9.x or Alma Linux 9.x device drivers?

1 Answers1

0

This can apparently patched on Alma Linux 9.2 by replacing the GFP_KERNEL | __GFP_NOWARN flags by the flag GFP_ATOMIC in the call of dma_alloc_coherent in the function Plx_dma_buffer_alloc in the file SuppFunc.c Probably some sort of semaphore /spin-lock wrapper around that functionality would also work. I did not check whether that source code modification would also work on Alma Linux 9.0 or 9.1.