rtw88_8822ce: unable to ping anything, "failed to write TX skb to HCI" and "failed to pusk skb, ret -28" in dmesg

[Andrzej Mendel-Nykorowycz]

I am able to associate with a SSID and receive an IP address, but when trying to ping anything, the ping fails and I get repeated messages in the syslog:
Oct 11 22:32:29 Brutus kernel: [51072.191588] rtw_8822ce 0000:03:00.0: failed to pusk skb, ret -28
Oct 11 22:32:30 Brutus kernel: [51073.215591] rtw_8822ce 0000:03:00.0: failed to write TX skb to HCI
Oct 11 22:32:30 Brutus kernel: [51073.215600] rtw_8822ce 0000:03:00.0: failed to pusk skb, ret -28
Oct 11 22:32:31 Brutus kernel: [51074.119382] rtw_8822ce 0000:03:00.0: failed to write TX skb to HCI

They appear at the same rate as the ping is attempted.

Ubuntu Kinetic (22.10), up-to-date as of October 11. Kernel 5.19.0-19-generic.

ProblemType: Bug
DistroRelease: Ubuntu 22.10
Package: linux-image-5.19.0-19-generic 5.19.0-19.19
ProcVersionSignature: Ubuntu 5.19.0-19.19-generic 5.19.7
Uname: Linux 5.19.0-19-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.23.1-0ubuntu2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: kelner 4762 F.... wireplumber
 /dev/snd/seq: kelner 4758 F.... pipewire
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
Date: Tue Oct 11 22:28:26 2022
InstallationDate: Installed on 2020-09-12 (758 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
MachineType: HP HP Pavilion Gaming Laptop 15-ec0xxx
ProcFB: 0 amdgpudrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.19.0-19-generic root=UUID=bc5eaf09-3825-4513-9cf6-b6e691ac42a6 ro quiet splash nogpumanager nvidia.NVreg_DynamicPowerManagement=0x02 intel_idle.max_cstate=0 vt.handoff=7
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon.
RebootRequiredPkgs: Error: path contained symlinks.
RelatedPackageVersions:
 linux-restricted-modules-5.19.0-19-generic N/A
 linux-backports-modules-5.19.0-19-generic N/A
 linux-firmware 20220923.gitf09bebf3-0ubuntu1
SourcePackage: linux
UpgradeStatus: Upgraded to kinetic on 2022-10-06 (5 days ago)
dmi.bios.date: 03/03/2022
dmi.bios.release: 15.13
dmi.bios.vendor: AMI
dmi.bios.version: F.13
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: 86D6
dmi.board.vendor: HP
dmi.board.version: 96.45
dmi.chassis.type: 10
dmi.chassis.vendor: HP
dmi.chassis.version: Chassis Version
dmi.ec.firmware.release: 96.45
dmi.modalias: dmi:bvnAMI:bvrF.13:bd03/03/2022:br15.13:efr96.45:svnHP:pnHPPavilionGamingLaptop15-ec0xxx:pvr:rvnHP:rn86D6:rvr96.45:cvnHP:ct10:cvrChassisVersion:sku8BS92EA#AKD:
dmi.product.family: 103C_5335KV HP Pavilion
dmi.product.name: HP Pavilion Gaming Laptop 15-ec0xxx
dmi.product.sku: 8BS92EA#AKD
dmi.sys.vendor: HP

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

This change was made by a bot.

[Andrzej Mendel-Nykorowycz (kelner)]

This bug is present also in mainline kernels and appears to be introduced between 5.18 and 5.19. I am now bisecting these versions to find the offending commit.

[Andrzej Mendel-Nykorowycz (kelner)]

"I have found out that loading rtw88_pci with disable_aspm=1 and disable_msi=1 fixes the issue." - Please disregard this.

[Kai-Heng Feng (kaihengfeng)]

Do both parameters are needed?
Maybe "disable_aspm=1" alone can do the trick?

[Andrzej Mendel-Nykorowycz (kelner)]

After some more testing, I don't think these parameters matter. Reloading the module (i.e. removing and inserting it again) sometimes fixes the issue for some time, that's why I thought these settings fixed the issue, but the behaviour after module reload is independent of these parameters.

I have also narrowed down the last working kernel version to 5.18, not 5.16. Another bug seems to be introduced in 5.17 ("failed to get tx report from firmware", "timed out to flush queue 0", "imed out to flush pci tx ring[1]" in dmesg, intermittent failures to send packets) that confounded me. I am currently bisecting commits between 5.18 and 5.19 to find the one that causes the issue in this bug report.

[Andrzej Mendel-Nykorowycz (kelner)]

I've finished kernel bisect and identified 046d2e7c50e3087a32a85fd384c21f896dbccf83 ("mac80211: prepare sta handling for MLO support") as the first bad commit.

[Andrzej Mendel-Nykorowycz (kelner)]

The bug is present in 6.0 but appears fixed in 6.1-rc1 and the current kernel Git head. I've run 6.1-rc1 for several hours and noticed no problems or error messages in dmesg. If there is interest in backporting the fix, I can do a reverse bisect to find it.

[delfi (korkyra52)]

22.04 kernel 5.19.0-32
Asus TUF A15 (AMD 4800H)

rtw_8822ce drama confirmed. No parameters were able to help it work. On some boots everything is fine.

kernel 5.15.0-60 is OK