Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld
Date: Tue, 25 Nov 2025 22:29:12 UTC
On Nov 25, 2025, at 07:48, bob prohaska <fbsd@www.zefox.net> wrote:
> On Mon, Nov 24, 2025 at 07:40:21PM -0800, Mark Millard wrote:
>> On Nov 24, 2025, at 18:07, bob prohaska <fbsd@www.zefox.net> wrote:
>>
>>> A few minutes ago a Pi2 running buildworld for -current locked up again, with no
>>> responsie to the debugger escape.
>>>
>>> The system was swapping fairly hard but not stuck, maybe 600 MB in use, eventually
>>> swap use declined but in minutes it got stuck with top displaying:
>>>
>>> last pid: 51520; load averages: 2.82, 2.96, 2.96 up 1+02:48:27 16:27:58
>>> 57 processes: 3 running, 54 sleeping
>>> CPU: 66.4% user, 0.0% nice, 16.0% system, 0.3% interrupt, 17.4% idle
>>> Mem: 183M Active, 540M Inact, 416K Laundry, 175M Wired, 98M Buf, 19M Free
>>> Swap: 2048M Total, 23M Used, 2025M Free, 1% Inuse
>>>
>>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
>>> 51497 root 5 59 0 352M 208M uwait 3 0:08 161.51% ld.lld
>>> 51518 root 1 101 0 167M 71M CPU1 1 0:03 87.52% cc
>>> 51520 root 1 59 0 167M 72M RUN 2 0:03 67.88% cc
>>> 11811 root 1 0 0 6724K 1456K CPU0 0 5:51 0.46% top
>>> 2047 root 1 0 0 4676K 704K select 0 1:08 0.09% powerd
>>> 2206 bob 1 0 0 14M 1212K select 0 0:46 0.06% sshd-session
>>> 2119 root 1 9 0 14M 2320K select 1 1:27 0.00% sshd
>>>
>>> The over-100% utilization for cpu 3 looks somewhat implausible.
>>
>> It is very plausible based on the above: note that THR
>> (thread count) indicates 5 for ld.lld : It can have more
>> than one core in use at the same time part of the time
>> in order to have 161.51% WCPU. More than core 3 was in
>> use by ld.lld . Some of the information shown is likely
>> specific to the main/original thread.
>>
>> (Top has a display mode that shows one thread per line
>> instead of one process per line. It can also display
>> Thread IDs instead of Process IDs. But PID can sometimes
>> make it easier to identify which threads are part of one
>> process. Non-thread-specific information is replicated.
>> Top can also display more of the command line text.)
>
> I completely misunderstood the meaning of "raw" vs "weighted"
> CPU. Apparently the "raw" value reflects how much more work
> the CPU _could_ be doing, at least in terms of time.
>
WCPU is based on the raw CPU figures but appears to involve
loadaverage relalted information as well.
# sysctl -d kern.ccpu
kern.ccpu: Decay factor used for updating %CPU in 4BSD scheduler
But what I get is:
# sysctl kern.ccpu
kern.ccpu: 0
(Sees odd.)
From the source to top and things it uses . . .
static load_avg ccpu;
. . .
GETSYSCTL("kern.ccpu", ccpu);
/* this is used in calculating WCPU -- calculate it ahead of time */
logcpu = log(loaddouble(ccpu));
. . .
log(loaddouble(0)) does not seem likely.
where:
typedef long pctcpu;
#define pctdouble(p) ((double)(p) / FSCALE)
typedef fixpt_t load_avg;
#define loaddouble(la) ((double)(la) / FSCALE)
. . .
typedef __uint32_t __fixpt_t; /* fixed point number */
. . .
typedef __fixpt_t fixpt_t; /* fixed point number */
. . .
# sysctl -d kern.fscale
kern.fscale: Fixed-point scale factor used for calculating load average values
# sysctl kern.fscale
kern.fscale: 2048
Also:
#define FSHIFT 11 /* bits to right of fixed binary point */
#define FSCALE (1<<FSHIFT)
And:
. . .
fixpt_t ki_pctcpu; /* %cpu for process during ki_swtime */
. . .
u_int ki_swtime; /* Time swapped in or out */
. . .
Back to top source code . . .
. . .
/* define what weighted cpu is. */
#define weighted_cpu(pct, pp) ((pp)->ki_swtime == 0 ? 0.0 : \
((pct) / (1.0 - exp((pp)->ki_swtime * logcpu))))
. . .
#define PCTCPU(pp) (pcpu[pp - pbase])
. . .
sbuf_printf(procbuf, "%6.2f%% ", ps.wcpu ? 100.0 * weighted_cpu(PCTCPU(pp), pp) : 100.0 * PCTCPU(pp));
Note: Some of the references to pctcpu or PCTCPU or %cpu really seem
to be the fraction of the cpu time and so actual percents result after
scaling by 100.
===
Mark Millard
marklmi at yahoo.com