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

[Havard Eidnes <he%NetBSD.org@localhost>]

>  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.