From: Stuart Henderson <stu@spacehopper.org>
Subject: Re: btrace, identifying syscall+0x5c4
To: tech <tech@openbsd.org>
Date: Tue, 3 Dec 2024 13:36:36 +0000

On 2024/12/03 08:27, Martin Pieuchot wrote:
> On 02/12/24(Mon) 23:43, Stuart Henderson wrote:
> > On 2024/12/02 17:47, Martin Pieuchot wrote:
> > > On 02/12/24(Mon) 14:49, Stuart Henderson wrote:
> > hw.ncpu=24 hw.ncpuonline=12 (Xeon E5-2630 v2).
> 
> I wonder if you don't have a piece of software that create a number of
> threads based on ncpu.

It's just a manual setting which I had at 16 parallel (in the past
I had more devices which were pretty slow at responding to SNMP
so it did make sense).

I've reduced that to 12 parallel now, clock time is about the same
and system time and spin looks a little lower in top, though not much.

## 14      1m00.99s real     1m48.33s user     6m52.74s system
## 13      1m03.74s real     1m52.27s user     6m49.06s system
## 12      1m01.88s real     1m46.29s user     6m07.15s system
## 11      1m08.17s real     1m54.57s user     6m02.85s system

> > *cpu1: kernel diagnostic assertion "_kernel_lock_held()" failed: file
> > "/sys/kern/kern_ktrace.c", line 660
> 
> Could you send me the picture of the trace once cpu1?  The one below is
> missing the interesting bits where the panic comes frome.

Sadly there was nothing beyond ktrwriteraw in the trace.

ddb{0}> mach ddbcpu 1
Stopped at x86_ipi_db+0x16: leave
x86_ipi_db(ffff8000494b0ff0) at xB6_ipi_db+0x16
x86_ipi_handler() at x86_ipi_handler+0x80
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x27
x86_bus_space_io_write_1(3d0,4,e) at x86_bus_space_io_write_1+0x1d
pcdisplay_cursor(ffffffff828fb1b8,0,18,1) at pcdisplay_cursor+0xa6
wsemul_vt100_output (ffffffff828d31f0, ffff80004ab46927,1,1) at wsemul_vt100_output+0xc7
wsdisplay_cnputc(c00,6c) at wsdisplay_cnputc+0x65
enputc(6c) at cnputc+0x3b
db_putchar(6c) at db_putchar+0x485
kprintf() at kprintf+0x1351
db_printf(ffffffff823fcb84) at db_printf+0x6d
panic(ffffffff8245b6dd) at panic+0xc2
__assert(ffffffff824123d6,ffffffff8235ac13,294,ffffffff82354e13) at __assert+0x29
ktrwriteraw(ffff800049fae2f8,fffffd87de9767a8,fffffd872f407e40,ffff80004ab46cf0,ffff80004ab46cd0) at ktrwriteraw+0x28f
end trace frame: 0xffff80004ab46d70, count: ©
ddb{1}> _

> > I'll leave it running overnight with that same kernel including the
> > fstat unlock and see if I run into any other issues (without
> > poking it with ktrace).
> 
> Thanks.

It's still happy.