handbook/firewalls: Properly point to freebsd-ftpd
Properly point to the ftp/freebsd-ftpd package.
Fixes: d8631346f9 ("handbook/firewalls: Adapt blacklistd to blocklistd")
handbook/firewalls: Adapt blacklistd to blocklistd
Follow upstream rename from blacklistd to blocklistd, and adapt the
documentation accordingly.
ftpd(8) has been changed to ftp/freebsd-ftpd, as it is no longer
included in base.
Reviewed by: ziaee
Pull Request: https://github.com/freebsd/freebsd-doc/pull/569
graphics/materialx: Add new port
MaterialX is an open standard for representing rich material and
look-development content in computer graphics, enabling its
platform-independent description and exchange across applications and
renderers.
PR: 283175
devel/glib20: remove FAM_ALTBACKEND
No longer accessed after libinotify-kqueue landed, further with
native inotify since 15-STABLE. While here, conditionalise the
devel/libinotify dependency accordingly.
devel/glib20: shore up DOCS
- use DOCS over PORTDOCS
- unconditionally omit G_VA_COPY_AS_ARRAY, as the symbol is historical,
only relevant on certain platforms and the generated doc is blank
LinuxKPI: 802.11: when synching HT and VHT cap, mask rx_mcs
When we sync the sta data, mask the rx_mcs with what the hardware is
able to do so that we do not leave, e.g., a 2nd stream enabled on a 1x1
chipset.
iwlwifi(4) has a further check for the smps_mode to limit to NSS=1 but
I believe that is historic and not actually in use anymore.
This fixes firmware crashes on TLC updates with nss=1 but the nss=2 array
index also being populated (with HT/VHT80/160 mcs information):
data being populated:
iwlwifi0: 0x20101A0D | ADVANCED_SYSASSERT
iwlwifi0: 0x00000006 | umac data1
iwlwifi0: 0x00000001 | umac data2
iwlwifi0: 0x000003FF | umac data3
iwlwifi0: 0x____050F | last host cmd
Reported by: Claudio Zumbo (claudiozumbo gmail.com), Erik Power
Tested by: Claudio Zumbo, Erik Power (eppower umich.edu)
[3 lines not shown]
LinuxKPI: pci: undo the pci_resource_len() check in lkpi_pci_request_region()
Creating non-passthru SR-IOV interfaces on a mlx5en(4) failed.
The problem lies in the pci_resource_len() call but not that the BAR length
is tmeporary 0 but in that we call lkpi_pci_get_bar() with a true argument
which will create the BAR resource for us and report the approriate length
back. However, the later call to bus_alloc_resource_any() will then fail
given the resource already exists.
Restore the previous behaviour and let bus_alloc_resource_any() do the
work. Adjust the return values from -ENODEV to -EBUSY to match callers
expectations.
In linuxkpi_pcim_request_all_regions(), like in linuxkpi_pci_request_regions(),
filter out the -EBUSY errors as "not an error" and try the next bar.
This also seems to be consistent with the expectations of the callers.
PR: 290793
Reported by: David BOYER (jcduss13 gmail.com)
[6 lines not shown]
