Control: forwarded -1 https://lore.kernel.org/all/aZMt6sSlpKK_JAdT@monoceros

Hello Paul,

On Tue, Feb 10, 2026 at 12:19:45PM +0000, Paul Kerry wrote:
> Subject: linux-image-6.12.69+deb13-amd64: hp_bioscfg mm/page_alloc.c:4802 
> warning
> Package: src:linux
> Version: 6.12.69-1
> Severity: normal
> X-Debbugs-Cc: [email protected]
> Dear Maintainer,
> *** Reporter, please consider answering these questions, where appropriate ***
>    * What led up to the situation?
> Booting a system into the recent debian 6.12.69+deb13-amd64 kernel upgrade 
> from 6.12.63+deb13-amd64

Probably the relevant difference between these two kernel versions is
commit b2e79963525205707c87391a01435cfdc9fc2d1e
(https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.12.y&id=b2e79963525205707c87391a01435cfdc9fc2d1e).

Can you confirm that when booting the older kernel, running

        modprobe hp_bioscfg

will break in the same way as the new kernel? If so, the driver was
broken already before and just unused. You can achieve this behaviour
with 6.12.69, too, by blacklisting the hp_bioscfg module. Either by
adding:

        module_blacklist=hp_bioscfg

on the kernel command line, or

        echo blacklist hp_bioscfg >> /etc/modprobe.d/broken-hp-bioscfg.conf
        update-initramfs -k all -u

>    * What exactly did you do (or not do) that was effective (or
>      ineffective)?
> n/a
>    * What was the outcome of this action?
> dmesg under 6.12.69+deb13-amd64 is now displaying the following...
> [    3.346704] ------------[ cut here ]------------
> [    3.347194] WARNING: CPU: 11 PID: 606 at mm/page_alloc.c:4802 
> __alloc_pages_noprof+0x2a7/0x310

This is

        if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp))
                return NULL;

which is probably triggered by

        bioscfg_drv.enumeration_data = 
kcalloc(bioscfg_drv.enumeration_instances_count,
                                               
sizeof(*bioscfg_drv.enumeration_data), GFP_KERNEL);

I manually determined sizeof(*bioscfg_drv.enumeration_data) to be around
20K. I have no idea about what the driver does here, but it seems to
request more than 2**10 pages continuous pages here which suggests that
bioscfg_drv.enumeration_instances_count, is bigger than 200.

@Jorge: Is that expected?

I dropped much context (mostly automatically collected information about
the machine where this triggered). If you're intested in that, check out
https://bugs.debian.org/1127612.

Best regards
Uwe

Attachment: signature.asc
Description: PGP signature

Reply via email to