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