Bug#1124075: linux-image-6.17.12+deb14-amd64: Kernel Oops (GPF) in idempotent_init_module when loading lp module
Dear Salvatore,
Thank you for the reply.
This is my primary production machine, and I had to prioritize restoring stability. When the issue first occurred, I identified the 'lp' module as the cause and disabled it. Crucially, even attempting an APT kernel upgrade at that moment caused a total system hang, forcing a hard reboot via SysRq.
After blacklisting the module and successfully rebooting, I upgraded to the latest minor kernel version and re-enabled 'lp'. The issue has not reappeared since then.
Given the risk of data loss and the fact that I cannot afford further system hangs on my workstation, I am unable to revert to the broken state for a bisect or test experimental kernels. I hope the details in my original report remain useful.
Best regards,
YuZhong Wang
Control: tags -1 + moreinfo unreproducible
On Sat, Dec 27, 2025 at 04:19:02PM +0800, YuZhong Wang wrote:
> Package: src:linux
> Version: 6.17.12-1
> Severity: important
> Tags: upstream
> X-Debbugs-Cc: debian-amd64@lists.debian.org
> User: debian-amd64@lists.debian.org
> Usertags: amd64
>
> Dear Maintainer,
>
> * What led up to the situation?
> After booting my AMD AM5 system (ASUS ROG STRIX B650-A), I noticed that
> 'systemd-modules-load.service' would hang for nearly 7 minutes.
> To investigate, I used 'dmesg -w' in one terminal and manually
> attempted to load the suspected module in another using:
> 'sudo modprobe -v lp'
>
> * What exactly did you do (or not do) that was effective (or ineffective)?
> 1. Execution: 'sudo modprobe -v lp' immediately resulted in a
> "Segmentation Fault" (段错误).
> 2. Troubleshooting: I checked the kernel logs and found a General
> Protection Fault in 'idempotent_init_module'.
> 3. Workaround: I renamed the config file:
> 'sudo mv /etc/modules-load.d/cups-filters.conf /etc/modules-load.d/cups-filters.conf.break'
> This prevented the boot-time hang. I also eventually blacklisted 'lp'.
> 4. Note: During my attempts to fix this, an APT upgrade once hung,
> forcing me to use Alt+PrintScreen+B (REISUB) to reboot.
>
> * What was the outcome of this action?
> The manual 'modprobe' consistently triggers a Kernel Oops.
> My current kernel taint state is 12417 (P D OE). The 'D' (DIE) was
> triggered by this GPF, while P/OE are from my manual NVIDIA driver
> installation via official .run scripts.
>
> * What outcome did you expect instead?
> The 'lp' module should probe the hardware and exit gracefully if
> no parallel port is found, rather than causing a memory corruption
> fault in the kernel's module loading core.
As the kernel is tainted by the nvidia modules, please try to
reproduce the issue without loading the nvidia modules. Once this is
done, please try as well 6.18.2-1~exp1 from experimental, can you then
please provide the full kernel logs with that version (and without
proprietary modules loaded).
Is this additionally an experienced regression from a earlier kernel?
Which was the last worked? If you have one last narrow enough to
6.17.12, can you start a bisect of the upstream kernel and report back
which commit breaks?
Regards,
Salvatore
Reply to: