lagg: Avoid dropping locks when starting the interface
The init routine of a lagg(4) interface will not change during the whole
lifecycle. So we can call lagg_init() directly instead of through the
function pointer. Well, that requires a drop and pickup lock, which
unnecessarily expose a small race window. Refactor lagg_init() into
lagg_init_locked() and call the later one to avoid that.
Meanwhile, delay updating the driver managed status until after the
interface is really ready.
Reviewed by: markj
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D55198
(cherry picked from commit c182cf646a4f995fa8506afd8afc9541c4d32905)
lagg: Make lagg_link_active() static
It is declared as static. Make the definition consistent with the
declaration.
It was ever fixed by commit 52e53e2de0ec, but the commit was reverted,
leaving it unfixed.
No functional change intended.
MFC after: 3 days
(cherry picked from commit 30988d0a7bd7ebd5f5825b9b7aa04ff0af788aa7)
audio/shairport-sync: Update to 5.0.0
- Update to 5.0.0
- Drop SNDIO from default options (deprecated upstream)
- Add SNDIO deprecation note to OPTIONS
Changelog:
https://github.com/mikebrady/shairport-sync/releases
ports-mgmt/synth: update to 3.13 release (+)
Changelog:
* Attempt to fix prefetching with modern pkg
* Limit log preservation to the task that failed
* testing fix for missing synth scanner log file
* Add EXIT STATUS section to man page
* Set non-zero return code when problem encountered
* Create /etc/hosts in builder
net/py-trio: Update to 0.33.0
- Add PYTHONPATH=${WRKSRC}/src to TEST_ENV so pytest runs against
the in-tree sources (src layout)
- Disable pytest plugin autoload during tests to avoid interference
from unrelated globally installed pytest plugins
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
[2 lines not shown]
