Re: port-amd64/60920: 11.0 kernel for amd64 fails with null pointer deref in uvm_page_redim()

["Michael van Elst via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR port-amd64/60920; it has been noted by GNATS.

From: mlelstv%serpens.de@localhost (Michael van Elst)
To: gnats-bugs%netbsd.org@localhost
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@localhost (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.