OpenBSD cvs log

created 2020-02-29T18:41:58Z
begin 2020-02-25T00:00:00Z
end 2020-02-26T00:00:00Z
path src/sys
commits 5

date 2020-02-25T02:09:22Z
author cheloha
files src/sys/dev/ic/i82365.c log diff annotate
message pcic(4): i82365.c: tsleep(9) -> tsleep_nsec(9)

Yet another straightforward ticks-to-milliseconds conversion.

I am honestly unsure what particular driver this file belongs to. It
seems to be related to pcic(4) and/or pcmcia(4) so I've marked this
diff with pcic(4) in the summary line.

No complaints on tech@ after six weeks.

date 2020-02-25T10:03:39Z
author mpi
files src/sys/dev/usb/ucycom.c log diff annotate
src/sys/dev/usb/utrh.c log diff annotate
src/sys/dev/usb/utwitch.c log diff annotate
message Prevent buffer overflows by not assuming the report length, given by
the hardware, is necessarily smaller than the length of the on-stack
buffer.

Original fix from Maxime Villard in NetBSD via deraadt@.

date 2020-02-25T13:21:17Z
author mpi
files src/sys/kern/kern_event.c log diff annotate
message Keep function definitions in a single place.

No functional change.

date 2020-02-25T14:24:58Z
author patrick
files src/sys/dev/ic/bwfm.c log diff annotate
src/sys/dev/ic/bwfmvar.h log diff annotate
src/sys/dev/pci/if_bwfm_pci.c log diff annotate
src/sys/dev/sdmmc/if_bwfm_sdio.c log diff annotate
src/sys/dev/usb/if_bwfm_usb.c log diff annotate
message Make bwfm(4) call if_input() only once per interrupt.

This reduces drops caused by the ifq pressure drop mechanism and hence
increases throughput.

ok tobhe@

date 2020-02-25T16:55:33Z
author visa
files src/sys/kern/init_main.c log diff annotate
src/sys/kern/kern_smr.c log diff annotate
src/sys/sys/smr.h log diff annotate
message Start the SMR thread when all CPUs are ready for scheduling. This
prevents the appearance of a "smr: dispatch took N seconds" message
during boot when there is an early smr_call(). Such a call can happen
with mfii(4). The initial dispatch cannot make progress until
smr_grace_wait() can visit all CPUs.

This fix is essentially a hack. It makes use of the fact that there
is no hard guarantee on how quickly the callback of smr_call() gets
invoked. It is assumed that the SMR call backlog does not grow large
during boot.

An alternative fix is to make smr_grace_wait() skip secondary CPUs
until they have been started. However, this could break if the spinup
logic of secondary CPUs was changed.

Delayed SMR dispatch reported and fix tested by Hrvoje Popovski
Discussed with and OK kettenis@, claudio@