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

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

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

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Frank Kardel <kardel%netbsd.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost
Subject: Re: kern/57580: evbarm/earmv7hf RPI2 scheduler/cpu stall
Date: Sun, 13 Aug 2023 11:56:13 +0000

 > In this state "cpuctl offline 1" gets stuck waiting on "xclocv"
 > wait channel.
 
 This means it's waiting for a low-priority xcall(9) to complete on
 another CPU, presumably cpu1.  The xcall thread for cpu1 is here:
 
 PID    LID S CPU     FLAGS       STRUCT LWP *               NAME WAIT
 0       28 2   1       200           914dd440            xcall/1
 
 S = 2 means LSRUN, meaning the process is runnable but not on the CPU.
 
 FLAGS = 0x200 means LW_SYSTEM, meaning this is a kernel thread, as
 expected -- this is the thread that handles low-priority xcalls.
 
 > 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?