NetBSD Problem Report #60920
From he@smistad.uninett.no Sat Oct 24 11:02:12 2026
Return-Path: <he@smistad.uninett.no>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits)
client-signature RSA-PSS (2048 bits))
(Client CN "mail.netbsd.org", Issuer "YR1" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 4F8AD1A923C
for <gnats-bugs@gnats.NetBSD.org>; Sat, 24 Oct 2026 11:02:12 +0000 (UTC)
Message-Id: <20261024110203.8315C43FD53@smistad.uninett.no>
Date: Sat, 24 Oct 2026 13:02:03 +0200 (CEST)
From: he@NetBSD.org
Reply-To: he@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: 11.0 kernel for amd64 fails with null pointer deref in uvm_page_redim()
X-Send-Pr-Version: 3.95
X-From4GNATS: "he@NetBSD.org via gnats" <gnats-admin@NetBSD.org>
>Number: 60920
>Category: port-amd64
>Synopsis: 11.0 kernel for amd64 fails with null pointer deref in uvm_page_redim()
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: port-amd64-maintainer
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sat Oct 24 11:05:00 +0000 2026
>Last-Modified: Sun Oct 25 23:10:01 +0000 2026
>Originator: Havard Eidnes
>Release: NetBSD 11.0
>Organization:
I try...
>Environment:
System: [ 1.0000000] NetBSD 11.0 (GENERIC) #0: Thu Jul 30 15:23:12 UTC 2026
[ 1.0000000] mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC
Architecture: x86_64
Machine: amd64
>Description:
Trying to reboot with the GENERIC kernel on this particular
system causes what looks like a null pointer de-reference
in the kernel, ref. (Replacing some greater-then with colons
for the sake of GNATS):
[ 1.0894377] acpicpu14 at cpu14: ACPI CPU
[ 1.0894377] acpicpu15 at cpu15: ACPI CPU
[ 1.0894377] ohci1: 1 scheduling overruns
[ 1.0894377] ohci3: 1 scheduling overruns
[ 1.1450179] uvm_fault(0xffffffff81976e60, 0x0, 2) -: e
[ 1.1450179] fatal page fault in supervisor mode
[ 1.1450179] trap type 6 code 0x2 rip 0xffffffff80cc0282 cs 0x8 rflags 0x10206 cr2 0 ilevel 0x8 rsp 0xffffffff81d56dd0
[ 1.1450179] curlwp 0xffffffff8188bdc0 pid 0.0 lowest kstack 0xffffffff81d512c0
kernel: page fault trap, code=0
Stopped in pid 0.0 (system) at netbsd:uvm_page_redim+0x2f9: addq $0x1,0(%
rdx)
uvm_page_redim() at netbsd:uvm_page_redim+0x2f9
main() at netbsd:main+0x346
ds 2
es 0
fs f3f
gs f000
rdi 108
rsi 820000042
rbp ffffffff81d56eb0
rbx ffff9d08062dc388
rdx 0
rcx 820000000
rax 2
r8 ffffffff81912728 uvm+0x88
r9 2
r10 20
r11 ffff9d0810566190
r12 2
r13 ffffcb8039007180
r14 ffff9d08062dc288
r15 ffffffff81912728 uvm+0x88
rip ffffffff80cc0282 uvm_page_redim+0x2f9
cs 8
rflags 10206
rsp ffffffff81d56dd0
ss 10
netbsd:uvm_page_redim+0x2f9: addq $0x1,0(%rdx)
db{0}: trace
uvm_page_redim() at netbsd:uvm_page_redim+0x2f9
main() at netbsd:main+0x346
db{0}: reboot 104
rebooting...
Booting the old 10.0 kernel it ran before works just fine.
The rest of the boot messages up to the above point are:
[ 1.0000000] WARNING: system needs entropy for security; see entropy(7)
[ 1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
[ 1.0000000] 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013,
[ 1.0000000] 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023,
[ 1.0000000] 2024, 2025, 2026
[ 1.0000000] The NetBSD Foundation, Inc. All rights reserved.
[ 1.0000000] Copyright (c) 1982, 1986, 1989, 1991, 1993
[ 1.0000000] The Regents of the University of California. All rights reserved.
[ 1.0000000] NetBSD 11.0 (GENERIC) #0: Thu Jul 30 15:23:12 UTC 2026
[ 1.0000000] mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC
[ 1.0000000] total memory = 65534 MB
[ 1.0000000] avail memory = 63373 MB
[ 1.0000000] mainbus0 (root)
[ 1.0000000] ACPI: RSDP 0x00000000000FA1D0 000024 (v02 ACPIAM)
[ 1.0000000] ACPI: XSDT 0x00000000DFEA0100 000064 (v01 SMCI 20120512 MSFT 00000097)
[ 1.0000000] ACPI: FACP 0x00000000DFEA0290 0000F4 (v03 051212 FACP0529 20120512 MSFT 00000097)
[ 1.0000000] Firmware Warning (ACPI): 32/64X length mismatch in FADT/Gpe0Block: 64/32 (20241212/tbfadt-748)
[ 1.0000000] ACPI: DSDT 0x00000000DFEA06B0 005B15 (v01 1A811 1A811000 00000000 INTL 20051117)
[ 1.0000000] ACPI: FACS 0x00000000DFEB2000 000040
[ 1.0000000] ACPI: APIC 0x00000000DFEA0390 000158 (v01 051212 APIC0529 20120512 MSFT 00000097)
[ 1.0000000] ACPI: MCFG 0x00000000DFEA04F0 00003C (v01 051212 OEMMCFG 20120512 MSFT 00000097)
[ 1.0000000] ACPI: OEMB 0x00000000DFEB2040 000075 (v01 051212 OEMB0529 20120512 MSFT 00000097)
[ 1.0000000] ACPI: HPET 0x00000000DFEAA6B0 000038 (v01 051212 OEMHPET 20120512 MSFT 00000097)
[ 1.0000000] ACPI: SRAT 0x00000000DFEAA6F0 000220 (v02 AMD AGESA 00000001 AMD 00000001)
[ 1.0000000] ACPI: SLIT 0x00000000DFEAA910 00003C (v01 AMD AGESA 00000001 AMD 00000001)
[ 1.0000000] ACPI: SSDT 0x00000000DFEAA950 002914 (v01 A M I POWERNOW 00000001 AMD 00000001)
[ 1.0000000] ACPI: 2 ACPI AML tables successfully acquired and loaded
[ 1.0000000] ioapic0 at mainbus0 apid 0
[ 1.0000000] cpu0 at mainbus0 apid 32
[ 1.0000000] cpu0: AMD Opteron(TM) Processor 6212 , id 0x600f12
[ 1.0000000] cpu0: node 0, package 0, core 0, smt 0
[ 1.0000000] cpu1 at mainbus0 apid 33
[ 1.0000000] cpu1: AMD Opteron(TM) Processor 6212 , id 0x600f12
[ 1.0000000] cpu1: node 0, package 0, core 1, smt 0
[ 1.0000000] cpu2 at mainbus0 apid 34
[ 1.0000000] cpu2: AMD Opteron(TM) Processor 6212 , id 0x600f12
[ 1.0000000] cpu2: node 0, package 0, core 2, smt 0
[ 1.0000000] cpu3 at mainbus0 apid 35
[ 1.0000000] cpu3: AMD Opteron(TM) Processor 6212 , id 0x600f12
[ 1.0000000] cpu3: node 0, package 0, core 3, smt 0
[ 1.0000000] cpu4 at mainbus0 apid 36
[ 1.0000000] cpu4: AMD Opteron(TM) Processor 6212 , id 0x600f12
[ 1.0000000] cpu4: node 0, package 0, core 4, smt 0
[ 1.0000000] cpu5 at mainbus0 apid 37
[ 1.0000000] cpu5: AMD Opteron(TM) Processor 6212 , id 0x600f12
[ 1.0000000] cpu5: node 0, package 0, core 5, smt 0
[ 1.0000000] cpu6 at mainbus0 apid 38
[ 1.0000000] cpu6: AMD Opteron(TM) Processor 6212 , id 0x600f12
[ 1.0000000] cpu6: node 0, package 0, core 6, smt 0
[ 1.0000000] cpu7 at mainbus0 apid 39
[ 1.0000000] cpu7: AMD Opteron(TM) Processor 6212 , id 0x600f12
[ 1.0000000] cpu7: node 0, package 0, core 7, smt 0
[ 1.0000000] cpu8 at mainbus0 apid 64
[ 1.0000000] cpu8: AMD Opteron(TM) Processor 6212 , id 0x600f12
[ 1.0000000] cpu8: node 0, package 1, core 0, smt 0
[ 1.0000000] cpu9 at mainbus0 apid 65
[ 1.0000000] cpu9: AMD Opteron(TM) Processor 6212 , id 0x600f12
[ 1.0000000] cpu9: node 0, package 1, core 1, smt 0
[ 1.0000000] cpu10 at mainbus0 apid 66
[ 1.0000000] cpu10: AMD Opteron(TM) Processor 6212 , id 0x600f12
[ 1.0000000] cpu10: node 0, package 1, core 2, smt 0
[ 1.0000000] cpu11 at mainbus0 apid 67
[ 1.0000000] cpu11: AMD Opteron(TM) Processor 6212 , id 0x600f12
[ 1.0000000] cpu11: node 0, package 1, core 3, smt 0
[ 1.0000000] cpu12 at mainbus0 apid 68
[ 1.0000000] cpu12: AMD Opteron(TM) Processor 6212 , id 0x600f12
[ 1.0000000] cpu12: node 1, package 1, core 4, smt 0
[ 1.0000000] cpu13 at mainbus0 apid 69
[ 1.0000000] cpu13: AMD Opteron(TM) Processor 6212 , id 0x600f12
[ 1.0000000] cpu13: node 1, package 1, core 5, smt 0
[ 1.0000000] cpu14 at mainbus0 apid 70
[ 1.0000000] cpu14: AMD Opteron(TM) Processor 6212 , id 0x600f12
[ 1.0000000] cpu14: node 1, package 1, core 6, smt 0
[ 1.0000000] cpu15 at mainbus0 apid 71
[ 1.0000000] cpu15: AMD Opteron(TM) Processor 6212 , id 0x600f12
[ 1.0000000] cpu15: node 1, package 1, core 7, smt 0
[ 1.0000000] acpi0 at mainbus0: Intel ACPICA 20241212
[ 1.0000000] acpi0: fixed power button present
[ 1.0000040] hpet0 at acpi0: high precision event timer (mem 0xfed00000-0xfed00400)
[ 1.0894377] attimer1 at acpi0 (TMR, PNP0100): io 0x40-0x43 irq 0
[ 1.0894377] pcppi1 at acpi0 (SPKR, PNP0800): io 0x61
[ 1.0894377] spkr0 at pcppi1: PC Speaker
[ 1.0894377] wsbell at spkr0 not configured
[ 1.0894377] midi0 at pcppi1: PC speaker
[ 1.0894377] sysbeep0 at pcppi1
[ 1.0894377] com0 at acpi0 (UAR1, PNP0501-1): io 0x3f8-0x3ff irq 4
[ 1.0894377] com: ns16550a, 16-byte FIFO
[ 1.0894377] com0: console
[ 1.0894377] com1 at acpi0 (UAR2, PNP0501-2): io 0x2f8-0x2ff irq 3
[ 1.0894377] com1: ns16550a, 16-byte FIFO
[ 1.0894377] RMEM (PNP0C01) at acpi0 not configured
[ 1.0894377] acpibut0 at acpi0 (PWRB, PNP0C0C-170): ACPI Power Button
[ 1.0894377] attimer1: attached to pcppi1
[ 1.0894377] ipmi0 at mainbus0
[ 1.0894377] pci0 at mainbus0 bus 0: configuration mode 1
[ 1.0894377] pchb0 at pci0 dev 0 function 0: ATI Technologies RD890 North Bridge Dual Slot 2x8 GFX (rev. 0x02)
[ 1.0894377] ppb0 at pci0 dev 2 function 0: ATI Technologies RD890 PCI Express Bridge GPP Port B (rev. 0x00)
[ 1.0894377] ppb0: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x8 @ 5.0GT/s
[ 1.0894377] pci1 at ppb0 bus 8
[ 1.0894377] mfi0 at pci1 dev 0 function 0: SAS 9260-8i
[ 1.0894377] mfi0: interrupting at ioapic0 pin 18
[ 1.0894377] mfi0: LSI MegaRAID SAS 9260-8i version 12.12.0-0111
[ 1.0894377] mfi0: logical drives 3, 512MB RAM, BBU type unknown type 5, status good
[ 1.0894377] scsibus0 at mfi0: 64 targets, 8 luns per target
[ 1.0894377] ppb1 at pci0 dev 4 function 0: ATI Technologies RD890 PCI Express Bridge GPP Port D (rev. 0x00)
[ 1.0894377] ppb1: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x4 @ 5.0GT/s
[ 1.0894377] ppb1: link is x4 @ 2.5GT/s
[ 1.0894377] pci2 at ppb1 bus 7
[ 1.0894377] wm0 at pci2 dev 0 function 0: 82576 1000BaseT Ethernet (rev. 0x01)
[ 1.0894377] wm0: interrupting at ioapic0 pin 16
[ 1.0894377] wm0: Ethernet address 00:30:48:f5:15:80
[ 1.0894377] wm0: Copper
[ 1.0894377] igphy0 at wm0 phy 1: i82566 10/100/1000 media interface, rev. 1
[ 1.0894377] igphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
[ 1.0894377] wm1 at pci2 dev 0 function 1: 82576 1000BaseT Ethernet (rev. 0x01)
[ 1.0894377] wm1: interrupting at ioapic0 pin 17
[ 1.0894377] wm1: Ethernet address 00:30:48:f5:15:81
[ 1.0894377] wm1: Copper
[ 1.0894377] igphy1 at wm1 phy 1: i82566 10/100/1000 media interface, rev. 1
[ 1.0894377] igphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
[ 1.0894377] ppb2 at pci0 dev 11 function 0: ATI Technologies RD890 PCI Bridge (NB-SB Link) (rev. 0x00)
[ 1.0894377] ppb2: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x8 @ 5.0GT/s
[ 1.0894377] pci3 at ppb2 bus 2
[ 1.0894377] ppb3 at pci3 dev 0 function 0: PLX Technology product 8624 (rev. 0xbb)
[ 1.0894377] ppb3: PCI Express capability version 2 <Upstream Port of PCI-E Switch>
[ 1.0894377] pci4 at ppb3 bus 3
[ 1.0894377] ppb4 at pci4 dev 4 function 0: PLX Technology product 8624 (rev. 0xbb)
[ 1.0894377] ppb4: PCI Express capability version 2 <Downstream Port of PCI-E Switch> x8 @ 5.0GT/s
[ 1.0894377] pci5 at ppb4 bus 6
[ 1.0894377] ppb5 at pci4 dev 5 function 0: PLX Technology product 8624 (rev. 0xbb)
[ 1.0894377] ppb5: PCI Express capability version 2 <Downstream Port of PCI-E Switch> x8 @ 5.0GT/s
[ 1.0894377] pci6 at ppb5 bus 5
[ 1.0894377] ppb6 at pci4 dev 8 function 0: PLX Technology product 8624 (rev. 0xbb)
[ 1.0894377] ppb6: PCI Express capability version 2 <Downstream Port of PCI-E Switch> x8 @ 5.0GT/s
[ 1.0894377] pci7 at ppb6 bus 4
[ 1.0894377] ahcisata0 at pci0 dev 17 function 0: ATI Technologies SB700-SB900 SATA Controller (AHCI mode) (rev. 0x00)
[ 1.0894377] ahcisata0: AHCI revision 1.10, 4 ports, 32 slots, CAP 0xb720ff83<CCCS,PSC,SSC,PMD,ISS=0x2=Gen2,SCLO,SAL,SALP,SMPS,SSNTF,S64A>
[ 1.0894377] ahcisata0: interrupting at ioapic0 pin 22
[ 1.0894377] atabus0 at ahcisata0 channel 0
[ 1.0894377] atabus1 at ahcisata0 channel 1
[ 1.0894377] atabus2 at ahcisata0 channel 2
[ 1.0894377] atabus3 at ahcisata0 channel 3
[ 1.0894377] ohci0 at pci0 dev 18 function 0: ATI Technologies SB700-SB900 USB OHCI Controller (rev. 0x00)
[ 1.0894377] ohci0: interrupting at ioapic0 pin 16
[ 1.0894377] ohci0: OHCI version 1.0, legacy support
[ 1.0894377] usb0 at ohci0: USB revision 1.0
[ 1.0894377] ohci1 at pci0 dev 18 function 1: ATI Technologies SB700-SB900 USB OHCI Controller (rev. 0x00)
[ 1.0894377] ohci1: interrupting at ioapic0 pin 16
[ 1.0894377] ohci1: OHCI version 1.0, legacy support
[ 1.0894377] usb1 at ohci1: USB revision 1.0
[ 1.0894377] ehci0 at pci0 dev 18 function 2: ATI Technologies SB700-SB900 USB EHCI Controller (rev. 0x00)
[ 1.0894377] ehci0: interrupting at ioapic0 pin 17
[ 1.0894377] ehci0: dropped intr workaround enabled
[ 1.0894377] ehci0: 2 companion controllers, 3 ports each: ohci0 ohci1
[ 1.0894377] ehci0: Using DMA subregion for control data structures
[ 1.0894377] usb2 at ehci0: USB revision 2.0
[ 1.0894377] ohci2 at pci0 dev 19 function 0: ATI Technologies SB700-SB900 USB OHCI Controller (rev. 0x00)
[ 1.0894377] ohci2: interrupting at ioapic0 pin 18
[ 1.0894377] ohci2: OHCI version 1.0, legacy support
[ 1.0894377] usb3 at ohci2: USB revision 1.0
[ 1.0894377] ohci3 at pci0 dev 19 function 1: ATI Technologies SB700-SB900 USB OHCI Controller (rev. 0x00)
[ 1.0894377] ohci3: interrupting at ioapic0 pin 18
[ 1.0894377] ohci3: OHCI version 1.0, legacy support
[ 1.0894377] usb4 at ohci3: USB revision 1.0
[ 1.0894377] ehci1 at pci0 dev 19 function 2: ATI Technologies SB700-SB900 USB EHCI Controller (rev. 0x00)
[ 1.0894377] ehci1: interrupting at ioapic0 pin 19
[ 1.0894377] ehci1: dropped intr workaround enabled
[ 1.0894377] ehci1: 2 companion controllers, 3 ports each: ohci2 ohci3
[ 1.0894377] ehci1: Using DMA subregion for control data structures
[ 1.0894377] usb5 at ehci1: USB revision 2.0
[ 1.0894377] piixpm0 at pci0 dev 20 function 0: ATI Technologies SBx00 SMBus Controller (rev. 0x3d)
[ 1.0894377] piixpm0: interrupting at SMI, polling
[ 1.0894377] iic0 at piixpm0 port 0: I2C bus
[ 1.0894377] ixpide0 at pci0 dev 20 function 1: ATI Technologies IXP IDE Controller (rev. 0x00)
[ 1.0894377] ixpide0: primary channel interrupting at ioapic0 pin 14
[ 1.0894377] atabus4 at ixpide0 channel 0
[ 1.0894377] ixpide0: secondary channel interrupting at ioapic0 pin 15
[ 1.0894377] atabus5 at ixpide0 channel 1
[ 1.0894377] pcib0 at pci0 dev 20 function 3: ATI Technologies SB700-SB900 LPC Host Controller (rev. 0x00)
[ 1.0894377] ppb7 at pci0 dev 20 function 4: ATI Technologies SBx00 PCI to PCI Bridge (rev. 0x00)
[ 1.0894377] pci8 at ppb7 bus 1
[ 1.0894377] vga0 at pci8 dev 4 function 0: Matrox MGA G200eW (rev. 0x0a)
[ 1.0894377] wsdisplay0 at vga0 kbdmux 1
[ 1.0894377] drm at vga0 not configured
[ 1.0894377] ohci4 at pci0 dev 20 function 5: ATI Technologies SB700-SB900 USB OHCI Controller (rev. 0x00)
[ 1.0894377] ohci4: interrupting at ioapic0 pin 18
[ 1.0894377] ohci4: OHCI version 1.0, legacy support
[ 1.0894377] usb6 at ohci4: USB revision 1.0
[ 1.0894377] pchb1 at pci0 dev 24 function 0: AMD Family15h HyperTransport Configuration (rev. 0x00)
[ 1.0894377] pchb2 at pci0 dev 24 function 1: AMD Family15h Address Map Configuration (rev. 0x00)
[ 1.0894377] pchb3 at pci0 dev 24 function 2: AMD Family15h DRAM Configuration (rev. 0x00)
[ 1.0894377] amdnb_misc0 at pci0 dev 24 function 3: AMD NB Misc Configuration
[ 1.0894377] amdtemp0 at amdnb_misc0: AMD CPU Temperature Sensors (Family15h)
[ 1.0894377] pchb4 at pci0 dev 24 function 4: AMD Family15h Link Configuration (rev. 0x00)
[ 1.0894377] pchb5 at pci0 dev 24 function 5: AMD Family15h North Bridge Configuration (rev. 0x00)
[ 1.0894377] pchb6 at pci0 dev 25 function 0: AMD Family15h HyperTransport Configuration (rev. 0x00)
[ 1.0894377] pchb7 at pci0 dev 25 function 1: AMD Family15h Address Map Configuration (rev. 0x00)
[ 1.0894377] pchb8 at pci0 dev 25 function 2: AMD Family15h DRAM Configuration (rev. 0x00)
[ 1.0894377] amdnb_misc1 at pci0 dev 25 function 3: AMD NB Misc Configuration
[ 1.0894377] amdtemp1 at amdnb_misc1: AMD CPU Temperature Sensors (Family15h)
[ 1.0894377] pchb9 at pci0 dev 25 function 4: AMD Family15h Link Configuration (rev. 0x00)
[ 1.0894377] pchb10 at pci0 dev 25 function 5: AMD Family15h North Bridge Configuration (rev. 0x00)
[ 1.0894377] pchb11 at pci0 dev 26 function 0: AMD Family15h HyperTransport Configuration (rev. 0x00)
[ 1.0894377] pchb12 at pci0 dev 26 function 1: AMD Family15h Address Map Configuration (rev. 0x00)
[ 1.0894377] pchb13 at pci0 dev 26 function 2: AMD Family15h DRAM Configuration (rev. 0x00)
[ 1.0894377] amdnb_misc2 at pci0 dev 26 function 3: AMD NB Misc Configuration
[ 1.0894377] amdtemp2 at amdnb_misc2: AMD CPU Temperature Sensors (Family15h)
[ 1.0894377] pchb14 at pci0 dev 26 function 4: AMD Family15h Link Configuration (rev. 0x00)
[ 1.0894377] pchb15 at pci0 dev 26 function 5: AMD Family15h North Bridge Configuration (rev. 0x00)
[ 1.0894377] pchb16 at pci0 dev 27 function 0: AMD Family15h HyperTransport Configuration (rev. 0x00)
[ 1.0894377] pchb17 at pci0 dev 27 function 1: AMD Family15h Address Map Configuration (rev. 0x00)
[ 1.0894377] pchb18 at pci0 dev 27 function 2: AMD Family15h DRAM Configuration (rev. 0x00)
[ 1.0894377] amdnb_misc3 at pci0 dev 27 function 3: AMD NB Misc Configuration
[ 1.0894377] amdtemp3 at amdnb_misc3: AMD CPU Temperature Sensors (Family15h)
[ 1.0894377] pchb19 at pci0 dev 27 function 4: AMD Family15h Link Configuration (rev. 0x00)
[ 1.0894377] pchb20 at pci0 dev 27 function 5: AMD Family15h North Bridge Configuration (rev. 0x00)
[ 1.0894377] isa0 at pcib0
[ 1.0894377] pckbc0 at isa0 port 0x60-0x64
[ 1.0894377] acpicpu0 at cpu0: ACPI CPU
[ 1.0894377] acpicpu1 at cpu1: ACPI CPU
[ 1.0894377] acpicpu2 at cpu2: ACPI CPU
[ 1.0894377] acpicpu3 at cpu3: ACPI CPU
[ 1.0894377] acpicpu4 at cpu4: ACPI CPU
[ 1.0894377] acpicpu5 at cpu5: ACPI CPU
[ 1.0894377] acpicpu6 at cpu6: ACPI CPU
[ 1.0894377] acpicpu7 at cpu7: ACPI CPU
[ 1.0894377] acpicpu8 at cpu8: ACPI CPU
[ 1.0894377] acpicpu9 at cpu9: ACPI CPU
[ 1.0894377] acpicpu10 at cpu10: ACPI CPU
[ 1.0894377] acpicpu11 at cpu11: ACPI CPU
[ 1.0894377] acpicpu12 at cpu12: ACPI CPU
[ 1.0894377] acpicpu13 at cpu13: ACPI CPU
[ 1.0894377] acpicpu14 at cpu14: ACPI CPU
[ 1.0894377] acpicpu15 at cpu15: ACPI CPU
[ 1.0894377] ohci1: 1 scheduling overruns
[ 1.0894377] ohci3: 1 scheduling overruns
[ 1.1450179] uvm_fault(0xffffffff81976e60, 0x0, 2) -: e
[ 1.1450179] fatal page fault in supervisor mode
[ 1.1450179] trap type 6 code 0x2 rip 0xffffffff80cc0282 cs 0x8 rflags 0x10206 cr2 0 ilevel 0x8 rsp 0xffffffff81d56dd0
[ 1.1450179] curlwp 0xffffffff8188bdc0 pid 0.0 lowest kstack 0xffffffff81d512c0
kernel: page fault trap, code=0
Stopped in pid 0.0 (system) at netbsd:uvm_page_redim+0x2f9: addq $0x1,0(%
rdx)
uvm_page_redim() at netbsd:uvm_page_redim+0x2f9
main() at netbsd:main+0x346
and ... the 10.0 kernel proceeds after the above point with:
[ 1.1063496] acpicpu10 at cpu10: ACPI CPU
[ 1.1063496] acpicpu11 at cpu11: ACPI CPU
[ 1.1063496] acpicpu12 at cpu12: ACPI CPU
[ 1.1063496] acpicpu13 at cpu13: ACPI CPU
[ 1.1063496] acpicpu14 at cpu14: ACPI CPU
[ 1.1063496] acpicpu15 at cpu15: ACPI CPU
[ 1.1063496] ohci0: 1 scheduling overruns
[ 4.1923335] scsibus0: waiting 2 seconds for devices to settle...
[ 4.2602178] uhub0 at usb4: NetBSD (0x0000) OHCI root hub (0x0000), class 9/0, rev 1.00/1.00, addr 1
[ 4.3702183] uhub1 at usb2: NetBSD (0x0000) EHCI root hub (0x0000), class 9/0, rev 2.00/1.00, addr 1
[ 4.4702192] uhub2 at usb6: NetBSD (0x0000) OHCI root hub (0x0000), class 9/0, rev 1.00/1.00, addr 1
[ 4.5802199] uhub3 at usb5: NetBSD (0x0000) EHCI root hub (0x0000), class 9/0, rev 2.00/1.00, addr 1
[ 4.6902208] uhub4 at usb3: NetBSD (0x0000) OHCI root hub (0x0000), class 9/0, rev 1.00/1.00, addr 1
[ 4.8002214] uhub5 at usb1: NetBSD (0x0000) OHCI root hub (0x0000), class 9/0, rev 1.00/1.00, addr 1
[ 4.9102224] uhub6 at usb0: NetBSD (0x0000) OHCI root hub (0x0000), class 9/0, rev 1.00/1.00, addr 1
[ 6.3402368] sd0 at scsibus0 target 0 lun 0: <LSI, MR9260-8i, 2.13> disk fixed
[ 6.4202400] sd0: fabricating a geometry
[ 6.4702343] sd0: 931 GB, 953344 cyl, 64 head, 32 sec, 512 bytes/sect x 1952448512 sectors
[ 6.5702350] sd0: fabricating a geometry
[ 6.6202499] sd0: tagged queueing
[ 6.6602418] sd1 at scsibus0 target 1 lun 0: <LSI, MR9260-8i, 2.13> disk fixed
[ 6.7402357] sd1: fabricating a geometry
[ 6.7902359] sd1: 223 GB, 228416 cyl, 64 head, 32 sec, 512 bytes/sect x 467795968 sectors
[ 6.8902369] sd1: fabricating a geometry
[ 6.9402430] sd1: tagged queueing
[ 6.9802440] sd2 at scsibus0 target 2 lun 0: <LSI, MR9260-8i, 2.13> disk fixed
[ 7.0602447] sd2: fabricating a geometry
[ 7.1102391] sd2: 1862 GB, 1906688 cyl, 64 head, 32 sec, 512 bytes/sect x 3904897024 sectors
[ 7.2102394] sd2: fabricating a geometry
[ 7.2602452] sd2: tagged queueing
[ 7.4002451] uhidev0 at uhub4 port 3 configuration 1 interface 0
[ 7.4765649] uhidev0: Winbond Electronics Corp (0x0557) Hermon USB hidmouse Device (0x2221), rev 1.10/0.01, addr 2, iclass 3/1
[ 7.6138532] ums0 at uhidev0: 3 buttons and Z dir
[ 7.6730331] wsmouse0 at ums0 mux 0
[ 7.7115153] uhidev1 at uhub4 port 3 configuration 1 interface 1
[ 7.7822401] uhidev1: Winbond Electronics Corp (0x0557) Hermon USB hidmouse Device (0x2221), rev 1.10/0.01, addr 2, iclass 3/1
[ 7.9202557] ukbd0 at uhidev1
[ 7.9552039] wskbd0 at ukbd0 mux 1
[ 9.6202848] entropy: best effort
[ 14.9803143] ipmi0: ID 32.1 IPMI 2.0 Available
[ 15.0303024] swwdog0: software watchdog initialized
[ 15.1003149] boot device: sd0
[ 15.1403032] root on sd0a dumps on sd0b
[ 15.1803033] root file system type: ffs
[ 15.2303039] kern.module.path=/stand/amd64/10.0/modules
>How-To-Repeat:
Try to run the 11.0 GENERIC kernel on this hardware
and watch it fail.
>Fix:
That would be nice!
>Audit-Trail:
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-amd64/60920: 11.0 kernel for amd64 fails with null pointer deref in uvm_page_redim()
Date: Sat, 24 Oct 2026 12:30:28 -0000 (UTC)
gnats-admin@NetBSD.org ("he@NetBSD.org via gnats") writes:
>[ 1.1450179] uvm_fault(0xffffffff81976e60, 0x0, 2) -: e
>[ 1.1450179] fatal page fault in supervisor mode
>[ 1.1450179] trap type 6 code 0x2 rip 0xffffffff80cc0282 cs 0x8 rflags 0x10206 cr2 0 ilevel 0x8 rsp 0xffffffff81d56dd0
>[ 1.1450179] curlwp 0xffffffff8188bdc0 pid 0.0 lowest kstack 0xffffffff81d512c0
>kernel: page fault trap, code=0
>Stopped in pid 0.0 (system) at netbsd:uvm_page_redim+0x2f9: addq $0x1,0(%
This is uvm_page.c:820
811 if (uvm_page_numa_region != NULL
) {
812 nb = uvm_page_numa_looku
p(pg);
813 } else {
814 nb = atop(VM_PAGE_TO_PHY
S(pg))
815 / uvmexp.ncolors / 8
816 % newnbuckets;
817 }
818 uvm_page_set_bucket(pg, nb);
819 npgb = npgfl.pgfl_buckets[nb];
820 npgb->pgb_nfree++;
npgfl.pgfl_buckets is initialized for newnbuckets (== uvm.bucketcount).
nb is in register %rax:
>rax 2
In the else part, nb is computed modulo newnbuckets and cannot exceed
newnbuckets.
But in the then part, nb can be the id of a NUMA node and it's unclear
if that exceeds newnbuckets.
Can you dump uvm.bucketcount in DDB ?
From: Havard Eidnes <he@NetBSD.org>
To: gnats-bugs@netbsd.org, gnats-admin@NetBSD.org
Cc: port-amd64-maintainer@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: port-amd64/60920: 11.0 kernel for amd64 fails with null
pointer deref in uvm_page_redim()
Date: Sat, 24 Oct 2026 18:22:23 +0200 (CEST)
> Can you dump uvm.bucketcount in DDB ?
If possible, I prefer not to have to shut down this host to do
that. Is there something I can dig out of the running 10.0
system which would give us that information?
But if there is no other way...
Looking at various header files:
#define VM_NFREELIST 6
...
struct uvm {
/* vm_page related parameters */
/* vm_page queues */
struct pgfreelist page_free[VM_NFREELIST]; /* unallocated pages */
u_int bucketcount;
bool page_init_done; /* true if uvm_page_init() finished */
/* page daemon trigger */
int pagedaemon; /* daemon sleeps on this */
struct lwp *pagedaemon_lwp; /* daemon's lid */
};
...
extern struct uvm uvm;
...
#define PGFL_MAX_BUCKETS 8
struct pgfreelist {
struct pgflbucket *pgfl_buckets[PGFL_MAX_BUCKETS];
};
# crash
Crash version 10.0, image version 10.0.
Kernel compiled without options LOCKDEBUG.
Output from a running system is unreliable.
crash> p uvm
ffffffff8190ecc0
crash> x/x,4
uvm: d9b5e000 ffff82fa d9b5e140 ffff82fa
crash>
uvm+0x10: 0 0 0 0
crash>
uvm+0x20: 0 0 0 0
crash>
uvm+0x30: 0 0 0 0
crash>
crash>
uvm+0x40: d9b5e280 ffff82fa d9b5e3c0 ffff82fa
crash>
uvm+0x50: 0 0 0 0
crash>
uvm+0x60: 0 0 0 0
crash>
uvm+0x70: 0 0 0 0
crash>
uvm+0x80: d9b5e500 ffff82fa d9b5e640 ffff82fa
crash>
uvm+0x90: 0 0 0 0
crash>
uvm+0xa0: 0 0 0 0
crash>
uvm+0xb0: 0 0 0 0
crash>
uvm+0xc0: d9b5e780 ffff82fa d9b5e8c0 ffff82fa
crash>
uvm+0xd0: 0 0 0 0
crash>
uvm+0xe0: 0 0 0 0
crash>
uvm+0xf0: 0 0 0 0
crash>
uvm+0x100: d9b5ea00 ffff82fa d9b5eb40 ffff82fa
crash>
uvm+0x110: 0 0 0 0
crash>
uvm+0x120: 0 0 0 0
crash>
uvm+0x130: 0 0 0 0
crash>
uvm+0x140: d9b5ec80 ffff82fa d9b5edc0 ffff82fa
crash>
uvm+0x150: 0 0 0 0
crash>
uvm+0x160: 0 0 0 0
crash>
uvm+0x170: 0 0 0 0
crash>
uvm+0x180: 2 1 0 0
crash>
So bucketcount = 2, at least in 10.0?
and 10.0 probed the CPUs like this:
: {31} dmesg | egrep 'cpu.*node'
[ 1.000004] cpu0: node 0, package 0, core 0, smt 0
[ 1.000004] cpu1: node 0, package 0, core 1, smt 0
[ 1.000004] cpu2: node 0, package 0, core 2, smt 0
[ 1.000004] cpu3: node 0, package 0, core 3, smt 0
[ 1.000004] cpu4: node 0, package 0, core 4, smt 0
[ 1.000004] cpu5: node 0, package 0, core 5, smt 0
[ 1.000004] cpu6: node 0, package 0, core 6, smt 0
[ 1.000004] cpu7: node 0, package 0, core 7, smt 0
[ 1.000004] cpu8: node 0, package 1, core 0, smt 0
[ 1.000004] cpu9: node 0, package 1, core 1, smt 0
[ 1.000004] cpu10: node 0, package 1, core 2, smt 0
[ 1.000004] cpu11: node 0, package 1, core 3, smt 0
[ 1.000004] cpu12: node 1, package 1, core 4, smt 0
[ 1.000004] cpu13: node 1, package 1, core 5, smt 0
[ 1.000004] cpu14: node 1, package 1, core 6, smt 0
[ 1.000004] cpu15: node 1, package 1, core 7, smt 0
: {32}
which seems to be identical to what 11.0 did.
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-amd64/60920: 11.0 kernel for amd64 fails with null pointer deref in uvm_page_redim()
Date: Sat, 24 Oct 2026 18:10:30 -0000 (UTC)
he@NetBSD.org (Havard Eidnes) writes:
>So bucketcount = 2, at least in 10.0?
bucketcount = 2 is a problem if the code touches bucket 2 (only 0 + 1 exist).
From: Havard Eidnes <he@NetBSD.org>
To: gnats-bugs@netbsd.org, gnats-admin@NetBSD.org
Cc: port-amd64-maintainer@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: port-amd64/60920: 11.0 kernel for amd64 fails with null
pointer deref in uvm_page_redim()
Date: Sat, 24 Oct 2026 21:37:53 +0200 (CEST)
> >So bucketcount = 2, at least in 10.0?
>
> bucketcount = 2 is a problem if the code touches bucket 2
> (only 0 + 1 exist).
Well, there's a difference between "index" and "count"; one would
say that one has 2 buckets if they're indexed with 0 and 1, no?
If uvm.bucketcount = newnbuckets = 2, (whatever % newnbuckets)
will be either 0 or 1, no? So are we getting to the crash via
if (uvm_page_numa_region != NULL) {
nb = uvm_page_numa_lookup(pg);
?
# crash
Crash version 10.0, image version 10.0.
Kernel compiled without options LOCKDEBUG.
Output from a running system is unreliable.
crash> x/x uvm_page_numa_region
uvm_page_numa_region: da530c80
crash>
I'll note that I don't quite understand why the last 4 cores are
noted as "node 1" whereas the 4 first in the last package are
"node 0", in
: {33} cat /tmp/11-cpus | egrep 'cpu.*node'
[ 1.0000000] cpu0: node 0, package 0, core 0, smt 0
[ 1.0000000] cpu1: node 0, package 0, core 1, smt 0
[ 1.0000000] cpu2: node 0, package 0, core 2, smt 0
[ 1.0000000] cpu3: node 0, package 0, core 3, smt 0
[ 1.0000000] cpu4: node 0, package 0, core 4, smt 0
[ 1.0000000] cpu5: node 0, package 0, core 5, smt 0
[ 1.0000000] cpu6: node 0, package 0, core 6, smt 0
[ 1.0000000] cpu7: node 0, package 0, core 7, smt 0
[ 1.0000000] cpu8: node 0, package 1, core 0, smt 0
[ 1.0000000] cpu9: node 0, package 1, core 1, smt 0
[ 1.0000000] cpu10: node 0, package 1, core 2, smt 0
[ 1.0000000] cpu11: node 0, package 1, core 3, smt 0
[ 1.0000000] cpu12: node 1, package 1, core 4, smt 0
[ 1.0000000] cpu13: node 1, package 1, core 5, smt 0
[ 1.0000000] cpu14: node 1, package 1, core 6, smt 0
[ 1.0000000] cpu15: node 1, package 1, core 7, smt 0
: {34}
(That's the same with 10.0)
Regards,
- Havard
From: Havard Eidnes <he@NetBSD.org>
To: gnats-bugs@netbsd.org, gnats-admin@NetBSD.org
Cc: port-amd64-maintainer@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: port-amd64/60920: 11.0 kernel for amd64 fails with null
pointer deref in uvm_page_redim()
Date: Sat, 24 Oct 2026 21:54:00 +0200 (CEST)
>> >So bucketcount = 2, at least in 10.0?
>>
>> bucketcount = 2 is a problem if the code touches bucket 2
>> (only 0 + 1 exist).
>
> Well, there's a difference between "index" and "count"; one would
> say that one has 2 buckets if they're indexed with 0 and 1, no?
>
> If uvm.bucketcount = newnbuckets = 2, (whatever % newnbuckets)
> will be either 0 or 1, no? So are we getting to the crash via
>
> if (uvm_page_numa_region != NULL) {
> nb = uvm_page_numa_lookup(pg);
>
> ?
>
> # crash
> Crash version 10.0, image version 10.0.
> Kernel compiled without options LOCKDEBUG.
> Output from a running system is unreliable.
> crash> x/x uvm_page_numa_region
> uvm_page_numa_region: da530c80
> crash>
Some further indication this is the path we got there:
static struct uvm_page_numa_region {
struct uvm_page_numa_region *next;
paddr_t start;
paddr_t size;
u_int numa_id;
} *uvm_page_numa_region;
# crash
Crash version 10.0, image version 10.0.
Kernel compiled without options LOCKDEBUG.
Output from a running system is unreliable.
crash> x/x uvm_page_numa_region
uvm_page_numa_region: da530c80
crash>
uvm_page_numa_region+0x4: ffff82fa
crash> x/x 0xffff82fada530c80
ffff82fada530c80: da530c60
crash> x/x,4
ffff82fada530c80: da530c60 ffff82fa 20000000 c
crash>
ffff82fada530c90: 0 4 3 0
crash> x/x 0xffff82fada530c60
ffff82fada530c60: da530c40
crash> x/x,4
ffff82fada530c60: da530c40 ffff82fa 20000000 8
crash>
ffff82fada530c70: 0 4 2 0
crash> x/x 0xffff82fada530c40
ffff82fada530c40: da530c20
crash> x/x,4
ffff82fada530c40: da530c20 ffff82fa 20000000 4
crash>
ffff82fada530c50: 0 4 1 0
crash> x/x 0xffff82fada530c20
ffff82fada530c20: c708dec0
crash> x/x,4
ffff82fada530c20: c708dec0 ffff8309 0 1
crash>
ffff82fada530c30: 20000000 3 0 0
crash>
So those show numa_id 0, 1, 2 and 3 (in reverse order)?
But why doesn't 10.0 fail, but 11.0 does?
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-amd64/60920: 11.0 kernel for amd64 fails with null pointer deref in uvm_page_redim()
Date: Sat, 24 Oct 2026 23:43:33 -0000 (UTC)
he@NetBSD.org (Havard Eidnes) writes:
>> >So bucketcount = 2, at least in 10.0?
>>
>> bucketcount = 2 is a problem if the code touches bucket 2
>> (only 0 + 1 exist).
>Well, there's a difference between "index" and "count"; one would
>say that one has 2 buckets if they're indexed with 0 and 1, no?
>If uvm.bucketcount = newnbuckets = 2, (whatever % newnbuckets)
>will be either 0 or 1, no? So are we getting to the crash via
> if (uvm_page_numa_region != NULL) {
> nb = uvm_page_numa_lookup(pg);
>?
Either that, or the code is miscompiled.
>I'll note that I don't quite understand why the last 4 cores are
>noted as "node 1" whereas the 4 first in the last package are
>"node 0", in
You have two packages, each made out of two dies, each die
has 4 cores and an L3 cache. That's the 4 NUMA nodes.
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-amd64/60920: 11.0 kernel for amd64 fails with null pointer deref in uvm_page_redim()
Date: Sat, 24 Oct 2026 23:49:13 -0000 (UTC)
he@NetBSD.org (Havard Eidnes) writes:
>So those show numa_id 0, 1, 2 and 3 (in reverse order)?
>But why doesn't 10.0 fail, but 11.0 does?
Maybe -11 clears the array and the stack value is a
"valid" pointer (to something else, but that doesn't
cause a crash) ?
In any case, with 4 NUMA nodes, you need at least 4 buckets
and not 2. Or you also have to reduce the numa-id modulo bucket count.
As a crude workaround you might be able to disable NUMA
in the BIOS.
From: Havard Eidnes <he@NetBSD.org>
To: gnats-bugs@netbsd.org, gnats-admin@NetBSD.org
Cc: port-amd64-maintainer@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: port-amd64/60920: 11.0 kernel for amd64 fails with null
pointer deref in uvm_page_redim()
Date: Sun, 25 Oct 2026 13:52:04 +0100 (CET)
> >So those show numa_id 0, 1, 2 and 3 (in reverse order)?
>
> >But why doesn't 10.0 fail, but 11.0 does?
>
> Maybe -11 clears the array and the stack value is a
> "valid" pointer (to something else, but that doesn't
> cause a crash)?
That sounds somewhat implausible...
> In any case, with 4 NUMA nodes, you need at least 4 buckets
> and not 2. Or you also have to reduce the numa-id modulo bucket count.
Well, I've looked around a bit, and despite this being an area above
my paygrade, let me share a few observations, even though I have not
found the explanation for why 11.0 fails but 10.0 succeeds on this
hardware.
There is the uvm_page_rebucket() function which is supposed to heed
NUMA-based bucket allocation as long as the number of NUMA IDs is
less than PGFL_MAX_BUCKETS, which appears to be 8, and that is done
via
aprint_debug("UVM: using NUMA allocation scheme\n");
...
uvm_page_redim(uvmexp.ncolors, max_numa + 1);
return;
How do I get that debug printout? Does the kernel need to be compiled
with the DEBUG option set, or is it just a matter of supplying the
right option to the "boot" command in the bootloader? Perhaps the
"-x" option?
And uvm_page_rebucket() is called from kern/init_main.c's configure2()
function, and that appears to be done both in 10.0 and 11.0.
But, hmm, x86's cpu_vm_init() calls
aprint_debug_dev(ci->ci_dev, "%d page colors\n", ncolors);
uvm_page_recolor(ncolors);
and uvm_page_recolor() is just a wrapper around uvm_page_redim().
But cpu_vm_init() does not appear to take the number of NUMA nodes in
the system into account when calculating ncolors, but instead just
looks at the caches on the (single?!?) CPU and their associativity?
But ... by the looks of it, this is the same in both 10.0 and 11.0
sources.
> As a crude workaround you might be able to disable NUMA
> in the BIOS.
I thought that the presence or absence of NUMA was a characteristic of
the actual hardware, and not something which can be turned on or off?
Besides, this is a regression, so I'd prefer we find a "proper fix".
BTW, the asymmetry I find confusing:
[ 1.000004] cpu0: node 0, package 0, core 0, smt 0
[ 1.000004] cpu1: node 0, package 0, core 1, smt 0
[ 1.000004] cpu2: node 0, package 0, core 2, smt 0
[ 1.000004] cpu3: node 0, package 0, core 3, smt 0
[ 1.000004] cpu4: node 0, package 0, core 4, smt 0
[ 1.000004] cpu5: node 0, package 0, core 5, smt 0
[ 1.000004] cpu6: node 0, package 0, core 6, smt 0
[ 1.000004] cpu7: node 0, package 0, core 7, smt 0
[ 1.000004] cpu8: node 0, package 1, core 0, smt 0
[ 1.000004] cpu9: node 0, package 1, core 1, smt 0
[ 1.000004] cpu10: node 0, package 1, core 2, smt 0
[ 1.000004] cpu11: node 0, package 1, core 3, smt 0
[ 1.000004] cpu12: node 1, package 1, core 4, smt 0
[ 1.000004] cpu13: node 1, package 1, core 5, smt 0
[ 1.000004] cpu14: node 1, package 1, core 6, smt 0
[ 1.000004] cpu15: node 1, package 1, core 7, smt 0
So for package 0, all the 8 CPU cores are "on the same node", node 0.
But for package 1, the first 4 CPU cores are on the same node as all
the cores in package 0, but the last 4 CPU cores are on a "node" of
itself? Not being intimately familiar with the architecture at this
level, I naively thoght that "node" came before "package" in the
enumeration hierarchy, but evidently that is not the case.
And a "package" is the same as a what I insert in a physical CPU
socket, right?
And ... how do we get from the above to 4 NUMA IDs? So a NUMA ID is
not the same as "node number"?
Regards,
- Havard
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-amd64/60920: 11.0 kernel for amd64 fails with null pointer deref in uvm_page_redim()
Date: Sun, 25 Oct 2026 23:08:06 -0000 (UTC)
he@NetBSD.org (Havard Eidnes) writes:
> aprint_debug("UVM: using NUMA allocation scheme\n");
> Perhaps the
>"-x" option?
Yes.
>I thought that the presence or absence of NUMA was a characteristic of
>the actual hardware, and not something which can be turned on or off?
It's a characteristic you can handle or ignore.
>So for package 0, all the 8 CPU cores are "on the same node", node 0.
>But for package 1, the first 4 CPU cores are on the same node as all
>the cores in package 0, but the last 4 CPU cores are on a "node" of
>itself?
That sounds broken. For your CPU, the NUMA nodes are aligned with
the L3 caches (one per die).
>And a "package" is the same as a what I insert in a physical CPU
>socket, right?
That's what it should represent.
>And ... how do we get from the above to 4 NUMA IDs? So a NUMA ID is
>not the same as "node number"?
aprint_normal_dev(ci->ci_dev, "node %u, package %u, core %u, smt %u\n",
ci->ci_numa_id, ci->ci_package_id, ci->ci_core_id, ci->ci_smt_id);
looks like it.
(Contact us)
$NetBSD: query-full-pr,v 1.51 2026/08/10 02:28:17 riastradh Exp $
$NetBSD: gnats_config.sh,v 1.10 2026/05/13 22:00:09 riastradh Exp $
Copyright © 1994-2026
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home