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@ |