Skip to content
Snippets Groups Projects
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 .
  1. Dec 20, 2024
  2. Dec 19, 2024
    • Olivier Certner's avatar
      libprocstat: ZFS support: Makefile: Tidy up a bit · 618c97b8
      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
      618c97b8
    • Olivier Certner's avatar
      setcred(2): Add manual page · b6f4027a
      Olivier Certner authored
      Reviewed by:    Alexander Ziaee <concussious@runbox.com>
      Sponsored by:   The FreeBSD Foundation
      Differential Revision:  https://reviews.freebsd.org/D48063
      b6f4027a
    • Gleb Smirnoff's avatar
      rpc: svc_tli_create() is always called with NULL socket · d052fcbd
      Gleb Smirnoff authored
      Axe dead code that allows to provide a created socket.
      d052fcbd
    • Adrian Chadd's avatar
      rtwn: bring the r92c rate control setup selection in line with tx descriptors · 300c843b
      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
      300c843b
    • Adrian Chadd's avatar
      rtwn: disable a workaround introduced earlier for RTL8192CU TX performance · eb631451
      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
      eb631451
    • Adrian Chadd's avatar
      rtwn: add a default OFDM / CCK rate for self-generated frames · aaaca5f2
      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
      aaaca5f2
    • Adrian Chadd's avatar
      rtwn: set the shortgi flag in the RTL8192C rate control setup message · 4e2bd8cf
      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
      4e2bd8cf
    • Richard Scheffenegger's avatar
      ip_fw: address lock order reversal · 8e780285
      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
      8e780285
    • Richard Scheffenegger's avatar
      tcp: cleanup of nits after use of accessor tcp_get_flags · 31034044
      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
      31034044
    • Franco Fichtner's avatar
      Revert "ixl: fix multicast filters handling" · 38663adb
      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
      38663adb
    • Gleb Smirnoff's avatar
  3. Dec 18, 2024
    • Slava Shwartsman's avatar
      mlx5: Eliminate the use of mlx5_rule_fwd_action · b762b199
      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
      b762b199
    • Adrian Chadd's avatar
      rtwn: add SGI flag for the rate control message · 371a4ee9
      Adrian Chadd authored
      This is straight from all the drivers, linux and vendor.
      
      Differential Revision:	https://reviews.freebsd.org/D48004
      Reviewed by:	bz, imp
      371a4ee9
    • Adrian Chadd's avatar
      rtwn: update rtwn_get_rates() to separate out the CCK/OFDM and HT rates · 745a8582
      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
      745a8582
    • Adrian Chadd's avatar
      rtwn: bump up the RX USB buffers · 638fcd53
      Adrian Chadd authored
      We should just keep the RX pipeline busy.
      
      Differential Revision:	https://reviews.freebsd.org/D47990
      Reviewed by:	imp
      638fcd53
    • Adrian Chadd's avatar
      ath_rate_sample: correct the "best rate" calculation · 25af78d0
      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
      25af78d0
    • Adrian Chadd's avatar
      rtwn: try enforcing net80211 regulatory / txpower limits for 11n chips · 0ea7f8ca
      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
      0ea7f8ca
    • Adrian Chadd's avatar
      rtwn: refactor out the TX power register power dump, condense output · 6858c6b1
      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
      6858c6b1
    • Adrian Chadd's avatar
      rtwn: add APIs for setting transmit power · b71805e9
      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
      b71805e9
    • Adrian Chadd's avatar
      rtwn: add tx power training for RTL8812/RTL8821 · cf6b389f
      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
      cf6b389f
    • Gleb Smirnoff's avatar
      tests: remove reference to renamed test · ff7e00eb
      Gleb Smirnoff authored
      Fixes:	ae5c3dfd
      ff7e00eb
    • Alan Somers's avatar
      fusefs: delete a comment in the tests · 53f73aaf
      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
      53f73aaf
    • Alan Somers's avatar
      fusefs: More accurately test the unique tokens in the test suite · b1879975
      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
      b1879975
    • Kristof Provost's avatar
      if_ovpn: improve reconnect handling · 3624de53
      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")
      3624de53
    • Juraj Lutter's avatar
      fsck_msdosfs(8): Introduce -B option as no-op · d9ad257a
      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
      d9ad257a
    • Pau Amma's avatar
      ow_temp(4): fix typo · 6e423be7
      Pau Amma authored
      Reviewed by:	mhorne, imp
      Differential Revision:	https://reviews.freebsd.org/D48128
      6e423be7
  4. Dec 17, 2024
Loading