Re: kern/57580: evbarm/earmv7hf RPI2 scheduler/cpu stall

[Frank Kardel <kardel%netbsd.org@localhost>]

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

From: Frank Kardel <kardel%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/57580: evbarm/earmv7hf RPI2 scheduler/cpu stall
Date: Sun, 13 Aug 2023 16:58:12 +0200

 Hi Taylor,
 
 ktruss -p 4939 does not seem to do anything, but is interruptible.
 
 perl does not collect an CPU time and if all would be working it should be
 
 yielding the CPU due to scheduling. Somehow the CPU seems be 'lost' before
 
 returning from kernel to user level - just a guess.
 
 As I rebooted, I need to wait again before I can get into the debugger.
 
 HEARTBEAT is in -current not in 10.0_BETA or did I miss a pullup-10?
 
 Frenk
 
 
 On 08/13/23 14:00, Taylor R Campbell wrote:
 >   > So why is CPU 1 not running processes anymore?
 >   
 >   Not sure.  It appears to be here:
 >   
 >   PID    LID S CPU     FLAGS       STRUCT LWP *               NAME WAIT
 >   4939 >4939 7   1   1000000           93f75200               perl
 >   
 >   S = 7 means LSONPROC, meaning the process is currently executing on
 >   the CPU.
 >   
 >   FLAGS = 0x1000000 means LW_PENDSIG, meaning a signal is pending.
 >   
 >   But what's the perl process doing and why can't it make progress?
 >   Unclear.
 >   
 >   Can you enter ddb in this state (not crash(8) -- use C-A-ESC in wskbd
 >   or break at serial console or (set and) type the hw.cnmagic sequence),
 >   and do `mach cpu 1', and then `bt'?  Once you get output, you can do
 >   `continue' to return from ddb.
 >   
 >   If not, can you try enabling `options HEARTBEAT' and `options
 >   HEARTBEAT_MAX_PERIOD=15' in our kernel config and see if you get any
 >   diagnostics out of that?
 >