This post is a request for any advice on what information I can dig up and provide or steps that I could take to make this report useful to development, testing or deployment of the latest XTRX driver and LimeSuiteNG code. Following a kernel update this morning, I could not load the limepcie module. My first diagnostic checks follow below.
IQXTR/testing$ modinfo limepcie
filename: /lib/modules/6.11.0-109017-tuxedo/updates/dkms/limepcie.ko.zst
license: GPL
author: Lime Microsystems
githash: 815fafad
version: 0.1.9
srcversion: 0FAD9C955069A37ADC4CFBA
alias: pci:v00002058d0000001Csvsdbcsci*
alias: pci:v00002058d0000001Bsvsdbcsci*
alias: pci:v00002058d0000001Asvsdbcsci*
alias: pci:v00001172d0000E001svsdbcsci*
alias: pci:v000010EEd00007023svsdbcsci*
alias: pci:v000010EEd00007022svsdbcsci*
depends:
retpoline: Y
name: limepcie
vermagic: 6.11.0-108014-tuxedo SMP preempt mod_unload modversions
sig_id: PKCS#7
signer: fai Secure Boot Module Signature key
sig_key: 7E:6C:65:54:40:E6:BA:9A:20:56:DF:EE:BB:69:F7:A4:D7:B9:A5:EC
sig_hashalgo: sha512
signature: 8A:43:8C:97:98:1E:63:BD:CD:C9:1C:AC:0B:92:55:75:D6:90:D4:AE:
23:DD:1A:03:FD:E1:E6:EA:33:9C:B6:8C:8E:37:9A:3B:9E:CC:9D:54:
CF:43:E8:F8:2F:11:A6:0A:2D:03:86:9F:4E:B1:B4:EA:8B:A5:72:76:
28:FB:02:4B:FD:5F:87:7D:B0:FE:4A:AB:FD:AD:A7:FE:F0:49:9D:39:
9A:D6:DD:A5:46:91:60:D8:41:5B:1C:F9:D2:6E:24:9D:86:ED:21:0A:
35:93:B7:53:22:1F:3C:F7:83:56:26:55:BA:AA:82:2E:DF:13:F0:10:
11:80:B6:F8:DB:DF:7D:F2:22:A3:CC:B5:FB:9E:58:C4:53:E2:7E:09:
D5:51:83:2B:7D:26:E7:8A:EA:68:3D:5F:CF:BE:0C:25:F3:1A:B3:1C:
76:82:8E:74:0B:75:26:DA:B8:ED:8B:FF:83:8E:B9:AB:A5:6A:30:C4:
6A:97:28:C7:C2:5E:B0:00:D3:B6:F0:E5:C2:2D:CD:81:54:70:7A:AD:
89:79:28:1A:8A:18:12:54:71:64:BB:4E:37:91:7C:34:B7:17:55:3D:
7C:14:4A:A6:66:29:C0:5F:8A:16:96:C9:1C:3B:B2:D2:42:22:C2:5C:
F2:3D:A2:AA:8E:EF:8F:02:E8:F8:AD:BF:ED:BD:13:5F
IQXTR/testing$ dkms status | grep “limepcie”
limepcie/0.1.9, 6.11.0-108014-tuxedo, x86_64: installed
limepcie/0.1.9, 6.11.0-109017-tuxedo, x86_64: installed
IQXTR/testing$ sudo modprobe limepcie
modprobe: ERROR: could not insert ‘limepcie’: Exec format error
IQXTR/testing$ sudo dmesg -T | grep limepcie
[Mon Feb 24 08:49:05 2025] limepcie: disagrees about version of symbol module_layout
[Mon Feb 24 08:53:07 2025] limepcie: disagrees about version of symbol module_layout
[Mon Feb 24 08:57:22 2025] limepcie: disagrees about version of symbol module_layout
Your current kernel version is 6.11.0-109017-tuxedo. The kernel module you are trying to load was built using 6.11.0-108014-tuxedo
The major and minor versions are the same, but the “patch” or something in it is different, so the kernel refuses to load incompatible module.
It might be not just the version difference, but the kernel features set, that was used when compiling it.
See uname -a to inspect enabled features, if they match the features listed in module vermagic SMP preempt mod_unload modversions
So overall, it all depends on who/how updated the kernel.
IQXTR/testing$ uname -a
Linux solstice 6.11.0-109017-tuxedo #17~24.04.2tux1 SMP PREEMPT_DYNAMIC Tue Feb 11 16:21:35 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
I will explore further this afternoon and hopefully I can enhance my understanding of this kernel module update process. Thanks!
The limepcie kernel module stayed the same, it is there from the last build. What changed is the kernel itself, usually when kernel version is updated, a separate directory is created where it’s modules are stored. In your case the kernel version numbers are the same, only a tag is different and kernel configuration, so it got placed in the same directory of the previous kernel, hence all the module filles are there, but none of them are compatible anymore, and dkms is not automatically rebuilding the module, because there already are built files.
So in your case, you either have to manually rebuild the limepcie module with the new kernel, or compile and update your kernel with the same configuration as previous kernel had.
You can see the kernel’s configuration files in /boot/config-old kernel version and when compiling the new kernel yourself you can provide that file to match the configuration.
Thanks for your help (again). I removed all limecie driver modules from the dkms tree and rebuilt with the current running kernel (default); all works as expected. The manual rebuild process is easy although is this something that I need to do in the case where only the kernel tag changes but not the kernel version? If that is the case, I don’t quite understand why other modules in the update folder (under the new tagged kernel) escaped the need for manual intervention. I wonder if this behavior is peculiar to the TUXEDO variant of Ubuntu 24.04.
that’s just how linux kernel works, it’s not specific to Ubuntu.
I don’t know about what other modules your talking about, if they are even used, or did they came together with the updated kernel. But essentially it’s not only about the tag, the kernel version might be the same, but the kernel configuration/features enabled/disabled can be different, which makes the symbols layout different and that makes the modules binary interface incompatible with the changed kernel interface.
This is very enlightening. Should anyone be interested, the ‘other’ modules in the updates/dkms folder are:
$ ls /usr/lib/modules/6.11.0-109017-tuxedo/updates/dkms
clevo_acpi.ko.zst tuxedo_nb04_sensors.ko.zst
clevo_wmi.ko.zst tuxedo_nb04_wmi_ab.ko.zst
gxtp7380.ko.zst tuxedo_nb04_wmi_bs.ko.zst
ite_8291.ko.zst tuxedo_nb05_ec.ko.zst
ite_8291_lb.ko.zst tuxedo_nb05_fan_control.ko.zst
ite_8297.ko.zst tuxedo_nb05_kbd_backlight.ko.zst
ite_829x.ko.zst tuxedo_nb05_keyboard.ko.zst
limepcie.ko.zst tuxedo_nb05_power_profiles.ko.zst
stk8321.ko.zst tuxedo_nb05_sensors.ko.zst
tuxedo_compatibility_check.ko.zst tuxedo_tuxi_fan_control.ko.zst
tuxedo_io.ko.zst tuxi_acpi.ko.zst
tuxedo_keyboard.ko.zst uniwill_wmi.ko.zst
tuxedo_nb02_nvidia_power_ctrl.ko.zst vboxdrv.ko.zst
tuxedo_nb04_kbd_backlight.ko.zst vboxnetadp.ko.zst
tuxedo_nb04_keyboard.ko.zst vboxnetflt.ko.zst
tuxedo_nb04_power_profiles.ko.zst