2.4 ghz channel does not work in ARM

[jjcampo]

I have tested with 5.10 and 5.13 kernels, and ubuntu, debían and archlinux arm Linux distros but always fails. There is no problem with 5 ghz and with ubuntu x64 both frecuencies work. My adapter is comfast CF-812-AC.

I use 5 ghz so no problem here, but wanted to inform you.

[morrownr]

Hi @jjcampo

I may have a little to investigate this soon. Can I confirm some details with you?

RasPi4B ?

What are the settings on your options line in the following file?

/etc/modprobe.d/88x2bu.conf

[jjcampo]

Hi @Morrow

The board is an amlogic S905X2

# /etc/modprobe.d/88x2bu.conf
#
# Purpose: Allow easy access to specific driver options (module parameters).
#
# Edit the following line to change options:
options 88x2bu rtw_drv_log_level=0 rtw_led_ctrl=1 rtw_vht_enable=1 rtw_power_mgnt=1 rtw_switch_usb_mode=2 rtw_beamform_cap=0
#
# After editing is complete, save this file and reboot to activate the changes.
#
# Documentation:
#
# -----
#
# Log level options: ( rtw_drv_log_level )
#
# 0 = NONE (default)
# 1 = ALWAYS
# 2 = ERROR
# 3 = WARNING
# 4 = INFO
# 5 = DEBUG
# 6 = MAX
#
# Note: From the driver directory, you can save a log file that only includes
# RTW log entries by running the following in a terminal:
#
# $ sudo ./save-log.sh
#
# -----
#
# LED control options: ( rtw_led_ctrl )
#
# 0 = Always off
# 1 = Normal blink (default)
# 2 = Always on
#
# -----
#
# VHT enable options: ( rtw_vht_enable )
#
#  0 = Disable
#  1 = Enable (default)
#  2 = Force auto enable (use caution)
#
# Notes:
# - Unless you know what you are doing, don't change the default setting.
# - A non-default setting can degrade performance greatly in some modes.
# - For 5 GHz in AP mode, setting this option to 2 allows 80 MHz channel width.
#
# -----
#
# Power saving options: ( rtw_power_mgnt )
#
# 0 = Disable power saving
# 1 = Power saving on, minPS (default)
# 2 = Power saving on, maxPS
#
# Note: Extensive testing has shown that the default setting works well.
#
# -----
#
# USB mode options: ( rtw_switch_usb_mode )
#
# 0 = No switch
# 1 = Switch from usb 2.0 to usb 3.0
# 2 = Switch from usb 3.0 to usb 2.0 (default)
#
# Notes:
# - When in client (managed) mode, using 1 (USB3) works well.
# - When in master (AP) mode, use 2 (USB2) for 2.4 GHz.
# - When in master (AP) mode, use 1 (USB3) for 5 GHz.
#
# -----
#
# Beamforming options: ( rtw_beamform_cap )
#
# 0 = Disable (default)
# 1 = SU Beamformer
# 2 = SU Beamformee
# 3 = SU Beamformer and SU Beamformee
# 10= SU Beamformee and MU Beamformee
# 11= SU Beamformer and SU Beamformee and MU Beamformee
#
# Notes:
# - MU Beamformer is not supported.
# - The driver default setting is 10 but that is being overridden based
#   on test results. Beamforming tests at this location indicate that
#   beamforming is only slightly beneficial at medium range distances
#   (25-35 ft.) and detrimental at short (< 25 ft.) and long (> 35 ft.)
#   distances. Your results may vary. Testing is the only way to know. 
#
# ----
#
# To see all options that are available:
#
# $ ls /sys/module/88x2bu/parameters/
#
# -----
#
# To see the values that are in use:
#
# $ grep [[:alnum:]] /sys/module/88x2bu/parameters/*
#
#`-----

[morrownr]

For your 5 GHz managed mode operation you might consider changing to these 2 settings if using a USB3 port:

rtw_switch_usb_mode=1 rtw_beamform_cap=10

I'm not seeing anything else that would be a problem and the above are not problems, just performance tweaks. One big problem in this day in time is that there are so many distros and so many hardware platforms that I don't stand a chance to be able to test everything. If 5 GHz is working well and that is what you want, let's press on with other things.

Regards