fix setting DMA base addresses of iwn(4) Tx rings 17 and beyond
For Tx rings 17 and up, the driver was writing DMA base addresses
to the wrong registers. The firmware would crash when we tried to
use those rings.
This was never noticed before because those rings had never been
used by the driver until the recent introduction of support for
DSCP_EF in the wireless stack.
Use of Tx ring 17 in iwn is triggered by DSCP_EF, which the stack
is now mapping to TID 6, which the iwn code maps to queue index 16,
which addresses the 17th ring.
This issue only affected iwn 5000/6000 series devices. The earlier
devices only have 16 Tx rings and the driver respects that limit.
fatal firmware errors reported by + fix tested + ok bluhm@
Update to quiche 0.24.8
Patch out qlog-dancer in Cargo.toml, as it has dependencies (checkout
on specific GH commit) that MODCARGO_CRATES does not seem to handle,
plus we do not need it anyway.
syncthing: don't set GOMAXPROC, it limits threads, not only processes
Instead pass MODGO_FLAGS, where the module sets -p ${MAKE_ENV} which
is closer to the intent.
ok kn sthen, no objection edd
Restore the comment indicating that uvmexp.wired is changed by atomics
This was changed in changes that were backed out that did not actually
make changes to uvmexp.wired. As this value is still only changed by
atomic operations, restore the comment indicating that it is.
ok kettenis@, claudio@
Modify uvmexp.paging only with atomic operations.
This was done in 1.3.1, but in conjunction with some undesirable
other changes for where this was changed and used.
This change makes the value be changed only with atomics, without
changing where or by how much it is changed, and restores the
comment in uvmexp.h to indicate it is changed by atomic ops.
ok kettenis@ claudio@