| created | 2019-07-09T07:20:32Z |
|---|---|
| begin | 2019-06-25T00:00:00Z |
| end | 2019-06-26T00:00:00Z |
| path | src/sys |
| commits | 8 |
| date | 2019-06-25T12:37:05Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/usb/ukspan.c | log | diff | annotate |
| message |
avoid uninitialised var access Cody Cutler author of ukspan(4) agrees ok deraadt@ |
|||
| date | 2019-06-25T14:08:57Z | |||
|---|---|---|---|---|
| author | deraadt | |||
| files | src/sys/sys/sysctl.h | log | diff | annotate |
| message |
move new element p_pledge to the tailof kinfo_proc to increase backwards-compat handling. pointed out by sthen, ok millert |
|||
| date | 2019-06-25T14:12:44Z | |||
|---|---|---|---|---|
| author | patrick | |||
| files | src/sys/dev/ic/ahci.c | log | diff | annotate |
| message |
Turn off the code which waits for AHCI_PREG_CMD_CR to be set by the HBA after ahci_default_port_start() sets AHCI_PREG_CMD_ST. The AHCI spec. rev. 1.3 only requires the inverse to be true, i. e. that a HBA clears AHCI_PREG_CMD_CR when AHCI_PREG_CMD_ST gets cleared by software/driver. In fact, some HBAs will not raise AHCI_PREG_CMD_CR as an immediate consequence of AHCI_PREG_CMD_ST being set. Actually neither the FreeBSD, Linux nor NetBSD counterpart of ahci(4) has an analogous check. Disabling that wait fixes "failed to start command DMA on port N, disabling" bails during attach. From Marius Strobl ok deraadt@ jmatthew@ |
|||
| date | 2019-06-25T15:47:28Z | |||
|---|---|---|---|---|
| author | millert | |||
| files | src/sys/kern/kern_descrip.c | log | diff | annotate |
| message |
Return EINVAL not EBADF when trying to lock a non-vnode. This behavior matches POSIX and our own fnctl(2) man page. OK anton@ deraadt@ |
|||
| date | 2019-06-25T16:46:32Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/arch/amd64/include/pci_machdep.h | log | diff | annotate |
| src/sys/arch/amd64/pci/pci_machdep.c | log | diff | annotate | |
| src/sys/arch/arm64/dev/pci_machdep.c | log | diff | annotate | |
| src/sys/arch/arm64/include/pci_machdep.h | log | diff | annotate | |
| src/sys/dev/pci/pci.c | log | diff | annotate | |
| message |
Implement suspend/resume support for MSI-X interrupts. Loosely based on an earlier diff from sf@. ok jmatthew@, also ok mlarkin@, sf@ for a slightly different earlier version |
|||
| date | 2019-06-25T16:46:33Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/dev/pci/pcivar.h | log | diff | annotate |
| message |
Implement suspend/resume support for MSI-X interrupts. Loosely based on an earlier diff from sf@. ok jmatthew@, also ok mlarkin@, sf@ for a slightly different earlier version |
|||
| date | 2019-06-25T22:30:55Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/arch/sparc64/dev/iommu.c | log | diff | annotate |
| message |
add support for bypassing iommu translation managing the translation table entries (TTEs) on an iommu is not free, and is in fact extremely expensive on some platforms. the flip side of this is that forcing dma through TTEs does provide some safety and can help during the development of drivers. however, this has been less true in recent years than it used to be and is less of a concern now, especially considering the performance differences on some platforms. devices have to create dmamaps with BUS_DMA_64BIT to bypass the iommu because the memory window presented to hardware with direct access to memory is at an extremely high address. there's no 32bit bypass access to memory, it has to go through TTEs otherwise. on an m4000 there are several orders of magnitude performance difference between a driver with BUS_DMA_64BIT set and one without it. hilariously, sun used a pci bridge on a whole generation of machines that had broken support for dma addresses over 40 bits (or around there), so devices behind those pci bridges need to have their dmamap_creates intercepted and any potential BUS_DMA_64BIT flags cleared on the way to the iommu drivers. this affects at least v215, v245, and v445, and probably u25s and u45s. it probably explains why all their onboard nics and disk controllers feel super slow, and why there was a meme at sun that bcopy was cheaper than dma when moving packets on and off a nic. ok kettenis@ deraadt@ |
|||
| date | 2019-06-25T22:30:56Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/arch/sparc64/dev/iommureg.h | log | diff | annotate |
| src/sys/arch/sparc64/dev/iommuvar.h | log | diff | annotate | |
| src/sys/arch/sparc64/dev/pci_machdep.c | log | diff | annotate | |
| src/sys/arch/sparc64/dev/psycho.c | log | diff | annotate | |
| src/sys/arch/sparc64/dev/pyro.c | log | diff | annotate | |
| src/sys/arch/sparc64/dev/sbus.c | log | diff | annotate | |
| src/sys/arch/sparc64/dev/schizo.c | log | diff | annotate | |
| src/sys/arch/sparc64/include/pci_machdep.h | log | diff | annotate | |
| message |
add support for bypassing iommu translation managing the translation table entries (TTEs) on an iommu is not free, and is in fact extremely expensive on some platforms. the flip side of this is that forcing dma through TTEs does provide some safety and can help during the development of drivers. however, this has been less true in recent years than it used to be and is less of a concern now, especially considering the performance differences on some platforms. devices have to create dmamaps with BUS_DMA_64BIT to bypass the iommu because the memory window presented to hardware with direct access to memory is at an extremely high address. there's no 32bit bypass access to memory, it has to go through TTEs otherwise. on an m4000 there are several orders of magnitude performance difference between a driver with BUS_DMA_64BIT set and one without it. hilariously, sun used a pci bridge on a whole generation of machines that had broken support for dma addresses over 40 bits (or around there), so devices behind those pci bridges need to have their dmamap_creates intercepted and any potential BUS_DMA_64BIT flags cleared on the way to the iommu drivers. this affects at least v215, v245, and v445, and probably u25s and u45s. it probably explains why all their onboard nics and disk controllers feel super slow, and why there was a meme at sun that bcopy was cheaper than dma when moving packets on and off a nic. ok kettenis@ deraadt@ |
|||