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 Salvatore Bonaccorso <[email protected]> 于2025年12月28日周日 04:02写道： > 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: [email protected] > > User: [email protected] > > 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 >
