* Don't use arbitrary frames for the average RX RSSI - only frames
from the current BSSID
* Don't log / do the syncbeacon logic for another BSSID and definitely
don't do the syncbeacon call if we miss beacons outside of STA mode.
* Don't do the IBSS merge bits if the current node plainly won't ever
match our current BSS (ie, the IBSS doesn't have to match, but all
the same bits that we check in ieee80211_ibss_merge() have to match.)
Tested:
* ath(4), AR9380, IBSS mode, surrounded by a lot of IBSS 11ac networks.
Sponsored by: Eva Automation, Inc.
The ath(4) driver now sees beacons and management frames for different
BSSIDs in IBSS mode, which is a problem when you're in a very busy
IBSS environment.
So, expose this function so drivers can use it to check if the current
RX node is actually for a BSS we need to pay attention to or not.
PR: kern/208644
Sponsored by: Eva Automation. Inc.
This prevents nodes being created for peers on BSSes that are not our own.
(Ie, same channel, IBSS, but different BSS.)
The "IBSS merge" thing was fixed by me enabling "see all beacons" in
the ath(4) driver a few months ago. Trouble is, we now need the filtering
again.
Tested:
* ath(4), IBSS, on a very busy IBSS channel with lots (> 15) IBSS networks.
PR: kern/208643
Sponsored by: Eva Automation, Inc.
Due to the bug in the number of 'GATHER' subdescriptors for TSO
packets, VNIC was not able to transmit more than one DMA segment
with TSO enabled.
Obtained from: Semihalf
Sponsored by: Cavium
This revision introduces PCIe support for the relevant Mediatek/Ralink
SoCs.
Currently the PCIe support is not converted to INTRNG, this may be a
task for the future.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5886
Tested on a MT7621 board, similar to the WiTi board.
More testing will be required to confirm everything is fine, but things
look good so far.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5885
USB on both MT7621 and MT7688 seems to work much better without doing
slew rate calibration.
These are the only two SoCs, apart from MT7628, which actually make
use of the slew rate calibration routines implemented in the mtk_usb_phy
driver. Since MT7628 is actually a superset of MT7688 things should be
the same for it as well.
We do not remove the code, we simply define it out.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5884
In mtk_soc.c memory is mapped incorrectly for MT7621. This revision fixes
this.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5882
If a user requested encrypted swap, but 0 sized, it would still be added to fstab
PR: 208630
Submitted by: Ganael LAPLANCHE <ganael.laplanche@corp.ovh.com>
MFC after: 2 weeks
Sponsored by: ScaleEngine Inc.
This is because they might do data compression which is quite CPU
expensive. The original code is correct for illumos, because there
a higher priority corresponds to a greater number.
MFC after: 2 weeks
This is rather ugly, because the RIPE and APNIC whois servers do
not provide referrals for address blocks that they do not manage.
However ARIN is usually the right place or knows the right place
so we try there.
The particular instance which clued me in to this bug is U.Mich.
141.211.0.0/16 for which the referral chain should be IANA ->
RIPE -> ARIN. RIPE's RDAP does provide useful redirects (for
example try `curl -I http://rdap.db.ripe.net/ip/141.211.0.0)
so maybe their whois server can be improved.
AfriNIC's whois server gives more direct referrals, but they are
designed to be human-readable. Ugly, but we can manage.
The issue of referrals between RIRs is likely to become more important
in the future whith the increasing number of cross-region IP address
block transfers increases.
The previous values caused the callout thread stall for 100ms each 2s
if no link is present. Dtrace analysis showed that it has significant
impact on overall interrupt performance.
Decrease these values by a factor of 100.
Obtained from: Semihalf
Sponsored by: Cavium
Reviewed by: zbb
Differential Revision: https://reviews.freebsd.org/D5854
Currently we don't keep zoneid in in6_ifaddr structure, because there
is still some code, that doesn't properly initialize sin6_scope_id,
but some functions use sa_equal() for addresses comparison. sa_equal()
compares full sockaddr_in6 structures and such comparison will fail.
For now use zero zoneid in in6ifa_ifwithaddr(). It is safe, because
used address is in embedded form. In future we will use zoneid, so mark it
with XXX comment.
Reported by: kp
Tested by: kp
Use vm_guest == VM_GUEST_HV is not enough to determine whether FreeBSD
is running on Hyper-V or not. What a mess.
Reported by: smokehydration tutanota com
Sponsored by: Microsoft OSTC
aq64_minfree is unsigned so comparing to find out if it is less
than zero is a nonsense. Move the comparison to the last position
as we don't want to spend time if any of the others triggers first.
hile it would be tempting to just remove it, it may be important to
keep it for portability with platforms where may be signed(?) or
in case we may want to change it in the future.
This flag indicates that the user wishes to use the GELIBOOT feature to boot from a fully encrypted root file system.
Currently, GELIBOOT does not support key files, and in the future when it does, they will be loaded differently.
Due to the design of GELI, and the desire for secrecy, the GELI metadata does not know if key files are used or not, it just adds the key material (if any) to the HMAC before the optional passphrase, so there is no way to tell if a GELI partition requires key files or not.
Since the GELIBOOT code in boot2 and the loader does not support keys, they will now only attempt to attach if this flag is set. This will stop GELIBOOT from prompting for passwords to GELIs that it cannot decrypt, disrupting the boot process
PR: 208251
Reviewed by: ed, oshogbo, wblock
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D5867
Improve over the solution in r297527:
Instead of attempting to initialize all the possible cases, just
move the check nearer to the case where it makes sense.
CID: 1006486
Reviewed by: ken
MFC after: 2 weeks
value that can't ever be in an inconsistant intermediate state even when
some other thread is in the middle of writing the value/register.
Locking of the hardware remains in the few places that do r-m-w operations.
Locking of metadata access is restricted to places using memcpy or sprintf
to modify the metadata.
oddly separated from related functionality. This just moves some blocks
of code around so that setup_intr and teardown_intr are near each other
again, and likewise for enable/disable_intr. No functional changes.
Previously, the ACPI PCI bus driver did a single pass over the devices in
the namespace that were a child of a given PCI bus to associate the
PCI bus-enumerated device_t devices with the corresponding ACPI handles.
However, this meant that handles were only established at runtime for devices
found during the initial PCI bus scan.
PCI_IOV adds devices that show up after the initial PCI bus scan, and coming
changes to add a bus rescan can also add devices after the initial scan.
This change adds a pci_child_added() callback to the ACPI PCI bus that walks
the namespace to find the ACPI handle for each device that is added. Using
a callback means that the handle is correctly set for any device no matter
how it is added (initial scan, IOV, or a bus rescan).
This matches with uudecode's -r option to decode raw data without initial and
final framing lines.
$ echo Test | uuencode -mr - | uudecode -mr
Test
Approved by: cognet
MFC after: 1 week
registered into global interrupt table. Thus, they must be filtered out
like per-cpu interrupts. Fortunately, it does not influence anything
on interrupt controllers which already use INTRNG.
GPIO controller drivers import.
As with other Ralink/Mediatek work, there are 2 versions of the GPIO
controller driver, depending on the type of SoC.
This revision introduces initial support for these.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5877
