created | 2020-12-20T00:32:35Z |
---|---|
begin | 2020-12-15T00:00:00Z |
end | 2020-12-16T00:00:00Z |
path | src/sys |
commits | 10 |
date | 2020-12-15T03:05:31Z | |||
---|---|---|---|---|
author | dlg | |||
files | src/sys/dev/pci/mfii.c | log | diff | annotate |
message |
neuter the shutdown hooks for now, they seem to crash the fw on some boards. grumble grumble |
date | 2020-12-15T03:26:08Z | |||
---|---|---|---|---|
author | dlg | |||
files | src/sys/dev/pci/if_mcx.c | log | diff | annotate |
message |
turn hardware rx mbuf timestamping off by default. we see too many ntp replies (appear to) arrive before the request for them was sent, which ntpd handles by disabling the peer for an hour. this was a lot easier to narrow down after fixing up bpf and timestamps, cos it let me see this: 16:50:36.051696 802.1Q vid 871 pri 3 192.0.2.55.47079 > 162.159.200.123.123: v4 client strat 0 poll 0 prec 0 [tos 0x10] 16:50:36.047201 802.1Q vid 871 pri 3 162.159.200.123.123 > 192.0.2.55.47079: v4 server strat 3 poll 0 prec -25 (DF) im going to borrow the link0 flag for a bit to allow turning timestamping on. |
date | 2020-12-15T03:35:26Z | |||
---|---|---|---|---|
author | dlg | |||
files | src/sys/dev/pci/if_mcx.c | log | diff | annotate |
message |
go to splhigh around the kernel clock and hardware timer reads. the idea is to avoid some other work, like a hardware interrupt, running in between the reads of the kernel and chip clocks and therefore skewing the interval calculations. this tightens up a lot of the slop seen when using the cqe timestamp for an mbuf timestamp, but there's still something not quite right. |
date | 2020-12-15T03:40:29Z | |||
---|---|---|---|---|
author | dlg | |||
files | src/sys/dev/pci/if_mcx.c | log | diff | annotate |
message |
fill in more of mcx_cap_device so i can get to the device frequencies. fun fact, my Connect-x 4 Lx boards seem to run at 156MHz. less fun fact, mcx_calibrate() seems to work that out pretty well anyway, but the maths is still a bit too wonky to make it usable for mbuf timestamps. |
date | 2020-12-15T03:43:34Z | |||
---|---|---|---|---|
author | dlg | |||
files | src/sys/net/if.c | log | diff | annotate |
message |
clear M_TIMESTAMP in if_enqueue. this is to avoid a timestamp being used on the way out of the stack (eg, in bpf), or if it reenters the stack (eg, if it goes between rdomains with pair(4)). |
date | 2020-12-15T04:48:18Z | |||
---|---|---|---|---|
author | visa | |||
files | src/sys/kern/kern_event.c | log | diff | annotate |
message |
Use nkev in place of count in kqueue_scan(). OK cheloha@, mpi@, mvs@ |
date | 2020-12-15T10:23:01Z | |||
---|---|---|---|---|
author | mpi | |||
files | src/sys/sys/rwlock.h | log | diff | annotate |
message |
Add helpers around rw_status(9) to help checking if a lock is held. ok visa@ |
date | 2020-12-15T15:23:48Z | |||
---|---|---|---|---|
author | sashan | |||
files | src/sys/net/pf_osfp.c | log | diff | annotate |
message |
missing NET_LOCK()/NET_UNLOCK() in pf_osfp_flush() OK mpi@ |
date | 2020-12-15T22:14:42Z | |||
---|---|---|---|---|
author | mpi | |||
files | src/sys/uvm/uvm_km.c | log | diff | annotate |
message |
Remove the assertion in uvm_km_pgremove(). At least some initialization code on i386 calls it w/o KERNEL_LOCK(). Found the hardway by jungle Boogie and Hrvoje Popovski. |
date | 2020-12-15T22:51:34Z | |||
---|---|---|---|---|
author | kettenis | |||
files | src/sys/arch/i386/i386/ucode.c | log | diff | annotate |
message |
Use km_alloc(9)/km_free(9) instead of uvm_km_valloc(9)/uvm_km_free(9). These are the preferred interfaces and using them avoids tripping over a kernel lock assertion during early boot. Tested by bluhm@, sthen@ and Hrvoje Popovski. ok mpi@ |