re: NetBSD/vax 11.0RC1

[matthew green <mrg%eterna23.net@localhost>]

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:

  61855 VM pages: 36633 active, 17954 inactive, 0 wired, 783 free pages  44168 anon, 4925 file, 5512 exec
  61855 VM pages: 36633 active, 17954 inactive, 0 wired, 780 free pages  44168 anon, 4925 file, 5512 exec

(ie, free pages changed).  for other stuff:

  faults=2737982, traps=2844249, intrs=3684080, ctxswitch=7214627 softint=692619, syscalls=4616545
  faults=2737982, traps=2844253, intrs=3685683, ctxswitch=7234639 softint=692803, syscalls=4616545
  faults=2737982, traps=2844257, intrs=3694077, ctxswitch=7340920 softint=693755, syscalls=4616545

so some parts are still quite active... unfortunately, the swap
usage is not changing.


.mrg.