By default we use the ktrace back end, but the /dev/filemon back end
is available as a compile-time option, by setting USE_FILEMON=dev in
make. sjg raised concerns about ktrace performance and would like to
continue using /dev/filemon on FreeBSD (which has seen more
maintenance kernel-side) without forking make.
- rw_downgrade(): do it in a for () loop like all the others.
- Explicitly carry around RW_NODEBUG - don't be lazy.
- Remove pointless macros.
- Don't make assertions conditional on LOCKDEBUG, there's no reason.
- Make space for a new flag bit (not added yet).
* The DRM driver stack is designed to work with cache coherent devices
* only, but permits an optimization to be enabled in some cases, where
* for some buffers, both the CPU and the GPU use uncached mappings,
* removing the need for DMA snooping and allocation in the CPU caches.
*
* The use of uncached GPU mappings relies on the correct implementation
* of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU
* will use cached mappings nonetheless. On x86 platforms, this does not
* seem to matter, as uncached CPU mappings will snoop the caches in any
* case. However, on ARM and arm64, enabling this optimization on a
* platform where NoSnoop is ignored results in loss of coherency, which
* breaks correct operation of the device. Since we have no way of
* detecting whether NoSnoop works or not, just disable this
* optimization entirely for ARM and arm64.
set $whatever
while [ $# - gt 10 ]; do shift 10; done
eval echo \$$#
fails when $# turns out to be 10 (or any multiple), it would need
to be instead
while [ $# -ge 10 ]; do shift 9; done
but there hasn't been a shell that cannot handle ${10} (etc) correctly
in a very long time, so let's just use that instead (properly quoted,
in case IFS happens to contain a digit for some bizarre reason).
We should also "set -f" / "set +f" (or better, restore the prev setting of -f)
around the "set $whatever" part, but if that was ever going to cause a problem
here, it would have already, so leave that for now.
- Track the 64-bit range capability of prefetchable and non-prefetchable
memory separately. Probe the extent maps provided by the caller to
initialize these values. Without this, we never get 64-bit range
capablity on the root bus, and thus are never able to forward it along
to downstream busses.
- Always prefer allocating space for a 64-bit memory BAR > 4GB. We will
fall back on a 32-bit range if no space above 4GB is available.
- Constrain allocation of 32-bit memory BARs (including expansion ROM BARs)
to be below 4GB, even if the window has a larger range available.
- When allocating non-prefetchable memory space for a PCI-PCI bridge, ensure
it falls below 4GB, since a bridge cannot forward a 64-bit non-prefetchable
range.
- Account for expansion ROMs as non-prefetchable memory rather than
prefetchable memory; expansion ROMs have 32-bit BARs, and if a device
with an expansion ROM is downstream of a brige, a 32-bit prefetchable
range might not be available.
Tested by jmcneill@ on an Arm Neoverse N1 SDP, where the previous
code failed to configure all devices correctly.
sun3 port has two definitions for different pmaps for sun3 (pmap3.h)
and sun3x (pmap3x.h) and they are selected by _SUN3_ or _SUN3X_ macro,
but neither of them is defined on module builds so common exported
definitions required by module(7) should be in a common header,
i.e. pmap.h.
Should be pulled up to netbsd-9.
creating a new pool l1ttpl for the userland L1 translation table which
needs to be 8KB and 8KB aligned.
Limit the pool to maxproc and add hooks to allow the sysctl changing of
maxproc to adjust the pool.
This comes at a 5% performance penalty for build.sh -j8 kernel on a
Tegra TK1.
NCQ on (some) drives. Enable this quirk for ATI (AMD) SB600/SB700
controllers. Alternate fix for kern/54790 and kern/54855.
ok jdolecek@, tested on my SB700 chipset and tsutsui's SB600 chipset.
thorpej