XPost: linux.debian.bugs.dist   
   From: yz24wang@gmail.com   
      
   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 于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: 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   
   >   
      
   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    
   39;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 reg   
   rds, YuZhong Wang
Control: tags -1 + moreinfo u   
   reproducible    
       
   On Sat, Dec 27, 2025 at 04:19:02PM +0800, YuZhong Wang wrote:    
   > Package: src:linux    
   > Version: 6.17.12-1    
   > Severity: important    
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|