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

On Tue, Nov 25, 2025 at 02:29:12PM -0800, Mark Millard wrote:
> 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.

I expected that top's cpu percentages would reflect a ratio of time
spent doing something commanded by the OS divided by the two second
update interval.... 

Silly me! Thank you for the enlightenment, 

bob prohaska