Options for FBSD support with LCD device - new project [[Maybe related: I2c issues on the Pi2]]
Karl Denninger
karl at denninger.net
Mon Mar 25 16:34:06 UTC 2019
> What do you mean by an insane rate? It's normal for the usb controller
> to be showing around thousands of int/sec. Despite what seems like a
> high rate, even on an on rpi-b it uses under 2% cpu to service that.
>
> root at rpi:~ # vmstat -i
> interrupt total rate
> intc0,2: vchiq0 2 0
> intc0,11: systimer0 10103206 1110
> intc0,17:-x_dwcotg0 218596055 24007
> intc0,28: bcm_dma0 834 0
> intc0,61: iichb0 5778 1
> intc0,65: uart0 1817 0
> intc0,70:-dhci_bcm0 172 0
> Total 228707864 25118
>
> -- Ian
The story gets more odd.
The same *physical* unit that I saw this on last night with no I2c
device connected I restarted this morning -- changing NOTHING -- and it
disappeared.
But -- on another unit it's still there (I haven't shut down, pulled
power and restarted that one.)
vmstat -i on both doesn't show anything all that odd:
root at Pool-MCP:~ # vmstat -i
interrupt total rate
local_intc0,1: + 6007812 1143
local_intc0,8: + 82834082 15754
local_intc0,9: pmu0 86 0
intc0,1: mbox0 268 0
intc0,2: vchiq0 2 0
intc0,17: + 126693883 24096
intc0,28: bcm_dma0 89696 17
intc0,61: iichb0 1 0
intc0,65: uart0 4362 1
intc0,70: + 15620 3
cpu0:rendezvous 47 0
cpu1:rendezvous 28 0
cpu2:rendezvous 48 0
cpu3:rendezvous 53 0
cpu0:preempt 34447 7
cpu1:preempt 177488 34
cpu2:preempt 164474 31
cpu3:preempt 172970 33
cpu0:hardclock 3 0
Total 216195370 41119
This is the instance that is *not* doing it.
The one that is:
root at Pool-MCP:/data/karl # vmstat -i
interrupt total rate
local_intc0,1: + 117213190 1160
local_intc0,3: + 2775590966 27463
local_intc0,8: + 818346159 8097
local_intc0,9: pmu0 1888 0
intc0,1: mbox0 1876 0
intc0,2: vchiq0 2 0
intc0,17: + 2658685185 26306
intc0,28: bcm_dma0 141881 1
intc0,61: iichb0 432618 4
intc0,65: uart0 415 0
intc0,70: + 20556 0
cpu0:rendezvous 80 0
cpu1:rendezvous 94 0
cpu2:rendezvous 62 0
cpu3:rendezvous 62 0
cpu0:ast 1 0
cpu2:ast 4 0
cpu3:ast 2 0
cpu0:preempt 1618359 16
cpu2:preempt 9797849 97
cpu3:preempt 9853072 97
cpu0:hardclock 6 0
Total 6391704327 63243
Both running identical copies of the code (same build, same everything.)
Now, here's the thing -- on the one that's doing it the load average is
1.04 -- only .04 is real as the code running on that box is extremely
efficient (it reads analog I2c inputs and acts on them by flipping
GPIOs, plus reporting status.) The rest is the interrupts but vmstat -i
doesn't show it. "systat -vm", however, DOES:
1 users Load 1.01 1.02 1.00 Mar 25 11:24
Mem usage: 14%Phy 14%Kmem
Mem: KB REAL VIRTUAL VN PAGER SWAP
PAGER
Tot Share Tot Share Free in out
in out
Act 29656 9132 138288 10092 804344 count
All 30308 9768 140020 11808 pages
Proc: Interrupts
r p d s w Csw Trp Sys Int Sof Flt ioflt 530k total
27 948 44 279 9462 103 cow 1166
local_intc
zfod 495k
local_intc
0.2%Sys 0.0%Intr 0.2%User 0.0%Nice 99.6%Idle ozfod 8099
local_intc
| | | | | | | | | | %ozfod
local_intc
daefr
intc0,1: m
dtbuf prcfr
intc0,2: v
Namei Name-cache Dir-cache 30805 desvn totfr 26205
intc0,17:
Calls hits % hits % 30805 numvn react
intc0,28:
2556 2556 100 28399 frevn pdwak 4
intc0,61:
2 pdpgs
intc0,65:
Disks mmcsd intrn
intc0,70:
KB/t 0.00 109716 wire
cpu0:rende
tps 0 6256 act
cpu1:rende
MB/s 0.00 18172 inact
cpu2:rende
%busy 0 laund
cpu3:rende
804344 free
cpu0:ast
55168 buf
cpu2:ast
cpu3:ast
12
cpu0:preem
136
cpu2:preem
91
cpu3:preem
cpu0:hardc
Note the "495k" number. That's real; on the unit that is NOT
misbehaving that's not there, and neither are the missed interrupt
complaints.
But again, last night the one that this morning is NOT misbehaving WAS,
and was showing the exact same thing.
So this looks like something that is not being initialized property at
boot time, and sometimes however it comes up causes trouble, and other
times it does not -- which is likely to make it a "lot" of fun to find.
Specifically, if I had to guess its that there's an interrupt source
that is attached to the CPU but there's no handler for it, and if it
triggers and is not acknowledged it KEEPS triggering. The question is
-- what is it and why is it "on"?
The uboot (and thus implied DTS) package that gets included here on the
build machine is:
u-boot-rpi2-2019.01 Cross-build das u-boot for model rpi2
if that matters -- and it might.....
I'm going to leave both running; if anyone has ideas of things I can
poke to try to figure out why the one that is doing it is, or the other
way around, let me know and I'll dump/poke/whatever to try to find the
answer to this. I'd specifically like to know why "vmstat -i" doesn't
show the source of that ridiculous rate interrupt storm (which IS real,
as the CPU load is real) but "systat -vm" does.
--
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20190325/f04e5ad2/attachment.bin>
More information about the freebsd-arm
mailing list