Re: Interrupts hover above 40% when idle on Dell Latitude E7450

2022-01-29 Thread Scott Cheloha
On Mon, Jan 10, 2022 at 10:36:41AM -0500, Ryan Kavanagh wrote:
> >Synopsis:high interrupt processing time on Dell Latitude E7450
> >Category:kernel amd64
> >Environment:
>   System  : OpenBSD 7.0
>   Details : OpenBSD 7.0-current (GENERIC.MP) #242: Sat Jan  8 
> 12:33:38 MST 2022
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
> 
> I installed OpenBSD 7.0 on a Dell Latitude E7450. The installer had me
> using GENERIC, and interrupts hovered above 40%-45% when idle. I
> upgraded to 7.0-current with the same issue. The laptop ran hot,
> presumably as a result of the high interrupt processing time.
> 
> Here is the output of vmstat -i under 7.0-current / GENERIC:
> 
> interrupt   total rate
> irq0/clock 885333   99
> irq96/acpi0  17890
> irq144/inteldrm0   117024   13
> irq114/em0  124141
> irq176/azalia1   16680
> irq115/iwm0416586   47
> irq102/ehci0  2210
> irq103/ahci0   124340   14
> irq104/ichiic0   17700
> irq145/pckbc0   177101
> irq146/pckbc0   445885
> Total 1623443  183
> 
> Stuart Henderson suggested in the misc thread [0] that I try GENERIC.MP.
> After switching, top shows that CPU0 is spending roughly the same amount
> of time processing interrupts, while CPU1 is free to do other stuff.
> Representative capture:
> 
> CPU0 states: 18.6% user,  0.0% nice,  3.0% sys,  0.2% spin, 44.3% intr,
> 33.9% idle
> CPU1 states: 50.3% user,  0.0% nice,  5.0% sys,  1.6% spin,  0.0% intr,
> 43.1% idle
> 
> `systat vm` shows an Int% hovering around 20% (I imagine it's the mean
> of the two interrupt rates shown by top), with lows in the low 10% and
> highs in the low 30%.
> 
> My laptop does not seem to get as hot as quickly under GENERIC.MP, but
> it still gets pretty hot: hw.sensors.cpu0.temp0=86.00 degC after 5
> minutes when watching a video on Youtube in firefox.
> 
> vmstat -i under GENERIC.MP after being up ~35 minutes with light load:
> 
> interrupt   total rate
> irq0/clock 860124  399
> irq0/ipi   714019  331
> irq96/acpi0   4360
> irq144/inteldrm033945   15
> irq114/em0   79653
> irq176/azalia1  10
> irq115/iwm0 73471   34
> irq102/ehci0   730
> irq103/ahci044676   20
> irq104/ichiic04310
> irq145/pckbc064412
> irq146/pckbc031781
> Total 1744760  810
> 
> I ran
> 
> btrace -e 'profile:hz:100 { @[kstack] = count(); }' > /tmp/btrace.out
> 
> for ten seconds and ran the output through
> 
> https://github.com/brendangregg/FlameGraph/raw/master/stackcollapse-bpftrace.pl
> https://github.com/brendangregg/FlameGraph/raw/master/flamegraph.pl
> 
> The output of stackcollapse-bpftrace.pl and flamegraph.pl are attached
> as btrace.collapsed and btrace.svg.

The flamegraph suggests that you spent 10% of that time servicing
ichiic(4) interrupts from idle.

That could be a fluke though.

What does the main systat view look like in the interrupt column?

$ systat 1



Re: crash on booting GENERIC.MP since upgrade to Jan 18 snapshot

2022-01-29 Thread Martin Pieuchot
On 28/01/22(Fri) 23:03, Thomas Frohwein wrote:
> On Sat, 29 Jan 2022 15:19:20 +1100
> Jonathan Gray  wrote:
> 
> > does this diff to revert uvm_fault.c rev 1.124 change anything?
> 
> Unfortunately no. Same pmap error as in the original bug report occurs
> with a kernel with this diff.

Could you submit a new bug report?  Could you manage to include ps and the
trace of all the CPUs when the pmap corruption occurs?

Do you have some steps to reproduce the corruption?  Which program is
currently running?  Is it multi-threaded?  What is the simplest scenario
to trigger the corruption?



Re: Athn driver or net80211 stack not prioritizing incoming WPA handshake frames properly

2022-01-29 Thread Mikolaj Kucharski
I see this problem too on both of mine APU3 access points with:

athn0 at pci4 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 5 int 16
athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:34:e4:23

I had it on my long waiting todo list to open a bug report for this
problem, but real life..

-- 
Regards,
 Mikolaj