math/octave-forge-apa: New port.
Arbitrary Precision Arithmetic (APA) package for Octave/Matlab. This
package is a wrapper around the MPFR library, which provides arbitrary
precision floating-point arithmetic. The package allows users to perform
calculations with a precision that can be set at runtime, making it
suitable for applications that require high precision, such as numerical
analysis and scientific computing.
netinet6: Fix memory leak on auto_linklocal
release the refcount of link-local prefix information to ensure
it gets freed when the address is deleted.
Reviewed By: zlei, ivy
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D55593
sys: Restore sorting in sys/elf_common.h
These various definitions are meant to be kept sorted by machine prefix.
Fixes: 2bb61497ca76 ("elf_common.h: Add definitions for LoongArch ELF files")
(cherry picked from commit b7ef4f4b230f01968473269f280bd7e4e86a3ec9)
devel/freebsd-git-arc: Update to 2026-02-18 snapshot
Upstream commit:
4fb507cae916 - git-arc: Tweak heuristic for email address
Sponsored by: The FreeBSD Foundation
libusb: dequeue next transfer on completion to prevent stalls
The transfer proxy callbacks (bulk/interrupt, control, isochronous)
only called libusb10_submit_transfer_sub() in the START path to
pipeline the second kernel transfer slot. On completion or error,
no attempt was made to dequeue the next pending transfer from
tr_head onto the now-free slot.
When more than two async transfers were submitted on the same
endpoint, the third (and subsequent) transfers would remain stuck
on tr_head indefinitely, since no completion ever triggered their
submission. This caused a protocol-level deadlock in applications
like adb that submit header + payload + zero-length terminator as
three separate bulk transfers in sequence.
Fix by calling libusb10_submit_transfer_sub() after every
libusb10_complete_transfer() in all three proxy callbacks.
MFC After: 2 weeks
[4 lines not shown]
libusb: dequeue next transfer on completion to prevent stalls
The transfer proxy callbacks (bulk/interrupt, control, isochronous)
only called libusb10_submit_transfer_sub() in the START path to
pipeline the second kernel transfer slot. On completion or error,
no attempt was made to dequeue the next pending transfer from
tr_head onto the now-free slot.
When more than two async transfers were submitted on the same
endpoint, the third (and subsequent) transfers would remain stuck
on tr_head indefinitely, since no completion ever triggered their
submission. This caused a protocol-level deadlock in applications
like adb that submit header + payload + zero-length terminator as
three separate bulk transfers in sequence.
Fix by calling libusb10_submit_transfer_sub() after every
libusb10_complete_transfer() in all three proxy callbacks.
MFC After: 2 weeks
[4 lines not shown]
