Re: kern/56932: x68k frequently hangs up after uvm change in 9.99.75

[Chuck Silvers <chuq%chuq.com@localhost>]

The following reply was made to PR kern/56932; it has been noted by GNATS.

From: Chuck Silvers <chuq%chuq.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/56932: x68k frequently hangs up after uvm change in 9.99.75
Date: Thu, 21 Jul 2022 02:21:53 -0700

 On Tue, Jul 19, 2022 at 11:54:37PM +0900, Tetsuya Isaki wrote:
 > At Mon, 18 Jul 2022 10:35:01 +0000 (UTC),
 > Chuck Silvers wrote:
 > >  this system has very very little RAM, so I'll guess that the hang
 > >  is because the system can't allocate memory.  in ddb, please do
 > >  "show uvmexp" and look at the number of free pages, eg.:
 > :
 > >  is the pagedaemon thread running after you notice the hang?
 > 
 > 5 free pages, and pagedaemon seems stuck.
 ...
 > 2nd "show uvmexp" differs only about interrupts, all others are the same.
 > -  faults=26552, traps=30585, intrs=77868, ctxswitch=29271
 > -   softint=13661, syscalls=115885
 > +  faults=26552, traps=30585, intrs=79782, ctxswitch=29854
 > +   softint=13913, syscalls=115885
 
 ok, the pagedaemon is definitely stuck since the pagedaemon counters aren't changing.
 
 
 > >  please show a ddb stack trace from the
 > >  pagedaemon thread to confirm this.
 > 
 > Is this correct stack trace of pagedaemon?
 > |db> ps
 > |PID   LID S CPU   FLAGS    STRUCT LWP *          NAME WAIT
 > |:
 > |0      54 3   0     200          8ab440      pgdaemon tstile
 > |:
 > |db> trace/a 8ab440
 > |trace: pid 0 lid 54 at 0x39abdc8
 > |mi_switch(8ab440,7f7fbc,2d2700,8ab440,15c7be) + 2aa
 > |db>
 
 the pagedaemon thread having a WAIT string of "tstile" is also
 consistent with it being stuck waiting for a lock.
 
 mi_switch() being the innermost stack frame is probably correct,
 but the trace is incomplete... there should be other functions
 in the trace after that, with uvm_pageout() being at the end.
 it will be very hard to figure out what's going on if ddb can't
 report complete stack traces.
 
 try getting a ddb stack trace for a few other threads and see if
 the same problem shows up with every thread.  (it probably will.)
 
 do you know how to figure out what's wrong with the m68k ddb
 stack trace code, or will you need some help with that?
 
 -Chuck