Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #90594 > unrolled thread

Bug#1124075: linux-image-6.17.12+deb14-amd64: Kernel Oops (GPF) in idempotent_init_module when loading lp module

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1124075: linux-image-6.17.12+deb14-amd64: Kernel Oops (GPF) in idempotent_init_module when loading lp module Salvatore Bonaccorso <carnil@debian.org> - 2025-12-27 21:20 +0100
    Bug#1124075: linux-image-6.17.12+deb14-amd64: Kernel Oops (GPF) in idempotent_init_module when loading lp module yuzh wang <yz24wang@gmail.com> - 2025-12-28 19:00 +0100

#90594 — Bug#1124075: linux-image-6.17.12+deb14-amd64: Kernel Oops (GPF) in idempotent_init_module when loading lp module

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

[toc] | [next] | [standalone]

#90596

[Multipart message — attachments visible in raw view] — view raw

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 <carnil@debian.org> 于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
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web