RTL8822BE [10ec:b822] Subsystem [103c:831b] wifi regression

[Philip Johnson]

This wireless adapter worked well under 18.04.4 (kernel 5.3) but has poor range after installing 20.04 (kernel 5.4). This is testing a 2.4GHz connection. While the received signal strength appears to be the same with either kernel, the transmitted signal is much weaker under the 5.4 kernel (as assessed from the wifi access point running OpenWrt): the 5.4 kernel yields ~10-20 lower dBm than the 5.3 kernel. This greatly reduces the usable wifi range.

To summarize testing:
5.3.0-28-generic (Booting off a 18.04.4 live USB) shows good signal.
5.4.0-39-generic (latest supported on 20.04) is problematic
5.6.0-1011-oem (installed from standard repos) is problematic
mainline kernel 5.8.0-050800-generic shows good signal.

Ideas to further narrow down this regression?

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.4.0-39-generic 5.4.0-39.43
ProcVersionSignature: Ubuntu 5.4.0-39.43-generic 5.4.41
Uname: Linux 5.4.0-39-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.3
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: johnson 745 F.... pulseaudio
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Mon Jun 29 23:18:24 2020
InstallationDate: Installed on 2020-05-29 (32 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 003: ID 05c8:022a Cheng Uei Precision Industry Co., Ltd (Foxlink) HP Webcam
 Bus 001 Device 002: ID 0bda:b00b Realtek Semiconductor Corp. Bluetooth Radio
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: HP HP Stream Laptop 11-ah0XX
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
 TERM=xterm-256color
 XDG_RUNTIME_DIR=<set>
 PATH=(custom, no user)
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-39-generic root=UUID=d161feb8-d49a-4c0c-b954-e14175cdae0b ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-5.4.0-39-generic N/A
 linux-backports-modules-5.4.0-39-generic N/A
 linux-firmware 1.187
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/23/2018
dmi.bios.vendor: Insyde
dmi.bios.version: F.02
dmi.board.asset.tag: Type2 - Board Asset Tag
dmi.board.name: 84FC
dmi.board.vendor: HP
dmi.board.version: 06.17
dmi.chassis.asset.tag: Chassis Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: HP
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnInsyde:bvrF.02:bd05/23/2018:svnHP:pnHPStreamLaptop11-ah0XX:pvr:rvnHP:rn84FC:rvr06.17:cvnHP:ct10:cvrChassisVersion:
dmi.product.family: 103C_5335KV HP Stream
dmi.product.name: HP Stream Laptop 11-ah0XX
dmi.product.sku: 4ND15UA#ABA
dmi.sys.vendor: HP

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This change was made by a bot.

[You-Sheng Yang (vicamo)]

I have the same card (RTL8822BE [10ec:b822] Subsystem [103c:831b]), but I got the same TX power for all following kernels:

  * 5.3.18-050318-generic
  * 5.4.0-39-generic
  * 5.6.0-1017-oem
  * 5.8.0-050800-generic

Could you specify the steps you took, the output of `iw dev <devname> info`? Will anything change when you do `iw dev <devname> set txpower auto`? and `iw dev <devname> set txpower fixed N`, where N is the txpower at 5.3 kernel?

[Kai-Heng Feng (kaihengfeng)]

Please also see if cold boot helps.

[Philip Johnson (grrrats)]

iw dev info *reports* the same default txpower (20.00 dBm) for all kernels. It is only the actual received signal (at the access point) that varies. I paste the output of `iw dev wlo1 info` below for 5.4 and 5.8; 5.3 is the almost the same except it lacks the multicast TXQ lines:

Interface wlo1
 ifindex 2
 wdev 0x1
 addr 74:40:bb:2e:b8:c1
 ssid nullfarm
 type managed
 wiphy 0
 channel 6 (2437 MHz), width: 40 MHz, center1: 2447 MHz
 txpower 20.00 dBm
 multicast TXQ:
  qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
  0 0 0 0 0 0 0 0 0

On 5.8, `set txpower auto` sets it to be 30.00 dBm (as reported by rerunning `iw dev wlo1 info`). However, this does not noticeably change the received signal strength (as there is variation in received signal, a small difference in the mean would be hard to detect). I also tried `set txpower 100` to 1.00 dBm; this also does not appear to change the received signal strength. So I suspect the txpower setting must not be getting through to the hardware.

On 5.4, `set txpower auto` sets it to be 20.00 dBm (i.e., no change). Attempting to match 5.8 auto by `set txpower 3000` actually sets it to be 20.00. `set txpower 100` works but none of these changes to txpower affect the received signal strength.

On 5.3, `set txpower auto` sets it to be 30.00 dBm (same as 5.8). `set txpower 100` also works but again, none of these changes affect the received signal strength.

I am conducting these tests ~5m away from the access point, although through walls/floor. The 5.3 and 5.8 received signal strength is generally between -61 and -65 dBm while on 5.4 it is generally between -78 and -80 dBm.

A cold boot into 5.4 does not change the behavior.

[Kai-Heng Feng (kaihengfeng)]

Can you please do a kernel bisection?

[Philip Johnson (grrrats)]

This is my first time tracking down a kernel bug, so it's taking me a little while as I learn the bisection & kernel compilation procedure.

As an initial step, I have isolated the problem to something Ubuntu-specific. I have now tried running several mainline 5.4 kernels including, e.g., 5.4.17-050417-generic and found, to my surprise, the wireless signal is strong on those mainline kernels. To summarize my testing:
BAD:
  20.04 runs a signed Ubuntu 5.4 or 5.6 kernel
GOOD:
  18.04.4 (live usb) runs the default signed 5.3 kernel
  20.04 runs unsigned mainline 5.3, 5.4, 5.8 kernels

As a step towards a bisection, I've tried to boot a signed Ubuntu 5.3 kernel (taken from 18.04) on 20.04, but this hangs at the "Loading initial ramdisk" stage -- presumably due to some incompatibility between 18.04 and 20.04. I'll next attempt to compile the Ubuntu 5.3 kernel myself, which will hopefully boot on 20.04.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[Thomas Hoffman (thomashoffman)]

i have also facing the same type of issue on my client's site kindly visit: https://www.capcutgeeks.com/capcut-mod-apk/