#1150523 linux-image-6.1.0-53-amd64: repeatable early-boot general protection faults in __kmem_cache_alloc_node

#1150523#5
Date:
2026-10-10 10:45:56 UTC
From:
To:
Dear Debian Kernel Team,

I am reporting a reproducible early-boot kernel failure with the Debian Bookworm kernel image 6.1.0-53-amd64 (package version 6.1.187-1) on an HPE ProLiant DL385 Gen10 Plus.

The failure occurs approximately 7–9 seconds after boot starts. The machine becomes unusable during early boot. The iLO virtual console stops updating/responding, and its virtual keyboard no longer works. The system does not reach normal userspace.

The previous installed kernel, 6.1.0-42-amd64 (package version 6.1.159-1), boots and runs normally on the same machine. It was selected as the GRUB default as a precaution. I have not yet retested 6.1.0-53 with additional debugging parameters because this is a production server and I do not currently have a maintenance window.

The persistent pstore logs contain multiple general protection faults in the 6.1.0-53 boot attempts. The first recorded fault is:

    general protection fault, probably for non-canonical address 0x90f173d9b306f676: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 0 PID: 18 Comm: kworker/0:1 Not tainted 6.1.0-53-amd64 #1 Debian 6.1.187-1
    Hardware name: HPE ProLiant DL385 Gen10 Plus/ProLiant DL385 Gen10 Plus, BIOS A42 05/11/2020
    Workqueue: events drm_fb_helper_damage_work [drm_kms_helper]
    RIP: __kmem_cache_alloc_node+0x12e/0x2a0

Its call trace includes:

    mgag200_crtc_atomic_duplicate_state
    drm_atomic_get_crtc_state
    drm_atomic_get_plane_state
    drm_atomic_helper_dirtyfb
    drm_fb_helper_damage_work

A subsequent fault in another pstore record has the same failure location in the allocator, with a different invalid address:

    general protection fault, probably for non-canonical address 0x20d4bc48444b12e8: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.1.0-53-amd64 #1 Debian 6.1.187-1
    Workqueue: events drm_fb_helper_damage_work [drm_kms_helper]
    RIP: __kmem_cache_alloc_node+0x12e/0x2a0

The same invalid address then appears in several further faults in that boot attempt. Other failing call paths include:

    lpfc_sli4_enable_intr
    lpfc_pci_probe_one
    pci_alloc_irq_vectors_affinity

and:

    xhci_debugfs_create_slot
    xhci_alloc_dev
    usb_alloc_dev
    hub_event

There is also an oops while a systemd-spawned process is executing a program. The repeated faults are all reported in __kmem_cache_alloc_node and appear to involve a corrupted allocator freelist, but I cannot identify the original writer from the available logs. The first visible fault is in the mgag200 framebuffer workqueue; lpfc and other workqueues fault shortly afterwards. I am therefore not claiming that any one of these drivers is conclusively the root cause.

The pstore data came from at least two failed boots of 6.1.0-53. One record reports four faults between approximately 7.24 and 7.56 seconds after boot; another reports three faults between approximately 8.58 and 8.77 seconds. The failing addresses differ between boots.

Relevant system information:

    System: HPE ProLiant DL385 Gen10 Plus
    BIOS: A42, dated 2020-05-11
    iLO: iLO 5, firmware 2.18 (2020-06-22)
    CPU: Vendor ID: AuthenticAMD
   Model name:  AMD EPYC 7452 32-Core Processor
   CPU family: 23
    Currently working kernel: 6.1.0-42-amd64
    Failing kernel: 6.1.0-53-amd64
    Failing kernel package: 6.1.187-1
    Previous kernel package: 6.1.159-1
    amd64-microcode package: 3.20250311.1~deb12u1
    Microcode patch level logged at boot: 0x0830107c
    GPU: NVIDIA Quadro RTX 4000
    Fibre Channel driver: lpfc 14.2.0.7
    lpfc srcversion on 6.1.0-42: 5F65565DAB46D9D96AD7353
    lpfc srcversion on 6.1.0-53: 767EF98BC07E5CCEBC4BE40

The 6.1.0-53 kernel image is the Debian package linux-image-6.1.0-53-amd64, version 6.1.187-1, from source package linux-signed-amd64 (6.1.187+1). The installed image passes `dpkg -V` with no output. The package was available from bookworm-security according to apt-cache policy.

The same early-boot failure also occurred after the system upgrade on 2026-10-09. The upgrade installed the 6.1.0-53 kernel and updated many other packages, including systemd/udev, DKMS, and NVIDIA driver packages. The 6.1.0-53 pstore logs show that the nvidia modules were not loaded at the time of the faults. NVIDIA DKMS modules are currently installed for 6.1.0-42 but not for 6.1.0-53. The failing boot was tested before I had a chance to confirm the DKMS build status for that kernel.

I have not yet confirmed whether this is a kernel regression, a driver interaction, or a hardware/firmware issue. The older kernel works on the same hardware. I have not found MCE/ECC errors in the journal output examined so far, but I have not yet reviewed/exported the iLO Integrated Management Log and Active Health System Log.

Could you advise:
1. Whether this matches a known issue in Debian kernel 6.1.187-1 or in the mgag200/lpfc/SLUB code paths.
2. What additional diagnostics would be useful before I schedule a controlled retest.
3. Whether there is a recommended kernel version or workaround to test on this HPE platform.

I can provide the complete pstore logs and additional diagnostic output. The pstore files are attached to this report.

Regards,
Sandi Hunyadi
linux.support@nib.si