wg(4): Assert task is nonzero before queueing work.
Prompted by (though I can't see any way it could be the source of):
PR kern/60728: workqueue panic in wg
arm64: don't consult mvfr1_el1 for AArch64 fp capabilities
The MVFR1_EL1 register describes features for the AArch32 AdvSIMD and FP
implementation and the contents of this register are UNKNOWN when FEAT_AA32
is not implemented.
So let's ignore this register and just set FPCR defaults for IEEE 754
compatibility.
Before this change, 7 tests in lib/libm failed on a VMware Fusion VM
(Apple M4 Pro) where MVFR1_EL1 reads as zero. With this change, all
tests pass.
Add interrupt support to pcfiic.
Make the repeat-start logic in the non-interrupt case simpler.
Add comments to softc fields.
By using interrupts, we greatly reduce the system time and wall clock time
used during i2c operations.
On machines where interrupts are not supported, the front end can set
the sc_poll flag to true, and the driver will use the polling path.
tzdata2netbsd - hg repo processing updates (mostly)
More updates to handle using mercurial as the repo, rather than cvs.
Mostly related to my gradual learning process of dealing with merges
and conflicts from the merge, correctly, using hg instead of cvs.
This also separated the merge from an attempt to update the sets list
at the same time (when an update is needed, which is rare), and (for
hg only) commit both in a single transaction, which would be ideal,
as if a rollback is needed, both parts need to be rolled back. But
it doesn't seem as if that is possible (or not without treating the
sets list as files to also be merged, which would have its own issues).
The only change here that affects usage when using a cvs repo, is that
the doc/3RDPARTY update now also updates the Date: field of the tz*
block, along with the Version (and if needed, Current-Version) field(s).
pci_resource: use existing BARs even if mem/io space is left disabled
It's possible that firmware assigned resources to a device and left
memory / io space accesses disabled. Let's assume if we see a non-zero
address in a BAR that it was assigned by firmware.
Should help PR# kern/60427 and kern/60463
gicv3: don't wait for RWP to clear when unblocking irqs
The RWP bit does not track writes to ISENABLER<n>, only ICENABLER<n>. So
don't bother waiting for it to clear when unblocking IRQs.
This is ok; pic_block_irqs is expected to be synchronous (no IRQs allowed
after the call) but not pic_unblock_irqs (some time can pass before an IRQ
is raised).
Pull up the following, requested by kre in ticket #1339:
external/public-domain/tz/dist/CONTRIBUTING up to 1.1.1.11
external/public-domain/tz/dist/Makefile up to 1.7
external/public-domain/tz/dist/NEWS up to 1.9
external/public-domain/tz/dist/README up to 1.4
external/public-domain/tz/dist/TZDATA_VERSION up to 1.47
external/public-domain/tz/dist/asia up to 1.17
external/public-domain/tz/dist/backward up to 1.13
external/public-domain/tz/dist/backzone up to 1.5
external/public-domain/tz/dist/northamerica up to 1.8
external/public-domain/tz/dist/southamerica up to 1.6
external/public-domain/tz/dist/theory.html up to 1.7
external/public-domain/tz/dist/version up to 1.20
external/public-domain/tz/dist/zone.tab up to 1.7
external/public-domain/tz/dist/zone1970.tab up to 1.8
external/public-domain/tz/dist/zonenow.tab up to 1.9
doc/3RDPARTY (apply patch)
Updated tzdata to 2026d (via local 2026dgtz).
Pull up following revision(s) (requested by bouyer in ticket #1338):
sys/arch/xen/xen/xbdback_xenbus.c: revision 1.109
Fix a brain-o in a KASSERT that could cause a guest to panic a DIAGNOSTIC
kernel: to assert that an I/O is already in flight we want
xbdi_pendingreqs > 0, not xbdi_pendingreqs > 1
While there, fix an error path that could also cause a KASSERT to fire
or a state corruption: reset xio_need_bounce to 0 before calling
xbdback_io_error() when the bounce buffer is not fully set up.
Pull up following revision(s) (requested by bouyer in ticket #464):
sys/arch/xen/xen/xbdback_xenbus.c: revision 1.109
Fix a brain-o in a KASSERT that could cause a guest to panic a DIAGNOSTIC
kernel: to assert that an I/O is already in flight we want
xbdi_pendingreqs > 0, not xbdi_pendingreqs > 1
While there, fix an error path that could also cause a KASSERT to fire
or a state corruption: reset xio_need_bounce to 0 before calling
xbdback_io_error() when the bounce buffer is not fully set up.
Pull up following revision(s) (requested by tls in ticket #461):
sys/net/npf/files.npf: revision 1.26
sys/net/bpf_filter.c: revision 1.74
sys/net/bpf.c: revision 1.259
sys/net/npf/npf_os.c: revision 1.24
sys/net/npf/npf_os.c: revision 1.25
Fix npf crash in kernels without "pseudo-device bpfilter".
Actually fix panic on non-modular kernels with npf and no bpf.
Fix commit of badly-applied patch that brought us npf_os.c 1.24.
