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
