DE froze with graphic glitches... lots of kernel, drm, and amdgpu entries in journal

okay, I was trying to learn more at Linux Kernel Module Management 101 - Linux.com and How to load or unload a Linux kernel module | Opensource.com … and I think I got a little bit smarter; enough to stumble on a new trick, which then revealed another head scratcher.

What I think I learned…

  1. amdgpu is actually not inside the kernel, but is loaded as a kernel module (driver), which for my current 5.15.2 kernel is in the path…
$ find /lib/modules/$(uname -r) -type f | grep amdgpu
/lib/modules/5.15.2-2-MANJARO/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko.xz
  1. But amdgpu has some dependency modules as well that get loaded, as found by the script, and seconded by…
$ lsmod | grep amdgpu
amdgpu               8613888  59
gpu_sched              53248  1 amdgpu
drm_ttm_helper         16384  1 amdgpu
ttm                    86016  2 amdgpu,drm_ttm_helper

And the trick I think I learned was how to find other installed module dependencies/differences without having to boot the other kernels…

  1. so taking the find command above, I thought I’d try remove the loaded kernel uname part of the path and instead grep for one of “missing” modules… drm.ko (ko = kernel object)… which basically confirmed it was absent (even on the drive) for the 5.15 kernel.
$ find /lib/modules/ -type f | grep /drm.ko
/lib/modules/5.10.79-1-MANJARO/kernel/drivers/gpu/drm/drm.ko.xz
/lib/modules/5.14.18-1-MANJARO/kernel/drivers/gpu/drm/drm.ko.xz
/lib/modules/5.13.19-2-MANJARO/kernel/drivers/gpu/drm/drm.ko.xz
/lib/modules/5.14.10-1-MANJARO/kernel/drivers/gpu/drm/drm.ko.xz
  1. While thinking about how I would get the entire amdgpu depends list for the other kernels, and feeling a bit more comfortable with the paths and extensions/file-types, I recalled the “ugly” $ cat /lib/modules/$(uname -r)/modules.dep | grep amdgpu command I’d found earlier, and built a command to find all the module.dep files…
$ find /lib/modules -name "modules.dep"
/lib/modules/5.10.79-1-MANJARO/modules.dep
/lib/modules/5.14.18-1-MANJARO/modules.dep
/lib/modules/5.15.2-2-MANJARO/modules.dep
/lib/modules/5.13.19-2-MANJARO/modules.dep
/lib/modules/5.14.10-1-MANJARO/modules.dep
  1. Now that I had all the paths, I could check for the amdgpu module dependencies for … say kernel 5.14 (which happened to pull the same list as the 5.13 file)…
$ cat /lib/modules/5.14.18-1-MANJARO/modules.dep | grep amdgpu
kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko.xz: kernel/drivers/gpu/drm/scheduler/gpu-sched.ko.xz kernel/drivers/i2c/algos/i2c-algo-bit.ko.xz kernel/drivers/gpu/drm/drm_ttm_helper.ko.xz kernel/drivers/gpu/drm/ttm/ttm.ko.xz kernel/drivers/gpu/drm/drm_kms_helper.ko.xz kernel/drivers/media/cec/core/cec.ko.xz kernel/drivers/gpu/drm/drm.ko.xz kernel/drivers/char/agp/agpgart.ko.xz kernel/drivers/video/fbdev/core/syscopyarea.ko.xz kernel/drivers/video/fbdev/core/sysfillrect.ko.xz kernel/drivers/video/fbdev/core/sysimgblt.ko.xz kernel/drivers/video/fbdev/core/fb_sys_fops.ko.xz

But the results from this file (5.13 and 5.14) introduces another head scratcher, as it lists a few more depends than the script found… I’ll apply tr to the command to make it easier to read…

$ cat /lib/modules/5.14.18-1-MANJARO/modules.dep | grep amdgpu | tr ' ' '\012'
kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko.xz:
kernel/drivers/gpu/drm/scheduler/gpu-sched.ko.xz
kernel/drivers/i2c/algos/i2c-algo-bit.ko.xz
kernel/drivers/gpu/drm/drm_ttm_helper.ko.xz
kernel/drivers/gpu/drm/ttm/ttm.ko.xz
kernel/drivers/gpu/drm/drm_kms_helper.ko.xz
kernel/drivers/media/cec/core/cec.ko.xz
kernel/drivers/gpu/drm/drm.ko.xz
kernel/drivers/char/agp/agpgart.ko.xz
kernel/drivers/video/fbdev/core/syscopyarea.ko.xz
kernel/drivers/video/fbdev/core/sysfillrect.ko.xz
kernel/drivers/video/fbdev/core/sysimgblt.ko.xz
kernel/drivers/video/fbdev/core/fb_sys_fops.ko.xz

That’s 13 depends, not 8 like the script found. Maybe the .dep file just lists the dependencies… but whether or not they are used may be another matter? If that’s the case, my trick may be a red herrring and I really do have to boot the kernel to really know what was actually loaded :thinking: