Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld

On Nov 25, 2025, at 07:48, bob prohaska <[email protected]> wrote:

> On Mon, Nov 24, 2025 at 07:40:21PM -0800, Mark Millard wrote:
>> On Nov 24, 2025, at 18:07, bob prohaska <[email protected]> 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