OpenBSD cvs log

created 2020-11-21T19:25:18Z
begin 2020-07-07T00:00:00Z
end 2020-07-08T00:00:00Z
path src/sys
commits 13

date 2020-07-07T00:00:03Z
author dlg
files src/sys/net/ifq.c log diff annotate
src/sys/net/ifq.h log diff annotate
message add kstats for rx queues (ifiqs) and transmit queues (ifqs).

this means you can observe what the network stack is trying to do
when it's working with a nic driver that supports multiple rings.
a nic with only one set of rings still gets queues though, and this
still exports their stats.

here is a small example of what kstat(8) currently outputs for these
stats:

em0:0:rxq:0
packets: 2292 packets
bytes: 229846 bytes
qdrops: 0 packets
errors: 0 packets
qlen: 0 packets
em0:0:txq:0
packets: 1297 packets
bytes: 193413 bytes
qdrops: 0 packets
errors: 0 packets
qlen: 0 packets
maxqlen: 511 packets
oactive: false

date 2020-07-07T01:36:49Z
author dlg
files src/sys/dev/pci/if_vmx.c log diff annotate
src/sys/dev/pci/if_vmxreg.h log diff annotate
message add kstat support for reading the "hardware" counters for each ring.

the counters happen to be a series of uint64_t values in memory,
so we treat them as arrays that get mapped to a series of kstat_kv
structs that are set up as 64 bit counters with either packet or
byte counters as appropriate. this helps keep the code size down.

while we export the counters as separate kstats per rx and tx ring,
you request an update from the hypervisor at the controller level.
this code ratelimits these requests to 1 per second per interface
to try and debounce this a bit so each kstat read doesnt cause a
vmexit.

here's an example of the stats. note that we get to see how many
packets that rx ring moderation drops for the first time. see the
"no buffers" stat.

vmx0:0:rxq:5
packets: 2372483 packets
bytes: 3591909057 bytes
qdrops: 0 packets
errors: 0 packets
qlen: 0 packets
...
vmx0:0:txq:5
packets: 1316856 packets
bytes: 86961577 bytes
qdrops: 0 packets
errors: 0 packets
qlen: 1 packets
maxqlen: 512 packets
oactive: false
...
vmx0:0:vmx-rxstats:5
LRO packets: 0 packets
LRO bytes: 0 bytes
ucast packets: 2372483 packets
ucast bytes: 3591909053 bytes
mcast packets: 0 packets
mcast bytes: 0 bytes
bcast packets: 0 packets
bcast bytes: 0 bytes
no buffers: 696 packets
errors: 0 packets
...
vmx0:0:vmx-txstats:5
TSO packets: 0 packets
TSO bytes: 0 bytes
ucast packets: 1316839 packets
ucast bytes: 86960455 bytes
mcast packets: 0 packets
mcast bytes: 0 bytes
bcast packets: 0 packets
bcast bytes: 0 bytes
errors: 0 packets
discards: 0 packets

date 2020-07-07T02:01:43Z
author deraadt
files src/sys/kern/kern_exec.c log diff annotate
message small typo

date 2020-07-07T02:13:13Z
author jcs
files src/sys/arch/amd64/amd64/efifb.c log diff annotate
message Get rid of some rasops callbacks in efifb that only call rasops
functions in them and let rasops call them directly.

From John Carmack

ok kettenis

date 2020-07-07T02:38:56Z
author dlg
files src/sys/dev/pci/if_ixl.c log diff annotate
message add kstat support for reading hardware counters.

this chip is annoyingly complicated, which is reflected in how
complicated it is to read counters off the chip. while we just use
ixl as a normal network interface, the chip is capable of being a
switch with physical ports, virtual ports and all sorts of other
functionality, and there are counters in different places for all
these different pieces. in our simple setup the driver interface
is mapped to a single physical port which we talk to via a single
virtual switch interface. this diff adds counters on each interface
for the physical port and for the virtual switch interface (vsi).

the port counters show what the hardware is doing, while the vsi
counters show how the driver is interacting with the chip. for
things like packet counters, these numbers tend to correlate strongly,
but there are some differences. if the chip drops packets cos there's
no descriptors on the rx ring, that's shown in the vsi counters.
problems talking to the physical network (eg, packet corruption off
the wire) are reported on the port counters.

on top of the chip just being complicated, reading the counters is
a complicated activity on its own. because the counters can be read
by multiple consumers in a virtualised environment, the counters
never really get reset. they are also stored in annoyingly small
fields. this means you basically have to poll the chip periodically
and calculate differences between the polls to avoid losing numbers
if they overflow too quickly.

date 2020-07-07T02:42:02Z
author dlg
files src/sys/dev/pci/if_ixl.c log diff annotate
message remove some old code from a previous version of the kstat diff.

ixl(4) is only enabled on 64bit archs, so we don't need a 32bit
fallback for the 48 and 64 bit counter reads.

date 2020-07-07T02:45:58Z
author dlg
files src/sys/dev/pci/if_ixl.c log diff annotate
message don't try and be too clever in the kstat update timeout.

date 2020-07-07T04:05:25Z
author cheloha
files src/sys/dev/pci/drm/include/linux/ktime.h log diff annotate
src/sys/dev/pci/drm/include/linux/timekeeping.h log diff annotate
message drm: use hi-res time to implement ktime_get(), ktime_get_real()

There seems to have been some confusion about the granularity of
certain time interfaces in the Linux kernel when our DRM compatibility
layer was written.

To be clear: the Linux ktime_get() and ktime_get_real() interfaces are
*high resolution* clocks. We should to implement them with high
resolution interfaces from our own kernel.

Thus, use microuptime(9) to implement ktime_get() and microtime(9) to
implement ktime_get_real().

While here, ktime_get_raw_ns() should use ktime_get_raw(), not
ktime_get().

Discussed with kettenis@ and jsg@.

ok jsg@

date 2020-07-07T04:42:35Z
author dlg
files src/sys/dev/pci/if_mcx.c log diff annotate
message add kstat support for some of the counters the chip maintains.

mcx keeps a bunch of different counters relating to the port. this
diff adds support for reading them off the hardware and then unpacking
them into kstat_kv structs for userland to look at.

jmatthew@ checked over it.

date 2020-07-07T10:14:35Z
author dlg
files src/sys/dev/pci/if_vmx.c log diff annotate
message apparently vmx(4) needs a power of 2 number of interrupts.

so we pass INTRMAP_POWEROF2 to intrmap_create and things are better.

reported by and fixed by mark patruck. thanks :)

date 2020-07-07T11:54:01Z
author stsp
files src/sys/dev/pci/if_iwx.c log diff annotate
message Switch iwx(4) from -46 to -48 firmware.

The -48 firmware image has been available via fw_update(4) for
about 4 weeks by now. It is contained in iwx-firmware-20191022p1.

date 2020-07-07T12:40:30Z
author dlg
files src/sys/dev/pci/if_ixl.c log diff annotate
message fix a copy pasto.

from netbsd if_ixl.c r1.39 by yamaguchi

date 2020-07-07T22:43:29Z
author kettenis
files src/sys/arch/powerpc64/conf/GENERIC log diff annotate
src/sys/arch/powerpc64/conf/files.powerpc64 log diff annotate
src/sys/arch/powerpc64/dev/opal.c log diff annotate
src/sys/arch/powerpc64/dev/opalsens.c log diff annotate
src/sys/arch/powerpc64/include/opal.h log diff annotate
src/sys/arch/powerpc64/powerpc64/locore.S log diff annotate
message Add opalsens(4), a driver for sensors provided by the OPAL firmware.