Bugzilla – Bug 1212808
WiFi not available for Realtek device
Last modified: 2024-06-25 17:44:42 UTC
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Build Identifier: If I boot a live Tumbleweed system, then WiFi is available. With Leap 15.5, it is not available. If I use the kernel from Kernel:/stable:/Backport/standard/ then WiFi is available with 15.5. But it is not available with the standard kernel for 15.5. Currently running kernel 6.4.0-lp154.2.gd68cda5-default which does see the device, and appear to be using "rtw89_8852be" as driver. Reproducible: Always This is a new computer. I'm reporting as a feature request. Personally, I'm not using WiFi on this computer, so this is not particularly urgent for me.
I need to correct this. It was kernel 6.3.9-lp154.2.1.g0df701d where WiFi actually worked. It did not work with 6.4.0-lp154.2.1.gd68cda5. I have since updated to 6.4.0-lp154.3.g6484854-default and it still does not work.
Yes, some RTW89 Wifi Chips are not supported by Leap (15.4 and 15.5) So post: zypper se -si kernel rtw zypper lr -d uname -a lsb-release -id But you could use the Hardware Repo.
Edit Also show lsusb /sbin/lspci -nnk | grep -EA3 "Network|Ethernet"
Created attachment 867898 [details] Typescript with output of requested commands Response to Stephan: I'm posting a "typescript" file showing the output from the requested commands.
1. Why not using a normal "txt"-File. 2. I would delete the 6.4 kernel, delete the kernel:stable:backports Repo and use this Repo: https://download.opensuse.org/repositories/hardware/15.5/ Install rtw89 and if secure boot is enabled you get maybe the blue Mok screen on reboot, add the key as described here: https://en.opensuse.org/SDB:NVIDIA_drivers#Secureboot
>1. Why not using a normal "txt"-File. It is basically a text file. But, looking at it, I see that "zypper" output includes lots of escape sequences to give colored output. I should probably have used "--terse" or "TERM=dumb" for that command. It's one of the annoying things about "zypper". I just used the "script" command to generate a transcript of the session. >2. I would delete the 6.4 kernel, delete the kernel:stable:backports Repo and use this Repo: I tried that, after your mention of the hardware repo. But still no WiFi. --- # dmesg | grep -i rtw [ 1.716152] rtw89core: loading out-of-tree module taints kernel. [ 1.855848] rtw89_8852be 0000:02:00.0: Direct firmware load for rtw89/rtw8852b_fw-1.bin failed with error -2 [ 1.855854] rtw89_8852be 0000:02:00.0: Direct firmware load for rtw89/rtw8852b_fw.bin failed with error -2 [ 1.855855] rtw89_8852be 0000:02:00.0: failed to early request firmware: -2 [ 1.855940] rtw89_8852be 0000:02:00.0: Direct firmware load for rtw89/rtw8852b_fw.bin failed with error -2 [ 1.855946] rtw89_8852be 0000:02:00.0: enabling device (0000 -> 0003) [ 1.857161] rtw89_8852be 0000:02:00.0: failed to wait firmware completion [ 1.857172] rtw89_8852be 0000:02:00.0: failed to setup chip information [ 1.858012] rtw89_8852be: probe of 0000:02:00.0 failed with error -22 --- Seems to be a firmware problem. Similarly, booting with that 6.4 kernel, I got firmware problem messages. But it worked with a 6.3.9 kernel. And it works in Tumbleweed (6.3.9 kernel). I tried installing firmware from the kernel-backport repo, but that did not help. So I have reverted to the origin 15.5 firmware.
Did you install the latest version of kernel-firmware-* package from OBS Kernel:stable:Backport repo?
I did not keep good notes, so this is from my memory. With a 6.3.9 kernel from Kernel:stable:backport everything worked fine. When I tried a 6.4.0 kernel from that repo, there was no WiFi. So I tried installing the firmware from that repo, but still no wifi. I then tried the drivers from the hardware repo (for Leap) as suggested by Stephan. Still no WiFi. So I uninstalled that firmware and reverted to the firmware from the Leap 15.5 install. But still no WiFi. That's about where we are today. My inclination is to just wait until Tumbleweed upgrades to a 6.4 kernel, and then retest with Tumbleweed (which I have installed in an alternative partition). Thanks for looking at this.
If you use the kmp from Hardware Repo, you have to run the kernel from the responding OSS (SLE-Update) Repo. f. e. Hardware Repo for openSUSE Leap 15.5, Kernel from openSUSE Leap 15.5 OSS (SLE-Update) Repo Do you do this?
>Do you do this? Yes, I'm aware of that requirement. I'm currently using kernel "5.14.21-150500.53-default".
An update on this. Tumbleweed has now updated to a 6.4.2 kernel, and WiFi continues to work with Tumbleweed. On Leap 15.5, I am now running kernel 6.4.3-lp154.4.g5ab030f-default (from the repo /Kernel:/stable:/Backport/standard/ but no WiFi. I upgraded firmware to that repo, and still now WiFi. % dmesg | grep -i rtw [ 16.727732] rtw89_8852be 0000:02:00.0: Direct firmware load for rtw89/rtw8852b_fw-1.bin failed with error -2 [ 16.727738] rtw89_8852be 0000:02:00.0: Direct firmware load for rtw89/rtw8852b_fw.bin failed with error -2 [ 16.727739] rtw89_8852be 0000:02:00.0: failed to early request firmware: -2 [ 16.728312] rtw89_8852be 0000:02:00.0: enabling device (0000 -> 0003) [ 16.742720] rtw89_8852be 0000:02:00.0: Firmware version 0.27.32.1, cmd version 0, type 1 [ 16.742724] rtw89_8852be 0000:02:00.0: Firmware version 0.27.32.1, cmd version 0, type 3 [ 16.742728] rtw89_8852be 0000:02:00.0: MAC has already powered on [ 16.748882] rtw89_8852be 0000:02:00.0: [ERR]pci config read 719 [ 16.749275] rtw89_8852be 0000:02:00.0: [ERR] pcie autok fail -22 [ 16.749658] rtw89_8852be 0000:02:00.0: failed to setup chip information [ 16.751687] rtw89_8852be: probe of 0000:02:00.0 failed with error -22
(In reply to Neil Rickert from comment #11) > [ 16.727732] rtw89_8852be 0000:02:00.0: Direct firmware load for > rtw89/rtw8852b_fw-1.bin failed with error -2 > [ 16.727738] rtw89_8852be 0000:02:00.0: Direct firmware load for > rtw89/rtw8852b_fw.bin failed with error -2 And actually neither of them are present on Leap 15.5 system? Or the error came up even though those files exist?
>And actually neither of them are present on Leap 15.5 system? The compressed version of both files exist: % ls /lib/firmware/rtw89 rtw8851b_fw.bin.xz rtw8852b_fw-1.bin.xz rtw8852c_fw.bin.xz rtw8852a_fw.bin.xz rtw8852b_fw.bin.xz The files seem to be identical to those in Tumbleweed (comparing MD5 checksum). Should I try manually decompressing?
No, the kernel must support decoding by itself. Then the question is why loading those files failed. Was it the place where running in initrd? If yes, check the initrd content. If those files are missing there (while the module is found), you'd need to add the firmware files manually to initrd.
Selected from "dmesg" output: [ 16.283752] systemd[1]: initrd-switch-root.service: Deactivated successfully. [ 16.283924] systemd[1]: Stopped Switch Root. [ 16.284033] systemd[1]: haveged.service: Stop job pending for unit, skipping automatic restart. [ 16.284257] systemd[1]: systemd-journald.service: Scheduled restart job, restart counter is at 1. [ 16.284490] systemd[1]: Created slice Virtual Machine and Container Slice. [ 16.285281] systemd[1]: Created slice Slice /system/getty. [ 16.285892] systemd[1]: Created slice Slice /system/modprobe. [ 16.286329] systemd[1]: Created slice Slice /system/systemd-fsck. [ 16.286941] systemd[1]: Created slice User and Session Slice. [ 16.287437] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point. [ 16.287897] systemd[1]: Reached target Block Device Preparation for /dev/mapper/cr_nwrdell. [ 16.287935] systemd[1]: Stopped target Switch Root. [ 16.287953] systemd[1]: Stopped target Initrd File Systems. [ 16.287964] systemd[1]: Stopped target Initrd Root File System. ... [ 16.727732] rtw89_8852be 0000:02:00.0: Direct firmware load for rtw89/rtw8852b_fw-1.bin failed with error -2 [ 16.727738] rtw89_8852be 0000:02:00.0: Direct firmware load for rtw89/rtw8852b_fw.bin failed with error -2 [ 16.727739] rtw89_8852be 0000:02:00.0: failed to early request firmware: -2 [ 16.728312] rtw89_8852be 0000:02:00.0: enabling device (0000 -> 0003) [ 16.742720] rtw89_8852be 0000:02:00.0: Firmware version 0.27.32.1, cmd version 0, type 1 [ 16.742724] rtw89_8852be 0000:02:00.0: Firmware version 0.27.32.1, cmd version 0, type 3 [ 16.742728] rtw89_8852be 0000:02:00.0: MAC has already powered on So it looks as this is after it has finished running with the "initrd".
Weird. Could you boot with a boot option firmware_class.dyndbg=+p and give the (complete) dmesg output?
Created attachment 868225 [details] Full output of "dmesg" after booting with firmware_class.dyndbg=+p Attaching output from dmesg shortly after booting.
Could you try to uncompress rtw89/rtw8852b_fw-1.bin.xz and rtw89/rtw8852b_fw.bin.xz in /lib/firmware? % unxz --keep /lib/firmware/rtw89/rtw8852b_fw-1.bin.xz % unxz --keep /lib/firmware/rtw89/rtw8852b_fw.bin.xz and retest?
After uncompressing the firmware, there is still no WiFi. % dmesg | grep -i rtw [ 17.507914] rtw89_8852be 0000:02:00.0: loaded firmware rtw89/rtw8852b_fw-1.bin [ 17.508047] rtw89_8852be 0000:02:00.0: enabling device (0000 -> 0003) [ 17.512624] rtw89_8852be 0000:02:00.0: Firmware version 0.29.29.1, cmd version 0, type 5 [ 17.512627] rtw89_8852be 0000:02:00.0: Firmware version 0.29.29.1, cmd version 0, type 3 [ 17.512639] rtw89_8852be 0000:02:00.0: MAC has already powered on [ 17.518857] rtw89_8852be 0000:02:00.0: [ERR]pci config read 719 [ 17.519230] rtw89_8852be 0000:02:00.0: [ERR] pcie autok fail -22 [ 17.519659] rtw89_8852be 0000:02:00.0: failed to setup chip information [ 17.521959] rtw89_8852be: probe of 0000:02:00.0 failed with error -22
OK, at least the firmware problem was worked around it. It was a bug in the driver. I'll fix it up later, but keep the uncompressed firmware as is for now. The remaining problem is that the initialization fails like: [ 17.518857] rtw89_8852be 0000:02:00.0: [ERR]pci config read 719 [ 17.519230] rtw89_8852be 0000:02:00.0: [ERR] pcie autok fail -22 [ 17.519659] rtw89_8852be 0000:02:00.0: failed to setup chip information This needs further investigation. There are a few old kernels in my OBS repos, e.g. home:tiwai:kernel:6.3, home:tiwai:kernel:6.2, etc. Each project contains "backport" repo that is built for Leap. Could you try those to identify which kernel works and which kernel fails? This may help to narrow down a possible regression and/or its fix.
>Could you try those to identify which kernel works and which kernel fails? I've done some testing, but no joy. 6.3.9-lp154.1.1.g0df701d -- No WiFi with this kernel 6.2.12-lp154.1.1.geb3255d -- no WiFi with this kernel 6.1.12-lp154.1.1.g373f017 -- and no WiFi with this kernel. However, it was working with "kernel-default-6.3.9-lp154.2.1.g0df701d" which I installed on June 25 (according to history), but I have since deleted. Unfortunately this one is not in your repos as far as I can tell.
(In reply to Neil Rickert from comment #21) > >Could you try those to identify which kernel works and which kernel fails? > > I've done some testing, but no joy. > > 6.3.9-lp154.1.1.g0df701d -- No WiFi with this kernel > 6.2.12-lp154.1.1.geb3255d -- no WiFi with this kernel > 6.1.12-lp154.1.1.g373f017 -- and no WiFi with this kernel. > > However, it was working with "kernel-default-6.3.9-lp154.2.1.g0df701d" which > I installed on June 25 (according to history), but I have since deleted. > Unfortunately this one is not in your repos as far as I can tell. It must be more or less the same code, as the hash number indicates. It implies that something else than kernel made it broken. And, if you reload the driver, it shows the same error?
>And, if you reload the driver, it shows the same error? Yes, it does. Since I don't really need WiFi on this system, I guess I just put up with this. I may occasionally test again with future kernels from that backport repo.
A patch to eliminate the call to request_partial_firmware_into_buf() was accepted into the kernel today, and added to my rtw89 repo. AS that GitHub repo is the source for the driver in Hardware:, it should be updated soon. Similarly, it should be in kernel 6.5-rc4, and backported to 6.4.X soon afterward. I am closing this b.o.o entry.
Updated the driver in Hardware Repo.