Re: NetBSD/vax 11.0RC1

Den 2026-02-20 kl. 08:30, skrev matthew green:
> 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:
Where is it hung?  I.e.  "bt"?  (It's somewhere in the kernel obviously).

-- R