[BUG] rtw88_8723de: Wi-Fi and Bluetooth fail after warm reboot

[BUG] rtw88_8723de: Wi-Fi and Bluetooth fail after warm reboot

[Snake Pilot]

Hello,

I would like to report a reproducible warm-reboot issue affecting the
Realtek RTL8723DE combo device.  I have included the reproduction steps,
relevant logs, and a tested workaround below.

The RTL8723DE combo device in this HP laptop is unusable after a warm
reboot.  The PCIe Wi-Fi function fails to power on and the USB Bluetooth
function fails to enumerate.  A cold boot restores both functions.

This prevents the laptop from using either Wi-Fi or Bluetooth after a
normal reboot.  The problem is reproducible.  I have also observed the
same behavior while using other Linux distributions.

System information:

  Laptop:             HP Laptop 15-da1xxx
  Product SKU:        18K59LA#ABM
  BIOS:               Insyde F.48, 2024-04-26
  Wi-Fi:              10ec:d723, subsystem 103c:8319
  Bluetooth:          USB 0bda:b009
  Distribution:       Soplos Linux Tyron RC4
  Kernel:             7.1.3+deb14-amd64
  Kernel package:     Debian 7.1.3-1
  Kernel taint:       0
  Driver:             in-tree rtw88_8723de
  Wi-Fi firmware:     48.0.0
  firmware-realtek:   20260622-1

The failing boot used the packaged Debian kernel with the in-tree driver,
no rtw88 module options, and no local shutdown workaround.  The kernel
reported taint value 0 when the failure was captured.

Steps to reproduce:

  1. Start the laptop after a complete power-off.  Wi-Fi and Bluetooth
     work normally.
  2. Reboot Linux normally.
  3. Wi-Fi and Bluetooth are both unavailable after the reboot.
  4. Power off the laptop and hold the power button for about 30 seconds.
  5. Start the laptop.  Wi-Fi and Bluetooth work again.

Expected result:

  Both functions should initialize after a warm reboot.

Actual result:

  The Wi-Fi PCI function remains visible at 02:00.0, but the driver does
  not bind.  The relevant kernel messages are:

  rtw88_8723de 0000:02:00.0: Firmware version 48.0.0, H2C version 0
  rtw88_8723de 0000:02:00.0: failed to poll offset=0x5 mask=0x1 value=0x0
  rtw88_8723de 0000:02:00.0: mac power on failed
  rtw88_8723de 0000:02:00.0: failed to power on mac
  rtw88_8723de 0000:02:00.0: failed to setup chip efuse info
  rtw88_8723de 0000:02:00.0: failed to setup chip information
  rtw88_8723de 0000:02:00.0: probe with driver rtw88_8723de failed with
  error -16

  During the same boot, the Bluetooth USB function fails before btusb can
  bind:

  usb 1-10: device descriptor read/64, error -71
  usb usb1-port10: attempt power cycle
  usb 1-10: device not accepting address 6, error -71
  usb 1-10: device not accepting address 7, error -71
  usb usb1-port10: unable to enumerate USB device

On a successful cold boot the same hardware produces:

  usb 1-10: New USB device found, idVendor=0bda, idProduct=b009
  rtw88_8723de 0000:02:00.0: Firmware version 48.0.0, H2C version 0
  rtw88_8723de 0000:02:00.0 wlo1: renamed from wlan0

Disabling ASPM with the following module option did not change the result:

  options rtw88_pci disable_aspm=1

The option was confirmed active during the test and was removed
afterwards.

The failure can be prevented by stopping NetworkManager and Bluetooth,
unloading btusb and rtw88_8723de, waiting three seconds, and then
rebooting.  On the same system, this workaround completed three
consecutive warm reboots without either failure:

  modprobe -r btusb
  modprobe -r rtw88_8723de
  sleep 3
  reboot

The fact that both bus functions fail together, while an explicit driver
shutdown prevents the failure, appears to indicate that the combo device
retains an invalid power or reset state across warm reboot.

An older report describes the same behavior on an HP 15-da0xxx with the
same PCI and USB identifiers.  It used the driver available in 2018, but
also reported USB error -71, MAC initialization failure after warm reboot,
and recovery after a cold boot:

  https://bbs.archlinux.org/viewtopic.php?id=240675
  https://bugzilla.kernel.org/show_bug.cgi?id=201239

A related RTL8723DE rtw88 power-sequence report is archived here:

  https://www.spinics.net/lists/linux-wireless/msg200831.html

Please let me know which additional traces or tests would help determine
whether the shutdown sequence belongs in rtw88 or requires a platform
quirk.

Thank you for your time and help.

Re: [BUG] rtw88_8723de: Wi-Fi and Bluetooth fail after warm reboot

[Lovekesh Solanki]

Hi,

Could you provide the following:
1) Full dmesg after warm and cold boot
2) 'journalctl -k -b -1' after warm boot

Also please run a few tests,
1) Unload rtw88_8723de only or btusb only and perform warm reboot
and see if both of them are broken while unloading only one driver
2) Repeat the above with a delay like sleep 0, 1, 3, 5
3) Try 'echo 1 | sudo tee /sys/bus/pci/devices/0000:02:00.0/reset' 
after warm reboot see if it pci function reset recovers wifi

Also provide output of 'lspci -vv -s 02:00.0' and 'lsusb -t'
after warm reboot.

That would be helpful.

Thanks, 
Lovekesh

Re: [BUG] rtw88_8723de: Wi-Fi and Bluetooth fail after warm reboot

[Snake Pilot]

[-- Attachment #1: Type: text/plain, Size: 3909 bytes --]

Thank you for the test suggestions. I ran the requested matrix with the
packaged Debian kernel 7.1.3+deb14-amd64 (Debian 7.1.3-1), the in-tree
drivers, and kernel taint 0.

For each module test I unloaded only the named module, added the requested
explicit delay, and rebooted. The normal system shutdown took approximately
four seconds in addition to the explicit delay.

Results:

  Module unloaded       Extra delay    Wi-Fi              Bluetooth
  ------------------------------------------------------------------------
  rtw88_8723de          0 seconds      failed (-16)       failed (-71)
  rtw88_8723de          1 second       failed (-16)       failed (-71)
  rtw88_8723de          3 seconds      failed (-16)       failed (-71)
  rtw88_8723de          5 seconds      failed (-16)       failed (-71)

  btusb                 0 seconds      worked             worked
  btusb                 1 second       worked             worked
  btusb                 3 seconds      worked             worked
  btusb                 5 seconds      worked             worked

Therefore, unloading only rtw88_8723de does not prevent either failure.
Unloading only btusb prevents both failures, even with no explicit delay.

The btusb tests used BlueZ 5.87-1, which was installed before that complete
set of tests. The kernel, btusb module, firmware-realtek package, and Wi-Fi
firmware did not change. The original Bluetooth failure is USB enumeration
error -71 and occurs before btusb or BlueZ can bind.

I also tested the PCI reset attribute after reproducing the failed warm boot.
Before the reset, Wi-Fi had failed with the MAC power-on error and probe error
-16, while Bluetooth had failed to enumerate with error -71. The device was
present at 0000:02:00.0 in D0, reset_method reported "bus", and no Wi-Fi
driver was bound.

Writing 1 to:

  /sys/bus/pci/devices/0000:02:00.0/reset

succeeded. I then requested a reprobe through /sys/bus/pci/drivers_probe.
The reprobe failed again with the same messages:

  rtw88_8723de 0000:02:00.0: mac power on failed
  rtw88_8723de 0000:02:00.0: probe with driver rtw88_8723de failed
with error -16

No Wi-Fi interface appeared, and Bluetooth remained absent. Thus, the PCI bus
reset did not recover the device after the failure had occurred.

The attached archive contains:

  MATRIX.txt
    Complete module/delay test matrix and overall conclusions.

  cold-boot-dmesg.txt
    Complete dmesg after at least 30 seconds powered off, using the same
    Debian kernel.

  cold-boot-lspci-vv.txt
  cold-boot-lsusb-t.txt
    PCI and USB topology from the successful controlled cold boot.

  failing-warm-boot-dmesg.txt
  failing-warm-boot-journal-kernel.txt
    Complete dmesg and journalctl -k output captured during the failing warm
    boot, before attempting the PCI reset.

  previous-boot-journal-kernel.txt
    Complete journalctl -k -b -1 output captured from the failing boot.

  failing-warm-boot-lspci-vv.txt
  failing-warm-boot-lsusb-t.txt
    PCI and USB state during the failure, before the reset.

  pci-reset-result.txt
    Timestamped result of writing 1 to the PCI reset attribute.

  post-pci-reset-dmesg.txt
  post-pci-reset-lspci-vv.txt
    Complete dmesg and PCI state after the reset and failed reprobe.

  package-versions.txt
    Exact BlueZ, firmware-realtek, and Debian kernel package versions.

In the controlled cold-boot capture, USB 0bda:b009 enumerated normally, btusb
bound, rtw88_8723de initialized firmware 48.0.0, and wlo1 appeared. No error
-71, MAC power-on failure, or probe error -16 was logged.

The results suggest that shutdown of the USB Bluetooth function changes the
retained state of the whole combo device, while shutdown of the PCIe Wi-Fi
function alone does not.

Please let me know if you would like a trace around btusb disconnect, USB
power management state, or a test of a specific reset sequence.

Kind regards,
Snake.

[-- Attachment #2: rtl8723de-warm-reboot-evidence-20260730.tar.gz --]
[-- Type: application/gzip, Size: 122559 bytes --]

Re: [BUG] rtw88_8723de: Wi-Fi and Bluetooth fail after warm reboot

[Lovekesh Solanki]

[-- Attachment #1: Type: text/plain, Size: 2029 bytes --]

Thanks for additional testing and logs,

On Fri, Jul 31, 2026 at 03:58:32AM -0600, Snake Pilot wrote:
>   Module unloaded       Extra delay    Wi-Fi              Bluetooth
>   ------------------------------------------------------------------------
>   rtw88_8723de          0 seconds      failed (-16)       failed (-71)
>   rtw88_8723de          1 second       failed (-16)       failed (-71)
>   rtw88_8723de          3 seconds      failed (-16)       failed (-71)
>   rtw88_8723de          5 seconds      failed (-16)       failed (-71)
> 
>   btusb                 0 seconds      worked             worked
>   btusb                 1 second       worked             worked
>   btusb                 3 seconds      worked             worked
>   btusb                 5 seconds      worked             worked
I'd say this rules out anything in rtw88 and we should focus on btusb,
since unloading it fixed both functions.

> No Wi-Fi interface appeared, and Bluetooth remained absent. Thus, the PCI bus
> reset did not recover the device after the failure had occurred.
Yeah and with -71 above seems like chip isn't answering read descriptors
at all.

The previous boot journal there's no other bluetooth activity logged
after boot, so a graceful bluetooth shutdown doesn't seem to be
happening on a warm reboot, but it does work when you explicitely unbind
it.

Problem could be in the power state chip may be left in a state warm
reboot cannot clear.

A somewhat similar issue with the Qualcomm QCA6390 combo 7e7bbddd029b
("qca6390 enable failure after warm reboot"), where they fixed it by
simply making sure chip got proper reset/shutdown command before
restart. This could also work for our case but needs confirmation.

I'm attaching a small patch that just adds extra logging around the 
shutdown path for this chip to see what's been invoked and what not
before a warm reboot and if it even completes.

Could you apply it and perform a simple warm reboot and send the
journalctl -k -b -1 after it?

Regards, 
Lovekesh


[-- Attachment #2: diag.patch --]
[-- Type: text/plain, Size: 3982 bytes --]

diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c
index 7f54d2d..b78feb7 100644
--- a/drivers/bluetooth/btrtl.c
+++ b/drivers/bluetooth/btrtl.c
@@ -1402,6 +1402,8 @@ int btrtl_shutdown_realtek(struct hci_dev *hdev)
 	struct sk_buff *skb;
 	int ret;
 
+	bt_dev_info(hdev, "diag: btrtl_shutdown_realtek: sending HCI_OP_RESET");
+
 	/* According to the vendor driver, BT must be reset on close to avoid
 	 * firmware crash.
 	 */
@@ -1411,6 +1413,7 @@ int btrtl_shutdown_realtek(struct hci_dev *hdev)
 		bt_dev_err(hdev, "HCI reset during shutdown failed");
 		return ret;
 	}
+	bt_dev_info(hdev, "diag: btrtl_shutdown_realtek: HCI_OP_RESET completed OK");
 	kfree_skb(skb);
 
 	return 0;
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 184e95c..382ff81 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -4470,6 +4470,8 @@ static void btusb_disconnect(struct usb_interface *intf)
 	struct btusb_data *data = usb_get_intfdata(intf);
 	struct hci_dev *hdev;
 
+	bt_dev_info(data ? data->hdev : NULL, "diag: btusb_disconnect called for intf %p", intf);
+
 	BT_DBG("intf %p", intf);
 
 	if (!data)
@@ -4682,6 +4684,15 @@ static void btusb_coredump(struct device *dev)
 }
 #endif
 
+static void btusb_shutdown(struct device *dev)
+{
+	struct usb_interface *intf = to_usb_interface(dev);
+	struct btusb_data *data = usb_get_intfdata(intf);
+
+	pr_info("btusb: diag: device_shutdown() reached btusb for intf %p, hdev up=%d\n",
+		intf, data && data->hdev ? test_bit(HCI_UP, &data->hdev->flags) : -1);
+}
+
 static struct usb_driver btusb_driver = {
 	.name		= "btusb",
 	.probe		= btusb_probe,
@@ -4692,11 +4703,12 @@ static struct usb_driver btusb_driver = {
 	.supports_autosuspend = 1,
 	.disable_hub_initiated_lpm = 1,
 
-#ifdef CONFIG_DEV_COREDUMP
 	.driver = {
+#ifdef CONFIG_DEV_COREDUMP
 		.coredump = btusb_coredump,
-	},
 #endif
+		.shutdown = btusb_shutdown,
+	},
 };
 
 module_usb_driver(btusb_driver);
diff --git a/drivers/net/wireless/realtek/rtw88/mac.c b/drivers/net/wireless/realtek/rtw88/mac.c
index eaa928b..49c5d07 100644
--- a/drivers/net/wireless/realtek/rtw88/mac.c
+++ b/drivers/net/wireless/realtek/rtw88/mac.c
@@ -166,12 +166,16 @@ static int rtw_pwr_cmd_polling(struct rtw_dev *rtwdev,
 
 	/* if PCIE, toggle BIT_PFM_WOWL and try again */
 	value = rtw_read8(rtwdev, REG_SYS_PW_CTRL);
+	rtw_info(rtwdev, "diag: pre-toggle REG_SYS_PW_CTRL=0x%02x, poll offset=0x%x want=0x%x\n",
+		 value, offset, cmd->value & cmd->mask);
 	if (rtwdev->chip->id == RTW_CHIP_TYPE_8723D)
 		rtw_write8(rtwdev, REG_SYS_PW_CTRL, value & ~BIT_PFM_WOWL);
 	rtw_write8(rtwdev, REG_SYS_PW_CTRL, value | BIT_PFM_WOWL);
 	rtw_write8(rtwdev, REG_SYS_PW_CTRL, value & ~BIT_PFM_WOWL);
 	if (rtwdev->chip->id == RTW_CHIP_TYPE_8723D)
 		rtw_write8(rtwdev, REG_SYS_PW_CTRL, value | BIT_PFM_WOWL);
+	rtw_info(rtwdev, "diag: post-toggle REG_SYS_PW_CTRL=0x%02x, retry poll read=0x%02x\n",
+		 rtw_read8(rtwdev, REG_SYS_PW_CTRL), rtw_read8(rtwdev, offset));
 
 	if (do_pwr_poll_cmd(rtwdev, offset, cmd->mask, cmd->value))
 		return 0;
diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index c8d1412..17dfc92 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -5416,11 +5416,19 @@ static int hci_dev_shutdown(struct hci_dev *hdev)
 	bool was_userchannel =
 		hci_dev_test_and_clear_flag(hdev, HCI_USER_CHANNEL);
 
+	bt_dev_info(hdev, "diag: hci_dev_shutdown: HCI_UP=%d HCI_UNREGISTER=%d shutdown_cb=%ps",
+		    test_bit(HCI_UP, &hdev->flags),
+		    hci_dev_test_flag(hdev, HCI_UNREGISTER),
+		    hdev->shutdown);
+
 	if (!hci_dev_test_flag(hdev, HCI_UNREGISTER) &&
 	    test_bit(HCI_UP, &hdev->flags)) {
 		/* Execute vendor specific shutdown routine */
-		if (hdev->shutdown)
+		if (hdev->shutdown) {
+			bt_dev_info(hdev, "diag: calling vendor shutdown callback");
 			err = hdev->shutdown(hdev);
+			bt_dev_info(hdev, "diag: vendor shutdown returned %d", err);
+		}
 	}
 
 	if (was_userchannel)