This project is mirrored from https://gitlab.com/FreeBSD/freebsd-src.git.
Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer or owner.
Last successful update .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer or owner.
Last successful update .
- Dec 20, 2024
-
-
Adrian Chadd authored
For some NICs (notably the rtl8192cu that I'm working on) the firmware rate adaptation requires beacon processing to be enabled. Instead of making assumptions in the if_rtwn beacon routines (and honestly all of that should be in the HAL too), create a HAL method for enabling/disabling beacon processing specifically in STA mode. Since this isn't necessarily required for all NICs (notably the RTL8188E NICs, where some will do firmware rate control and some will require driver rate control), only enable it for the RTL8192CU and RT8192EU. The RTL8188E and RTL8812/RTL8821 just have no-op routines for now. Locally tested: * RTL8192CU, STA mode Differential Revision: https://reviews.freebsd.org/D48066 Reviewed by: bz
-
Joerg Wunsch authored
devd.conf by default considers many variables as internal, possibly expanding them to an empty string. Shell variables thus need to be wrapped into braces. Reviewed by: imp, Andre Albsmeier MFC after: 1 week Differential Revision: <https://reviews.freebsd.org/D48154>
-
Ed Maste authored
The description of the endpoint-independent option accidentally ended up in the middle of map-e-portset's text. Fixes: 390dc369 ("pf: Add support for endpoint independent NAT bindings for UDP") Reviewed by: kp Sponsored by: Tailscale Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D48158
-
Konstantin Belousov authored
Flags should not propagate from the lower fs. Behavior for the upper fs is determined by flags from its mount point structure. When lower fs acts according to its mount configuration, it is reported up as VOP errors. PR: 283425 Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D48150
-
Bjoern A. Zeeb authored
Add the missing bus_add_child DEVMETHOD. This is needed for the RPi5 running with a MMCCAM kernel and the worproject/rpi5-uefi to avoid a kernel panic on boot when SDIO tries to attach to a 'Intel Bay Trail' controller. Reviewed by: imp MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D48152
-
Bjoern A. Zeeb authored
When null_add_child() panics add the bus device name/unit and the new unit as this will immediately reveal the parent missing the DEVMETHOD(bus_add_child, ...) entry. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D48151
-
Bjoern A. Zeeb authored
The original commit was missing a space between two words due to uncareful string line wrapping; let the string run beyond the 80 char limit in order to also make it grep-able [1]. Reported by: jrtc27, Chris Torek (chris.torek gmail.com) Suggested by: emaste, imp [1] Sponsored by: The FreeBSD Foundation Fixes: 87e140a5 avoid (hard) hang on loading module MFC after: 3 days X-MFC with: 87e140a5 Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D48155
-
Sergey A. Osokin authored
MFC after: 3 days
-
CismonX authored
The FUSE_NO_OPEN_SUPPORT and FUSE_NO_OPENDIR_SUPPORT flags are only meant to indicate kernel features, and should be ignored if they appear in the FUSE_INIT reply flags. Also fix the corresponding test cases. MFC after: 2 weeks Reviewed by: Alan Somers <asomers@FreeBSD.org> Signed-off-by: CismonX <admin@cismon.net> Pull Request: https://github.com/freebsd/freebsd-src/pull/1509
-
- Dec 19, 2024
-
-
Olivier Certner authored
Regroup assignments tweaking preprocessor defines/undefs, and separately those about include directories. Re-order include directories a bit more logically, and remove redundant ones. Separate logical groups by blank lines. Build artifacts have been verified to stay the same when produced with an external LLVM 18 toolchain. MFC after: 1 month Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D48070
-
Olivier Certner authored
Reviewed by: Alexander Ziaee <concussious@runbox.com> Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D48063
-
Gleb Smirnoff authored
Axe dead code that allows to provide a created socket.
-
Adrian Chadd authored
The rate control message was doing 11g+11n without 11b rates, but the TX descriptor setup supports also falling back on 11b rates when doing multi-rate retry / per-descriptor rate control. So, line them up. They're not exactly the same as the TX path supports pure-N and pure-G modes which the rate control configuration does not, but there'll need to be a lot more work on supporting those operating modes anyway (around things like self-generated frame rate control/masks, beacon config, RTS/CTS selection, etc.) Locally tested: * RTL8192CU, STA mode Differential Revision: https://reviews.freebsd.org/D48081 Reviewed by: bz
-
Adrian Chadd authored
I'm unable to reproduce the original problem with my RTL8192CU USB devices with the current codebase and I can't find any reference to what this power register is doing - I see it defined in drivers, but it's not described or used anywhere. This reverts 7f740971 - rtwn_usb(4): fix Tx instability with RTL8192CU chipsets In any case being able to do higher rate RTS/CTS is beneficial. Local testing: * rtl8192cu, STA mode, TX/RX testing PR: 233949 Differential Revision: https://reviews.freebsd.org/D48026 Reviewed by: imp
-
Adrian Chadd authored
I noticed during testing that the MAC was generating MCS7 ACKs and MCS7 block-ACK frames in response to MCS frames from its peer. This is very suboptimal - it means that unless you're very close to your peer (in this case a 2GHz AP), you'll end up failing a lot of ACKs. Linux faced the opposite problem in rtl8xxxu - the rate set being programmed in here included a lot MORE rates, including MCS 0->7 and OFDM 6M->54M. This meant that they were INTENTIONALLY telling the hardware to transmit at higher rates, and their fix was to mask out the higher rates so self-generated frames don't try the high rates at all. Now, I am not sure why I'm not seeing any OFDM or HT basic rates. We don't mark any OFDM / HT rates as basic in net80211 (in ieee80211_phy.c) so I'm going to need to go and do a review of the standard to see what's up. Additionally, the HT rate set that we populate isn't tagging any of the HT rates as IEEE80211_RATE_BASIC, so the code I added for now is a no-op. So: * Extend rtwn_get_rates() and its consumers to populate the HT rateset with basic rates if they're provided * Add a default 2GHz / 5GHz mask, inspired by linux, applied over the basic rates provided. * Make sure there's at least an OFDM rate (for 2G/5G) rate available if the peer node is HT, which avoids the MAC defaulting to MCS7 when generating ACK/block-ACK. * Add register definitions for INIDATA/INIRTS, which set the default data rate when the driver doesn't specify the initial data / RTS/CTS rates in the TX descriptor. * Leave a comment about why I've modified the mask from Linux. Locally tested: * RTL8192CU, STA mode * RTL8188EU, STA mode * RTL8192EU, STA mode * RTL8812AU, STA mode Differential Revision: https://reviews.freebsd.org/D48019 Reviewed by: bz
-
Adrian Chadd authored
Enable the short-GI flag configuring the rate mask. Obtained from: * Realtek vendor driver, rtl8192cu Differential Revision: https://reviews.freebsd.org/D48013 Reviewed by: bz, imp
-
Richard Scheffenegger authored
Maintain lock ordering in ip_fw2.c by tracking any nested locking using a flag, and then executing the locking in the correct order. Reported by: Jimmy Zhang Obtained from: Jimmy Zhang Sponsored by: NetApp, Inc. Reviewed By: glebius, ae Sponsored by: NetApp, Inc. Differential Revision: https://reviews.freebsd.org/D48069
-
Richard Scheffenegger authored
Remove unneeded th_x2 initalization, use named constants instead of magic numbers (fixing one oversight) and add some line breaks. Expand one man page slightly. No functional change intended. Reviewed By: tuexen, cc Sponsored by: NetApp, Inc. Differential Revision: https://reviews.freebsd.org/D48065
-
Franco Fichtner authored
This reverts commit 89e73359. PR: 281125 Reviewed by: Krzysztof Galazka <krzysztof.galazka@intel.com> MFC after: 3 days Pull Request: https://github.com/freebsd/freebsd-src/pull/1545
-
Gleb Smirnoff authored
-
- Dec 18, 2024
-
-
Slava Shwartsman authored
Driver defined all flow context actions in MLX5_FLOW_CONTEXT_ACTION_*, no need to duplicate them with mlx5_rule_fwd_action. Sponsored by: NVidia networking MFC after: 1 week
-
Adrian Chadd authored
This is straight from all the drivers, linux and vendor. Differential Revision: https://reviews.freebsd.org/D48004 Reviewed by: bz, imp
-
Adrian Chadd authored
The 32 bit bitmap is enough for CCK/OFDM rates and MCS0..15, but won't work for > MCS15, nor VHT rates. So, break out the legacy rates and HT rates. * break the rates and htrates out * document which calls are looking up basic rates and which care about the rates themselves * ensure the rate bitmap passed into the rate control firmware call (which isn't enabled yet!) is capped at 28 bits so they don't set the mode field. Differential Revision: https://reviews.freebsd.org/D47993 Reviewed by: bz, imp
-
Adrian Chadd authored
We should just keep the RX pipeline busy. Differential Revision: https://reviews.freebsd.org/D47990 Reviewed by: imp
-
Adrian Chadd authored
This should be a *9 rather than a *10 so higher stream MCS rates (eg comparing MCS0 and MCS8) that have slightly longer average transmit times (but better burst transmit times) get considered. This mirrors what the later code does when considering if a rate change is needed. Locally tested: * AR9280, AP mode * AR9380, AP mode Differential Revision: https://reviews.freebsd.org/D47988 Reviewed by: imp
-
Adrian Chadd authored
This is an attempt to reverse engineer what the actual transmit power calculations are doing and apply net80211 limits on them. It doesn't look as simple as just applying the check at the end - there are plenty of places where offsets are calculated between different PHY modes and 1 / 2 antenna MCS transmit rates. There are also some places where the offset being added is negative, so handle the potential underflow so when things hit 0, they don't just wrap and cause the maximum transmit power into the registers. This is being done to aide in power/performance debugging - if there are issues with the transmit power being wrongly calculated and are too high, the output waveform will be distorted and it will effect performance. Being able to drop the transmit power by a few dB here and there can quickly identify if this is happening (because suddenly higher MCS rates / OFDM rates suddenly work better!) I've tested each NIC through the transmit power values from 0 dBm to 30dBm via ifconfig (and they're all capped far before that, normally around 20-25dBm) and they're not underflowing. Locally tested: * RTL8192CU, STA * RTL8192EU, STA * RTL8188EU, STA Differential Revision: https://reviews.freebsd.org/D47987 Reviewed by: bz, imp
-
Adrian Chadd authored
* Refactor out the TX power register register dump - it's done in a couple places and it makes sense to refactor it. * Condense the output into a few lines per transmit chain. It's very long with the 8 and 16 MCS rates, and it made it difficult to eyeball what's going on when tweaking TX power. Differential Revision: https://reviews.freebsd.org/D47986 Reviewed by: bz, imp
-
Adrian Chadd authored
The RTL8188/RTL8192/RTL8821/RTL8812 NICs all seem happy to have their transmit power changed at runtime - and it does seem to do what's expected - the transmit power level does change. So, add the API call here, even though it's all currently no-ops. A follow-up commit will land changes for the chipsets to both limit transmit power to the configured / regulatory limit AND allow reconfiguration at runtime. Differential Revision: https://reviews.freebsd.org/D47979 Reviewed by: bz, imp
-
Adrian Chadd authored
This apparently kicks off TX power level self-calibration, which can't hurt. Locally tested: * RTL8812AU, STA * RTL8821AU, STA Obtained from: Linux rtw88 Differential Revision: https://reviews.freebsd.org/D47978 Reviewed by: bz, imp
-
Gleb Smirnoff authored
Fixes: ae5c3dfd
-
Alan Somers authored
Even on a riscv embedded system, the fusefs tests run fast enough that 10 seconds is a reasonable timeout. [skip ci] MFC after: 2 weeks Sponsored by: ConnectWise
-
Alan Somers authored
Every fuse ticket has a "unique" token. As the name implies, they're supposed to be unique. Previously the fusefs test suite verified their uniqueness by relying on the fact that they are also sequential. But they aren't guaranteed to be sequential. Enhance the tests by removing that convenient assumption. MFC after: 2 weeks Sponsored by: Axcient
-
Kristof Provost authored
When a DCO client reconnects (e.g. on server restart) OpenVPN may create a new socket rather than reusing the existing one. This used to be rejected because we expect all peers to use the same socket. However, if there are no peers it's safe to release the previous socket and install the tunnel function on the new one. See also: https://redmine.pfsense.org/issues/15928 MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC ("Netgate")
-
Juraj Lutter authored
When performing a background fsck on msdosfs devices, it ends with the following error: fsck_msdosfs: illegal option -- B usage: fsck_msdosfs -p [-f] filesystem ... fsck_msdosfs [-ny] filesystem ... Introduce -B option as a compatibility with fsck_ffs(8) and also update the descriptions for -B and -C in fsck_msdosfs(8) manual page. Reviewed by: imp Approved by: imp MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D48132
-
Pau Amma authored
Reviewed by: mhorne, imp Differential Revision: https://reviews.freebsd.org/D48128
-
- Dec 17, 2024
-
-
Valeriy Ushakov authored
The "c" command should start the next cycle as clarified in POSIX 2024. This is also consistent with historical and gnu sed behavior. This patch is from OpenBSD by way of NetBSD with a tweak to the man page date by me. Confirmed the test case in the bug now works. PR: 271817 Obtained from: NetBSD (1.39 uwe), OpenBSD (1.39 millert) Sponsored by: Netflix
-
Konstantin Belousov authored
It is not implemented, and most likely cannot be, in a robust manner. Reviewed by: Ariel Ehrenberg <aehrenberg@nvidia.com>, slavash Sponsored by: NVidia networking
-
Alan Somers authored
[skip ci] MFC after: 2 weeks Sponsored by: ConnectWise Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D48125
-
Jessica Clarke authored
Otherwise this matches any two-character status except for ok. Fixes: e5e94d2d ("Expand OpenFirmware API with ofw_bus_node_status_okay method") MFC after: 1 week
-
Kristof Provost authored
As per RFC (RFC4960 section 3.3.7) an ABORT terminates the connection fully. We should mode the state to CLOSED rather than CLOSING. Suggested by: Oliver Thomas See also: https://redmine.pfsense.org/issues/15924 Sponsored by: Rubicon Communications, LLC ("Netgate")
-