am335x, am18xx: make the sdmmc drivers get along with each other
The am18xx and the am335x share a DMA controller used by the sdmmc controller. However, the am335x starts a transfer, then the DMA while the am18xx starts the DMA, then the transfer.
Currently, the DMA driver resets DMA events when starting a transfer, which breaks the am335x because it start the DMA after the transfer, so events can already accumulate. This commit rolls back the change that resets DMA events when starting a transfer.
However, this is now an issue on the am18xx, where due to a hardware quirk, it is possible for DMA events to accumulate on transfers that don't use the DMA. The fix is to always reset the DMA events on transfers with and without DMA.
libc/gen/Makefile.inc Avoid building while cleaning
Don't try and build the user version info for sysctl while
cleaning, the needed tools probably don't exist yet.
Eliminate very low concurrency limit in RAIDframe, improving write throughput as much as 25%.
RAIDframe maintains a per-set freelist of "emergency buffers" to ensure it can perform I/O
under heavy memory pressure. The freelist size was 10, and each I/O request can require
up to 2 buffers in some recovery conditions, so raidPtr->openings was limited to RAIDOUTSTANDING,
which was set to 6 (this was a bug; it should have been 5).
There is no need at all for this limit for RAID 0 or RAID 1 sets; they do not buffer I/O in
the relevant way. Eliminate the allocation entirely in this case; openings is set as the
configured queue length for the RAID set.
For parity RAID sets, we dynamically size two freelists of pre-allocated buffers and the
openings value so that we consume no more than 1% of system RAM per set:
openings = MIN(maxQueueDepth, MAX(RAIDOUTSTANDING, (1% of physmem), bytes_per_opening))
stripe buffers: 2 * openings
I/O buffers: openings * max_stripes_per_bp * numCol
RAIDOUTSTANDING (now used as a floor) remains 6.
[16 lines not shown]
cnmagic(9): minor tweaks
Call it a "magic sequence" (not "magic key sequence") - there are no
"keys" in the serial input and wscons(4) does not even use cnmagic(9),
so. Mention that latter fact in CAVEATS.
Document CNC_BREAK.
cpufreq_dt: communicate full voltage range to regulators
In the last commit, fdtbus_regulator_set_voltage got changed to accept the voltage as a target, min, max triple from a min, max pair. This commit switched the cpufreq code over to sending the full voltage triple to regulators if it is available in the device tree.
This fixes PR 60671
fdtbus_regulator_set_voltage_triple: support target/min/max
Some dt-bindings specify voltages as target/min/max, while the NetBSD fdt subsystem only supported min/max.
This PR introduces fdtbus_regulator_set_voltage_triple that tries to set the voltage to an optimal value before falling back to the full range.
See PR 60671
sun4v: Try to use the hypervisor interrupt api version 2 if version 3 fails.
Version 3 systems are working ok - trying to fix the setup when a version 2
system is used.
Not tested on yet.
riscv: Make comapt32 compile.
Note: I doubt it will work -- cpu_getmcontext32 and cpu_setmcontext32
appear to be missing save/restore of most registers, so signal
delivery will probably trash them. Also not sure whether to use
l->l_private or tf->tf_reg[_REG_TP] here (or _X_TP). TBD!
PR port-riscv/60889: riscv64: compat_netbsd32 is busticated
sys/conf/files: riscv has no EXEC_AOUT either even for compat32.
Do the same ifdef dance as for mips and arm.
Fixes:
> /home/riastradh/netbsd/current/src/sys/compat/netbsd32/netbsd32_exec_aout.c: In function 'exec_netbsd32_makecmds':
> /home/riastradh/netbsd/current/src/sys/compat/netbsd32/netbsd32_exec_aout.c:119:15: error: 'NETBSD32_MID_MACHINE' undeclared (first use in this function)
> 119 | case (NETBSD32_MID_MACHINE << 16) | ZMAGIC:
> | ^~~~~~~~~~~~~~~~~~~~
PR port-riscv/60889: riscv64: compat_netbsd32 is busticated
printf(3): try to improve description of positional arguments
Don't use "field" to refer to positional argument specification in
`%n$`, as the term is already used for the output field (as in "field
width", etc).
Reword the `*n$` paragraph that first refers to `n` as "one or more
decimal digits" and contrasts it with the "digit string" that actually
refers to an explicitly specified width or precision far away on the
previous page/screen (!). This is very unobvious, especially when you
read the page out of order, as one often does.
The result of this (intentionally) localized edits is still pretty
poor overall, but at least it fixes, hopefully, the two most glaring
problems. Further editorial help is welcome.
drm: Nix `highmem' memory accounting.
This led to confusing dmesg output when the kernel map size was
enlarged between 9 and 10, probably by this commit:
> Module Name: src
> Committed By: chs
> Date: Wed Aug 3 01:52:11 UTC 2022
>
> Modified Files:
> src/sys/uvm: uvm_km.c
>
> Log Message:
> for platforms which define NKMEMPAGES_MAX_UNLIMITED, set nkmempages
> high enough to allow the kernel to map all of RAM into kmem,
> so that free physical pages rather than kernel virtual space is
> the limiting factor in allocating kernel memory. this gives ZFS
> more flexibility in tuning how much memory to use for its ARC cache.
>
[13 lines not shown]
Make mpl115a2 return correct values.
Do not byteswap calibration coefficients - apparently, this was always
wrong. Properly wait before reading. Calculate in 64-bit arithmetic.
Use ENVSYS_PRESSURE.
vr(4): set or clear VR_RXCFG_RX_PROMISC bit in vr_setmulti().
Previously the promiscuous bit was only handled in vr_init().
When an interface is added to or removed from bridge(4), its
IFF_PROMISC flag is changed through the interface flags (SIOCSIFFLAGS).
On a running interface it does not reinitialize device, but calls
vr_setmulti() directly, which did not update the promiscuous bit in RX filter.
PR port-i386/60884
printf(3): use emphasis when a term is used for the first time
Use it for "conversion specification", "flag", "field width,
"precision", "length modifier", "conversion specifier".
printf(3): tweak formatting of n$
XXX: The way the description of positional arguments is worded is
pretty awkward. It [ab]uses "field" to refer to the conversion
specification itself, when the standard already uses it to refer to
the output field.
Pull up following revision(s) (requested by kre in ticket #1364):
common/lib/libc/string/memset2.c: revision 1.12
PR port-mips/60780 UBSan: long int << fix (src/common/lib/libc/string/memset2.c)
The comments say that memword_t is intended to be unsigned, but
presume that __register_t will provide that attribute. It usually
doesn't, so we need an unsigned type for building the fill value.
Thanks to Alexander Schreiber for running the UBSan built system
and reporting this (and others), and hopefully, in advance for
testing that this one is now fixed.
