riscv64: use evcount_percpu(9) for clock interrupts

ok? Index: clock.c === RCS file: /cvs/src/sys/arch/riscv64/riscv64/clock.c,v retrieving revision 1.6 diff -u -p -r1.6 clock.c --- clock.c 19 Nov 2022 16:02:37 - 1.6 +++ clock.c 30 Nov 2022 19:28:49 - @@ -100,6

help pfsync by extending pf_state_key lifetimes on pf_states

we (mostly sashan@ and me) have a problem where pfsync can be holding a reference to a pf_state that pf has decided to purge, and then pfsync crashes because it tries to read the pf_state_key parts of the state, but they been removed by the purge process. the background to this is that pf_state

Re: ENTRY_NB() on riscv64

On Fri, 2 Dec 2022, Jeremie Courreges-Anglas wrote: > clang emits this warning when compiling brk.S and sbrk.S on riscv64: > > /tmp/sbrk-06c40b.s:46:2: warning: sbrk changed binding to STB_WEAK > .weak sbrk > > Let's avoid this using the "ENTRY_NB" approach implemented by guenther@ > on other

riscv64: drop unused WEAK_REFERENCE macro

WEAK_REFERENCE seems to come from FreeBSD, it's not used in our tree. (WEAK_ALIAS is defined a few lines above). ok? Index: sys/arch/riscv64/include/asm.h === RCS file: /cvs/src/sys/arch/riscv64/include/asm.h,v retrieving

ENTRY_NB() on riscv64

clang emits this warning when compiling brk.S and sbrk.S on riscv64: /tmp/sbrk-06c40b.s:46:2: warning: sbrk changed binding to STB_WEAK .weak sbrk Let's avoid this using the "ENTRY_NB" approach implemented by guenther@ on other archs. Diff tailored to reduce the differences with

Re: AMD pcidevs updates

On Fri, Dec 02, 2022 at 07:10:43PM +1100, Jonathan Gray wrote: > On Wed, Nov 30, 2022 at 07:57:33AM +, Laurence Tratt wrote: > > On Tue, Nov 29, 2022 at 10:42:36PM +, Laurence Tratt wrote: > > > > > The diff below adds some newish AMD elements to pcidevs. > > > > As Mike Larkin kindly

Re: Unlock minherit(2)

On Fri, Dec 02, 2022 at 08:44:09PM +0100, Christian Weisgerber wrote: > The only user of minherit() in base appears to be libc's arc4random. Yes, no other grep hits. > I successfully ran a full amd64 package bulk build with this. Thanks!

Re: Unlock minherit(2)

Klemens Nanni: > This has been running fine through regress and daily usage on my X230 driver > for months, incl. selected ports builds. > > Feedback? Objection? Tests? OK? The only user of minherit() in base appears to be libc's arc4random. I successfully ran a full amd64 package bulk build

Re: run-regress-* targets in bsd.regress.mk

On Fri, Dec 02, 2022 at 02:08:33PM +0100, Theo Buehler wrote: > On Fri, Dec 02, 2022 at 01:52:43PM +0100, Marc Espie wrote: > > On Fri, Dec 02, 2022 at 12:59:02PM +0100, Theo Buehler wrote: > > > I wanted to override some of the default run-regress-* targets by > > > declaring them in regress

Re: run-regress-* targets in bsd.regress.mk

On Fri, Dec 02, 2022 at 01:52:43PM +0100, Marc Espie wrote: > On Fri, Dec 02, 2022 at 12:59:02PM +0100, Theo Buehler wrote: > > I wanted to override some of the default run-regress-* targets by > > declaring them in regress Makefiles. Many tests already do that and > > it happens to work as

Re: run-regress-* targets in bsd.regress.mk

On Fri, Dec 02, 2022 at 12:59:02PM +0100, Theo Buehler wrote: > I wanted to override some of the default run-regress-* targets by > declaring them in regress Makefiles. Many tests already do that and > it happens to work as expected. > > However, this relies on behavior in the BUGS section of

run-regress-* targets in bsd.regress.mk

I wanted to override some of the default run-regress-* targets by declaring them in regress Makefiles. Many tests already do that and it happens to work as expected. However, this relies on behavior in the BUGS section of make. In fact, espie informs me that gmake behaves the other way around and

Re: AMD pcidevs updates

On Wed, Nov 30, 2022 at 07:57:33AM +, Laurence Tratt wrote: > On Tue, Nov 29, 2022 at 10:42:36PM +, Laurence Tratt wrote: > > > The diff below adds some newish AMD elements to pcidevs. > > As Mike Larkin kindly pointed out off-list, I sent a diff to the generated > file. Sorry! With