rpi2 head -r327485 (e.g.): rpi2 leaves one "CPU n" always idle for some boots
Mark Millard
markmi at dsl-only.net
Tue Jan 2 19:48:51 UTC 2018
I've seen this over many versions of head for months
but have never managed to find a way to force it to
happen. It just shows up once and a while.
Thus, I'm just dumping out some top and kernel information
here for reference. I've used:
openssl speed 1>/dev/null 2>&1 &
openssl speed 1>/dev/null 2>&1 &
openssl speed 1>/dev/null 2>&1 &
openssl speed 1>/dev/null 2>&1 &
to give the rpi2 4 active processes. Various outputs
are from different times without a reboot between.
top -CaePores shows the likes of:
PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME CPU COMMAND
614 root 1 20 0 10452K 10480K 0K select 1 0:00 0.03% /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f /var/db/ntpd.drift
661 root 1 52 0 9984K 6132K 0K select 1 0:00 0.00% /usr/sbin/sshd
751 root 1 101 0 7256K 4276K 0K RUN 1 0:28 99.57% openssl speed
750 root 1 100 0 7256K 4276K 0K CPU0 0 0:32 94.83% openssl speed
753 root 1 86 0 7256K 4276K 0K RUN 3 0:13 52.36% openssl speed
752 root 1 86 0 7256K 4276K 0K CPU3 3 0:14 46.54% openssl speed
363 root 1 20 0 6428K 3840K 0K select 3 0:00 0.00% /sbin/devd
. . .
and:
last pid: 754; load averages: 3.70, 2.38, 1.58 up 0+00:16:50 01:59:37
21 processes: 5 running, 16 sleeping
CPU 0: 94.9% user, 0.0% nice, 0.0% system, 5.1% interrupt, 0.0% idle
CPU 1: 99.6% user, 0.0% nice, 0.0% system, 0.4% interrupt, 0.0% idle
CPU 2: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 3: 100% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle
Mem: 12M Active, 1136K Inact, 56M Wired, 30M Buf, 722M Free
Swap: 1536M Total, 6M Free
From problem boot to problem boot, the CPU that stays
idle has varied but usually has been CPU 2. I've never
seen 2 or more stuck in idle.
show allpcpu shows the likes of:
db> show allpcpu
Current CPU: 0
cpuid = 0
dynamic pcpu = 0x3d2540
curthread = 0xd8478ae0: pid 2032 tid 100150 "openssl"
curpcb = 0xd852ae98
fpcurthread = 0xd8478ae0: pid 2032 "openssl"
idlethread = 0xc376fae0: tid 100002 "idle: cpu0"
curpmap = 0xd8e43bf4
curvnet = 0
cpuid = 1
dynamic pcpu = 0x3998540
curthread = 0xd7e5b3a0: pid 2031 tid 100173 "openssl"
curpcb = 0xda7e0e98
fpcurthread = 0xd7e5b3a0: pid 2031 "openssl"
idlethread = 0xc376f740: tid 100003 "idle: cpu1"
curpmap = 0xd8e43ec4
curvnet = 0
cpuid = 2
dynamic pcpu = 0x3999540
curthread = 0xc376f3a0: pid 10 tid 100004 "idle: cpu2"
curpcb = 0xc378ae98
fpcurthread = none
idlethread = 0xc376f3a0: tid 100004 "idle: cpu2"
curpmap = 0
curvnet = 0
cpuid = 3
dynamic pcpu = 0x399a540
curthread = 0xd8477000: pid 2034 tid 100167 "openssl"
curpcb = 0xd876de98
fpcurthread = 0xd8477000: pid 2034 "openssl"
idlethread = 0xc376f000: tid 100005 "idle: cpu3"
curpmap = 0xc377ab04
curvnet = 0
In other words: it appears that the cpuN (here cpu2) is
left with idle scheduled all the time for some reason.
ps from db> shows things like:
db> ps
pid ppid pgrp uid state wmesg wchan cmd
2034 714 2034 0 R+ openssl
2033 714 2033 0 R+ CPU 3 openssl
2032 714 2032 0 R+ CPU 0 openssl
2031 714 2031 0 R+ CPU 1 openssl
(then later:)
db> ps
pid ppid pgrp uid state wmesg wchan cmd
2034 714 2034 0 R+ CPU 3 openssl
2033 714 2033 0 R+ openssl
2032 714 2032 0 R+ CPU 0 openssl
2031 714 2031 0 R+ CPU 1 openssl
There is also:
10 0 0 0 RL (threaded) [idle]
100002 CanRun [idle: cpu0]
100003 CanRun [idle: cpu1]
100004 CanRun [idle: cpu2]
100005 CanRun [idle: cpu3]
These are from:
# uname -apKU
FreeBSD rpi2 12.0-CURRENT FreeBSD 12.0-CURRENT r327485M arm armv7 1200054 1200054
===
Mark Millard
markmi at dsl-only.net
More information about the freebsd-hackers
mailing list