matthew green writes:
Anders Magnusson writes:
Den 2026-02-19 kl. 04:56, skrev matthew green:
It used to be that you broke into ddb with ESC B, wasn't it?
ah, it's ^E that gets you to the "sim>" prompt, but i still can't get
something for ddb to work.
It's ESC-D on the (MTPR-based) DL11 vax console. It should be the same
on the DZ11-style console, unless someone has done something "creative"
somewhere that broke it. It's checked for at serial IPL, so should
never block.
perfect!! thank you. this works for me.
ok, i downgraded to 256mb ram. 384mb made only 16mb appear. then,
i restarted my netbsd-11 build.
it worked after the system harder-hung (eg, no response from the
console that was logged in as root).
the last "vmstat 10" reported was:
procs memory page disks faults cpu
r b avm fre flt re pi po fr sr r0 r1 in sy cs us sy id
3 0 296520 1248 210 2 1 136 136 240 4 0 111 16 9 75 25 0
and 'fre' had been low for a quite a few 10s of seconds.
from ddb:
db> ps
PID LID S CPU FLAGS STRUCT LWP * NAME WAIT
1866 > 1866 7 0 40000 8d4c80c0 cc1plus
db> bt/a 8d4c80c0
Process 1866.1866
PCB contents:
KSP = 0x94c14c20
ESP = 0x94c13064
SSP = 0x8d4c80c0
USP = 0x7fffc318
R[00] = 0x8fe52300 R[06] = 0x8fe52300
R[01] = 0x8fe52300 R[07] = 0x809f3400
R[02] = 0x8f713900 R[08] = 0x804afe00
R[03] = 0x94c13000 R[09] = 0x8d4c80c0
R[04] = 0x8f713908 R[10] = 0x8027ae4a
R[05] = 0x00000000 R[11] = 0x8023dfce
AP = 0x94c14c68
FP = 0x94c14c3c
PC = 0x80256138
PSL = 0xd80008
Trap frame pointer: 0x94c14fb4
Stack traceback:
0x94c14c3c: 0x2(0x8e72cac0)
it's not 100% hung -- i can continue from ddb and it pings, but the
console remains non-responsive when not in ddb. not even ^T does
anything there. "show uvmexp" from ddb between breaking into it shows
that there are some changes to page usage, but small, eg: