WIFI RTL8852BE Disappeared from EVERYWHERE including "lspci"

Support and Help
,
1

Ubuntu Version

Ubuntu 24.04 LTS Flavors

Desktop Environment (if applicable)

Cinnamon

Problem Description

Just recently laptop’s WIFI RTL8852BE was working perfectly.
Likely after yesterday OS update it disappeared from EVERYWHERE including “lspci” and iwconfig.

“sudo lspci -vnnn |grep -A20 RTL8852BE” was showing the below earlier BEFORE this issue started:
"
pcilib: Error reading /sys/bus/pci/devices/0000:00:08.3/label: Operation not permitted
02:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8852BE PCIe 802.11ax Wireless Network Controller [10ec:b852]
Subsystem: Lenovo RTL8852BE PCIe 802.11ax Wireless Network Controller [17aa:4853]
…
"

Multiple reboots did NOT help.

Relevant modules are no longer loaded by default, thus:
“lsmod | grep rtw89”
returns nothing .

Kernel 6.17.0-14-generic (has been the same for months).
How to investigate this issue further?

Not a single change or update w.r.t. to BIOS or laptop’s HW.
Thank you.

Relevant System Information

WIFI RTL8852BE card.
Thinkbook G7 ARP laptop.

Error Messages / Logs

sudo lspci -vnnn |grep -A20 RTL8852BE

pcilib: Error reading /sys/bus/pci/devices/0000:00:08.3/label: Operation not permitted

With dock connected:
iwconfig
lo no wireless extensions.
enp1s0 no wireless extensions.
enx54bf6404423e no wireless extensions.
lxcbr0 no wireless extensions.

What I’ve Tried

  • Made sure WIFI is enabled in BIOS

  • sudo modprobe rtw89_8852be

  • Multiple reboots

  • “/etc/modprobe.d” contains NO single file that was changed after April 2026, so it cannot be the cause.

  • “sudo dmesg |grep -A20 rtw89” returns nothing at all.

Ubuntu Weekly Newsletter Issue 962
2

Realtek PCIe cards can freeze or drop off the bus entirely due to residual static charge on the motherboard.

  1. Shut down your ThinkBook completely.

  2. Unplug the power adapter and disconnect all external USB peripherals or cables.

  3. Press and hold down the Power Button continuously for 60 seconds (do not let go, even if the laptop flashes or turns on/off).

  4. Release the button, plug the power adapter back in, and turn the laptop on.

3 Likes
4

Jeff, one thing worth adding to what @Actionparsnip said: your symptoms point at the PCI bus layer, not at the driver.

You mentioned lsmod | grep rtw89 returns nothing and that sudo modprobe rtw89_8852be doesn’t bring the card back. That’s the expected outcome here — if the device has dropped off the bus, the module has nothing to bind to, so modprobe succeeds but changes nothing. The clue is that lspci no longer lists the card at all. A blacklisted module or a broken initramfs would leave the device visible in lspci and only affect lsmod. Your case is the other way around, which is why reboots and modprobe can’t help.

The pcilib: Error reading .../label: Operation not permitted line is unrelated — it’s lspci complaining about a sysfs permission issue, not evidence about the card.

To confirm the link really is down at the hardware level, check the kernel log for PCIe errors instead of for rtw89:

sudo dmesg -T | grep -iE 'pcie|aer|0000:02:00.0'

If the link went down you’ll typically see messages from pcieport about a link training failure or an AER (Advanced Error Reporting) entry for 0000:02:00.0. Those messages are what separate a dead link from a missing driver.

If the static-discharge procedure above doesn’t bring it back and you want to avoid opening the machine, rescan the PCI bus first:

echo 1 | sudo tee /sys/bus/pci/rescan

It won’t fix a physically-failed link, but if the controller only soft-failed it can re-enumerate the device without a full power cycle, and it’s harmless to try.

I’ve hit a card dropping off the PCI bus like this on different hardware, but I don’t have your ThinkBook so I can’t promise this is it — the dmesg output above is the fastest way to tell.

2 Likes
5

Thank you. Would I also need to disconnect internal laptop’s battery?

6

Thank you.

sudo dmesg -T | grep -iE 'pcie|aer|0000:02:00.0'     
[Sun Sep 20 06:40:15 2026] ACPI: USB4 _OSC: OS supports USB3+ DisplayPort+ PCIe+ XDomain+    
[Sun Sep 20 06:40:15 2026] ACPI: USB4 _OSC: OS controls USB3+ DisplayPort+ PCIe+ XDomain+           
[Sun Sep 20 06:40:15 2026] acpi PNP0A08:00: _OSC: platform does not support [SHPCHotplug AER]       
[Sun Sep 20 06:40:15 2026] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME PCIeCapability LTR DPC]
[Sun Sep 20 06:40:15 2026] pci 0000:00:02.1: [1022:14ba] type 01 class 0x060400 PCIe Root Port
[Sun Sep 20 06:40:15 2026] pci 0000:00:02.3: [1022:14ba] type 01 class 0x060400 PCIe Root Port
[Sun Sep 20 06:40:15 2026] pci 0000:00:02.4: [1022:14ba] type 01 class 0x060400 PCIe Root Port
[Sun Sep 20 06:40:15 2026] pci 0000:00:04.1: [1022:14cd] type 01 class 0x060400 PCIe Root Port
[Sun Sep 20 06:40:15 2026] pci 0000:00:08.1: [1022:14b9] type 01 class 0x060400 PCIe Root Port
[Sun Sep 20 06:40:15 2026] pci 0000:00:08.3: [1022:14b9] type 01 class 0x060400 PCIe Root Port
[Sun Sep 20 06:40:15 2026] pci 0000:01:00.0: [10ec:8168] type 00 class 0x020000 PCIe Endpoint
[Sun Sep 20 06:40:15 2026] pci 0000:02:00.0: [1217:8621] type 00 class 0x080501 PCIe Endpoint
[Sun Sep 20 06:40:15 2026] pci 0000:02:00.0: BAR 0 [mem 0x98901000-0x98901fff]
[Sun Sep 20 06:40:15 2026] pci 0000:02:00.0: BAR 1 [mem 0x98900000-0x989007ff]
[Sun Sep 20 06:40:15 2026] pci 0000:02:00.0: PME# supported from D3hot D3cold
[Sun Sep 20 06:40:15 2026] pci 0000:03:00.0: [144d:a80d] type 00 class 0x010802 PCIe Endpoint
[Sun Sep 20 06:40:15 2026] pci 0000:74:00.0: [1002:1681] type 00 class 0x030000 PCIe Legacy Endpoint
[Sun Sep 20 06:40:15 2026] pci 0000:74:00.1: [1002:1640] type 00 class 0x040300 PCIe Legacy Endpoint                   [Sun Sep 20 06:40:15 2026] pci 0000:74:00.2: [1022:1649] type 00 class 0x108000 PCIe Endpoint
[Sun Sep 20 06:40:15 2026] pci 0000:74:00.3: [1022:161d] type 00 class 0x0c0330 PCIe Endpoint
[Sun Sep 20 06:40:15 2026] pci 0000:74:00.4: [1022:161e] type 00 class 0x0c0330 PCIe Endpoint
[Sun Sep 20 06:40:15 2026] pci 0000:74:00.5: [1022:15e2] type 00 class 0x048000 PCIe Endpoint
[Sun Sep 20 06:40:15 2026] pci 0000:74:00.6: [1022:15e3] type 00 class 0x040300 PCIe Endpoint
[Sun Sep 20 06:40:15 2026] pci 0000:75:00.0: [1022:161f] type 00 class 0x0c0330 PCIe Endpoint
[Sun Sep 20 06:40:15 2026] pci 0000:75:00.3: [1022:15d6] type 00 class 0x0c0330 PCIe Endpoint
[Sun Sep 20 06:40:15 2026] pci 0000:75:00.4: [1022:15d7] type 00 class 0x0c0330 PCIe Endpoint
[Sun Sep 20 06:40:15 2026] pci 0000:75:00.6: [1022:162f] type 00 class 0x0c0340 PCIe Endpoint
[Sun Sep 20 06:40:15 2026] pci 0000:02:00.0: Adding to iommu group 13
[Sun Sep 20 06:40:15 2026] pcieport 0000:00:02.1: PME: Signaling with IRQ 37
[Sun Sep 20 06:40:15 2026] pcieport 0000:00:02.3: PME: Signaling with IRQ 38
[Sun Sep 20 06:40:15 2026] pcieport 0000:00:02.4: PME: Signaling with IRQ 39
[Sun Sep 20 06:40:15 2026] pcieport 0000:00:04.1: PME: Signaling with IRQ 40
[Sun Sep 20 06:40:15 2026] pcieport 0000:00:04.1: pciehp: Slot #0 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surp
rise+ Interlock- NoCompl+ IbPresDis- LLActRep+
[Sun Sep 20 06:40:15 2026] pcieport 0000:00:08.1: PME: Signaling with IRQ 41
[Sun Sep 20 06:40:15 2026] pcieport 0000:00:08.3: PME: Signaling with IRQ 42
[Sun Sep 20 06:40:15 2026] sdhci-pci 0000:02:00.0: SDHCI controller found [1217:8621] (rev 1)
[Sun Sep 20 06:40:15 2026] sdhci-pci 0000:02:00.0: enabling device (0000 -> 0002)
[Sun Sep 20 06:40:15 2026] mmc0: SDHCI controller on PCI [0000:02:00.0] using ADMA
[Sun Sep 20 06:40:28 2026] [drm] PCIE GART of 1024M enabled (table at 0x000000F41FC00000).
[Sun Sep 20 10:41:39 2026] pcieport 0000:00:08.3: quirk: disabling D3cold for suspend
[Sun Sep 20 10:41:40 2026] [drm] PCIE GART of 1024M enabled (table at 0x000000F41FC00000).

Yes, already tried rescanning PCI with zero result. Will try static discharge a bit later.

7

If you can… Sure. Just needs the power draining

1 Like
8

Jeff, thanks for posting the log — it actually tells us something specific.

The important line is this one:

pci 0000:02:00.0: [1217:8621] type 00 class 0x080501 PCIe Endpoint
sdhci-pci 0000:02:00.0: SDHCI controller found [1217:8621] (rev 1)

1217:8621 is an O2Micro OZ711 SD/MMC card reader, not a network controller. So bus address 02:00.0, the very slot your RTL8852BE used to sit on, is now occupied by a different device.

And the RTL8852BE itself is nowhere in the log at all. No 10ec:b852, no rtw89, nothing. It is not that the card was detected and then failed — it was never enumerated during boot.

That is a stronger statement than I made earlier, and it partly corrects it. I said you’d “typically see” a link training failure or an AER entry if the link went down. Your log has neither. No AER errors, no link training messages, no hotplug removal event for 00:08.3. The root port is there and quiet. So there is no kernel record of the link ever coming up and going bad on this boot — the card was simply absent when the kernel enumerated the bus.

That changes what’s worth trying next. The static discharge step is still the right first move, but if the card has dropped off so completely that the BIOS does not see it either, then driver-side troubleshooting (modprobe, modprobe.d, initramfs) is provably exhausted — nothing to bind to.

Two things to check after the power drain, in this order:

  1. Does the card come back in the firmware? Enter the BIOS/UEFI setup and look at the devices or network list there. Firmware enumeration happens before the kernel, so if the card is missing in the BIOS too, the OS layer is ruled out entirely.

  2. Is the card visible in a different OS? A Ubuntu live USB is quickest. If a fresh kernel from a clean boot also does not see it, that points away from the kernel update as the trigger.

About your question on the internal battery: it is not strictly required for draining residual charge, but if your ThinkBook has an internal battery and it is easy to reach, disconnecting it makes the drain complete. Holding power for 60 seconds with only the adapter unplugged is the documented minimum. The external battery on the G7 ARP is removable, so that alone may be enough.

One caveat on cause: it is worth double checking whether the card is soldered. Some ThinkBook WiFi modules sit in a socketed M.2 CNVio slot and can work loose from thermal cycling; others are soldered to the board, in which case no amount of re-seating helps. I could not verify which one the G7 ARP uses from Lenovo’s spec page.

If the card remains invisible in BIOS after the drain, that is a warranty or service-center problem, not a software one. Your data on the lspci-before output and the unchanged kernel version is useful to have ready in that conversation.

2 Likes
9

Hmm… AMD engineers would probably get a heart attack if Intel’s proprietary CNVio showed up on their Ryzen platform :grinning_face:

The RTL8852BE is a plain standard PCIe M.2 card. Realtek controllers are notorious for falling into a deep sleep in the PCIe D3cold state after reboots or updates, and power draining the board via the BIOS setting (Config - Power - Disable Built-in Battery) usually wakes the card right back up…

2 Likes
10

Disabling built-in battery brought it back. Thank you guys for such an advanced help!

Every post is so helpful that I’m not sure which one to accept as a solution :grinning_face:

Do you possibly have any links to discussion(s) that go deep into this issue?

Wonder if this is card’s firmware issue, and whether it makes sense to report it to Realtek etc?

Is it WIFI card’s firmware that tells RTL8852BE to go into D3cold state?

Does laptop’s BIOS have anything to do with waking up RTL8852BE on reboot?

1 Like
11

As a non-participant in this topic, I reckon post no. 2 by @Actionparsnip should be marked

2 Likes
12

So,

  1. Who triggers D3cold: The OS kernel and ACPI power management negotiate it to save battery

  2. Why it gets stuck: During warm reboots, capacitors retain charge and Realtek’s PCIe controller fails link training before the root port finishes probing, so the slot looks empty. Disabling the battery drops all voltages to 0V and forces a true hardware cold reset. I actually have the exact same annoying thing at home with my TV and AV receiver hooked up to a single remote - sometimes they get completely stuck in standby handshake, and nothing helps until you literally pull the power cord from the wall to drain it :grinning_face:

  3. Is it known: Yes, Realtek chips are notorious for PCIe sleep state quirks, and the kernel has workarounds for them

And some bedtime reading :slight_smile:

3 Likes
13

Very helpful, thank you!

2 Likes
14

This topic was automatically closed 18 hours after the last reply. New replies are no longer allowed.