Re: kern/58871: Stuck processes

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Tue, 10 Dec 2024 20:54:45 +0100
> From: Benny Siegert <bsiegert%gmail.com@localhost>
> 
> This happened again, so I did some of the things you said at least:
> 
> Am 03.12.24 um 21:03 schrieb Taylor R Campbell:
> > Can you start crash(8) and get output from `ps', `ps/w', and `show all
> > tstiles'?

Would really like `ps' and `show all tstiles' too next time!

> Is it normal that ps/w prints output continuously until you press Ctrl+C?

Is it just taking a long time or it is going in a loop?  If there's a
lot of processes/threads and the serial console is slow or the CPUs
are busy running other threads it might just take a long time.

> > Can you start crash(8) and stack traces from the processes not in RUN
> > state, like the tstile one with `bt 0t18154'?

Sorry, I meant `bt/t 0t18154'.

> I tried looking at the "find" process in tstile (3770) and the 
> "pipeline.test" process (2534) but got the following. Is this a bug in 
> crash(8)?
> 
> According to htop, process 2534 was hogging 100% of one core. It looks 
> like it was actually spinning on the CPU?
> 
> crash> bt/t 2534
> trace: pid 9524 not found
> crash> bt/t 3770
> trace: pid 14192 not found

You need to use `0t2534' for pid 2534 in decimal; otherwise the input
is read in hexadecimal.  So these should have been:

bt/t 0t2534
bt/t 0t3770

(Whether this is a bug in crash(8) is a matter of perspective...
Certainly it is confusing that the input is interpreted as decimal and
the output is presented in hexadecimal here!)

> Sorry, this is probably not the most helpful answer. When this 
> invariably happens again, I will try the other debugging techniques.

OK, thanks!

> Would it be useful to run with a LOCKDEBUG kernel?

Sure, that could help, but it'll run muuuuuch slower and might paper
over the symptoms by having less concurrency.