| created | 2020-11-19T18:36:59Z |
|---|---|
| begin | 2020-06-17T00:00:00Z |
| end | 2020-06-18T00:00:00Z |
| path | src/sys |
| commits | 25 |
| date | 2020-06-17T00:03:13Z | |||
|---|---|---|---|---|
| author | mortimer | |||
| files | src/sys/dev/pci/emuxki.c | log | diff | annotate |
| message |
Do not do logical negation of a bitshifted field. Prompted by warning from clang 10. ok patrick@ |
|||
| date | 2020-06-17T00:27:52Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/kern/kern_intrmap.c | log | diff | annotate |
| src/sys/sys/intrmap.h | log | diff | annotate | |
| message |
add intrmap, an api that picks cpus for devices to attach interrupts to. there's been discussions for years (and even some diffs!) about how we should let drivers establish interrupts on multiple cpus. the simple approach is to let every driver look at the number of cpus in a box and just pin an interrupt on it, which is what pretty much everyone else started with, but we have never seemed to get past bikeshedding about. from what i can tell, the principal objections to this are: 1. interrupts will tend to land on low numbered cpus. ie, if drivers try to establish n interrupts on m cpus, they'll start at cpu 0 and go to cpu n, which means cpu 0 will end up with more interrupts than cpu m-1. 2. some cpus shouldn't be used for interrupts. why a cpu should or shouldn't be used for interrupts can be pretty arbitrary, but in practical terms i'm going to borrow from the scheduler and say that we shouldn't run work on hyperthreads. 3. making all the drivers make the same decisions about the above is a lot of maintenance overhead. either we will have a bunch of inconsistencies, or we'll have a lot of untested commits to keep everything the same. my proposed solution to the above is this diff to provide the intrmap api. drivers that want to establish multiple interrupts ask the api for a set of cpus it can use, and the api considers the above issues when generating a set of cpus for the driver to use. drivers then establish interrupts on cpus with the info provided by the map. it is based on the if_ringmap api in dragonflybsd, but generalised so it could be used by something like nvme(4) in the future. this version provides numeric ids for CPUs to drivers, but as kettenis@ has been pointing out for a very long time, it makes more sense to use cpu_info pointers. i'll be updating the code to address that shortly. discussed with deraadt@ and jmatthew@ ok claudio@ patrick@ kettenis@ |
|||
| date | 2020-06-17T01:03:57Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/drm/include/linux/atomic.h | log | diff | annotate |
| message |
use WRITE_ONCE and READ_ONCE for set and read ok kettenis@ |
|||
| date | 2020-06-17T01:15:32Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/arch/sparc64/dev/pci_machdep.c | log | diff | annotate |
| src/sys/arch/sparc64/include/pci_machdep.h | log | diff | annotate | |
| message | sparc64 should define __HAVE_PCI_MSIX | |||
| date | 2020-06-17T01:43:04Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/dev/pci/pci.c | log | diff | annotate |
| src/sys/dev/pci/pcivar.h | log | diff | annotate | |
| message |
add pci_intr_msix_count(), to get the msi-x table size for a device. this basically tells us the number of interrupt vectors a pci device is able to support. it relies on the arch having __HAVE_PCI_MSIX defined. without that define it always returns 0. i think this originally came from haesbart via patrick@ as amd64 md code in the middle of a diff from 2018(!), but i've tweaked it to make it MI. tested on sparc64 and amd64 with various drivers. |
|||
| date | 2020-06-17T02:06:05Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/drm/include/linux/kref.h | log | diff | annotate |
| message | kref_sub() interface was removed from linux and is unused | |||
| date | 2020-06-17T02:58:15Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/drm/include/linux/kref.h | log | diff | annotate |
| message | use atomic_set() in kref_init() | |||
| date | 2020-06-17T03:01:26Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/kern/kern_intrmap.c | log | diff | annotate |
| src/sys/sys/intrmap.h | log | diff | annotate | |
| message |
make intrmap_cpu return a struct cpu_info *, not a "cpuid number" thing. requested by kettenis@ discussed with jmatthew@ |
|||
| date | 2020-06-17T03:04:16Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/conf/files | log | diff | annotate |
| message | wire intrmap into the build | |||
| date | 2020-06-17T06:14:52Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/arch/amd64/amd64/acpi_machdep.c | log | diff | annotate |
| src/sys/arch/amd64/amd64/intr.c | log | diff | annotate | |
| src/sys/arch/amd64/include/intr.h | log | diff | annotate | |
| src/sys/arch/amd64/include/pci_machdep.h | log | diff | annotate | |
| src/sys/arch/amd64/isa/isa_machdep.c | log | diff | annotate | |
| src/sys/arch/amd64/pci/pci_machdep.c | log | diff | annotate | |
| message |
pci_intr_establish_cpu() for establishing an interrupt no a specific cpu. the cpu is specified by a struct cpu_info *, which should generally come from an intrmap. this is adapted from a diff that patrick@ sent round a few years ago for a pci_intr_map_msix_cpuid, where you asked for an msi vector on a specific cpu, and then called pci_intr_establish with the handle you get. kettenis pointed out that it's hard on some archs to carry cpu on a pci interrupt handle, so i tweaked it to turn it into a pci_intr_establish_cpu instead. jmatthew@ and i (but mostly jmatthew@ to be honest) have been experimenting with this api on multiple archs and it is working out well. i'm putting this diff in now on amd64 so people can kick the tyres a bit. tested with hacked up vmx(4), ix(4), and mcx(4) |
|||
| date | 2020-06-17T06:17:19Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/arch/i386/pci/pci_machdep.c | log | diff | annotate |
| src/sys/arch/i386/pci/pci_machdep.h | log | diff | annotate | |
| message |
add a dumb pci_intr_establish_cpu(). i386 doesnt support msix, and the interrupt code assumes that it only ties stuff to cpu0. this mostly exists so the api exists for multiq drivers to compile against, but fail with when they try to use it. tested with a hacked up vmx(4). |
|||
| date | 2020-06-17T06:36:17Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/dev/pci/files.pci | log | diff | annotate |
| src/sys/dev/pci/if_vmx.c | log | diff | annotate | |
| message |
enable multiple queues (and interrupts on multiple cpus) on vmx(4). im doing this with vmx(4) because it only exists on two archs (well, one and a half archs really) so any impact is localised. most other drivers i'm working on are enabled on 3 or 4 archs, and we're still working on the interrupt code on those archs. in the meantime vmx(4) can be used as a reference driver on how to implement multiq. it shows the use of rss, toeplitz, intrmap, and interrupts on multiple cpus. it's also a relatively simple device, which makes it easier to understand the above features. note that vmx(4) seems to advertise 25 msi-x vectors. it appears that the intention is that 16 of these vectors are supposed to be used for rx, 8 for tx, and 1 for events (eg, link up and down). we're keeping things simple for now and using a maximum of 8 vectors for both tx and rx, and one for events. this is mostly based on work that jmatthew@ did, but it's simplified now cos intrmap makes things easier. |
|||
| date | 2020-06-17T06:36:56Z | |||
|---|---|---|---|---|
| author | tb | |||
| files | src/sys/net/toeplitz.c | log | diff | annotate |
| message |
Remove some of the unnecessary complications in the calculation of the stoeplitz_cache and bring them into a form more suitable for mathematical reasoning. Add a comment explaining the full construction which will also help justifying upcoming diffs. The observations for the code changes are the following: First, scache->bytes[val] is a uint16_t, and we only need the lower 16 bits of res in the second nested pair of for loops. The values of key[b] are only xored together to compute res, so we only need the lower 16 bits of those, too. Second, looking at the first nested for loop, we see that the values 0..15 of j only touch the top 16 bits of key[b], so we can skip them. For b = 0, the inner loop for j in 16..31 scans backwards through skey and sets the corresponding bits of key[b], so key[0] = skey. A bit of pondering then leads to key[b] = skey << b | skey >> (NBSK - b). The key array is renamed into column since it stores columns of the Toeplitz matrix. It's not very expensive to brute-force verify that scache->bytes[val] remains the same for all values of val and all values of skey. I did this on amd64, sparc64 and powerpc. ok dlg |
|||
| date | 2020-06-17T06:45:22Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/dev/pci/if_mcx.c | log | diff | annotate |
| src/sys/net/fq_codel.c | log | diff | annotate | |
| src/sys/net/if.c | log | diff | annotate | |
| src/sys/net/if_aggr.c | log | diff | annotate | |
| src/sys/net/if_gif.c | log | diff | annotate | |
| src/sys/net/if_gre.c | log | diff | annotate | |
| src/sys/net/if_mpip.c | log | diff | annotate | |
| src/sys/net/if_mpw.c | log | diff | annotate | |
| src/sys/net/if_trunk.c | log | diff | annotate | |
| src/sys/net/ifq.c | log | diff | annotate | |
| src/sys/net/pf.c | log | diff | annotate | |
| src/sys/sys/mbuf.h | log | diff | annotate | |
| message |
make ph_flowid in mbufs 16bits by storing whether it's set in csum_flags. i've been wanting to do this for a while, and now that we've got stoeplitz and it gives us 16 bits, it seems like the right time. |
|||
| date | 2020-06-17T07:08:39Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/dev/pci/if_vmx.c | log | diff | annotate |
| src/sys/dev/pci/if_vmxreg.h | log | diff | annotate | |
| message |
if the chip did rss, use the hash from the chip as an mbuf flowid. another sniped commit from jmatthew@ |
|||
| date | 2020-06-17T08:00:22Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/arch/arm64/dev/mainbus.c | log | diff | annotate |
| message |
Attach secondary CPUs early. Since on most machine we need psci(4) to spin op the secondary CPUs, explicitly probe and attach that driver before we attach the CPUs. This should help with distributing interrupts across CPUs on arm64. ok patrick@, deraadt@, dlg@ |
|||
| date | 2020-06-17T08:18:21Z | |||
|---|---|---|---|---|
| author | stsp | |||
| files | src/sys/dev/pci/if_iwx.c | log | diff | annotate |
| src/sys/dev/pci/if_iwxreg.h | log | diff | annotate | |
| message |
Let iwx(4) firmware decide which Tx rate to use. The firmware will notify the driver when it decides to change Tx rate. Based on those notifications the driver updates the value displayed by ifconfig. This is similar to how bwfm(4) and urtwn(4) handle this. Offloading Tx rate selection should allow us to eventually delete AMRR/MiRA support code from iwx(4). That code is disabled for now, not yet deleted. For now, the driver restricts firmware Tx rate selection to 11n/20MHz mode because that's what net80211 can support. |
|||
| date | 2020-06-17T10:48:44Z | |||
|---|---|---|---|---|
| author | claudio | |||
| files | src/sys/dev/cardbus/if_re_cardbus.c | log | diff | annotate |
| src/sys/dev/cardbus/if_rl_cardbus.c | log | diff | annotate | |
| src/sys/dev/pci/if_re_pci.c | log | diff | annotate | |
| message |
Remove the bus specific sc_ih (interrup handle) variable and use the common sc_ih value of struct rl_softc. This fixes a crash in re(4) because intr_barrier(9) is called with the rl_softc sc_ih which was NULL. OK kettenis@ |
|||
| date | 2020-06-17T14:12:19Z | |||
|---|---|---|---|---|
| author | visa | |||
| files | src/sys/sys/smr.h | log | diff | annotate |
| message |
Expose SMR list and pointer macros to userspace. This enables the use of SMR lists in userspace-visible parts of system headers. In addition, the macros allow libkvm to examine SMR data structures. Initial diff by and OK claudio@ |
|||
| date | 2020-06-17T16:16:05Z | |||
|---|---|---|---|---|
| author | deraadt | |||
| files | src/sys/dev/acpi/acpiutil.c | log | diff | annotate |
| message | needs param.h, not types.h | |||
| date | 2020-06-17T17:54:05Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/arch/powerpc64/powerpc64/bus_dma.c | log | diff | annotate |
| message | Explicitly unmap DMA memory using pmap_kremove(9). | |||
| date | 2020-06-17T18:29:28Z | |||
|---|---|---|---|---|
| author | anton | |||
| files | src/sys/kern/sys_pipe.c | log | diff | annotate |
| src/sys/sys/pipe.h | log | diff | annotate | |
| message |
Instead of performing three distinct allocations per created pipe, reduce it to a single one. Not only should this be more performant, it also solves a kqueue related issue found by visa@ who also requested this change: if you attach an EVFILT_WRITE filter to a pipe fd, the knote gets added to the peer's klist. This is a problem for kqueue because if you close the peer's fd, the knote is left in the list whose head is about to be freed. knote_fdclose() is not able to clear the knote because it is not registered with the peer's fd. FreeBSD also takes a similar approach to pipe allocations. ok mpi@ visa@ |
|||
| date | 2020-06-17T18:58:55Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/arch/powerpc64/include/pmap.h | log | diff | annotate |
| src/sys/arch/powerpc64/powerpc64/pmap.c | log | diff | annotate | |
| message | More pmap bits, mostly from powerpc andd arm64. | |||
| date | 2020-06-17T20:58:20Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/arch/powerpc64/include/cpufunc.h | log | diff | annotate |
| src/sys/arch/powerpc64/powerpc64/cpu.c | log | diff | annotate | |
| message | Print CPU name and cache info in the same way as we do on arm64. | |||
| date | 2020-06-17T23:43:08Z | |||
|---|---|---|---|---|
| author | bru | |||
| files | src/sys/dev/usb/ums.c | log | diff | annotate |
| src/sys/dev/usb/usbdevs | log | diff | annotate | |
| src/sys/dev/usb/usbdevs.h | log | diff | annotate | |
| src/sys/dev/usb/usbdevs_data.h | log | diff | annotate | |
| message |
Fix broken HID descriptors of Elecom trackballs. The report descriptors specify an invalid button count for models with 6 or 8 buttons. Thanks to Sivaram Gowkanapalli, who provided the core of this patch. ok mpi@ |
|||