Re: [BUG] rtw88_8723de: Wi-Fi and Bluetooth fail after warm reboot
Snake Pilot <[email protected]> Sat, 1 Aug 2026 02:00:12 -0600
| Newsgroups | org.kernel.vger.linux-usb,org.kernel.vger.linux-kernel,org.kernel.vger.linux-wireless |
|---|---|
| Message-ID | <CA+fxq6hD-duO3g1gEEQL5o+_S-y8dfFDerD58=scNsd9WfdU5Q@mail.gmail.com> |
Hello Lovekesh, Thank you for the diagnostic patch. I applied it to the Debian 7.1.3-1 source and rebuilt the affected bluetooth, btusb/btrtl, and rtw88 modules. The test boot used kernel 7.1.3+deb14-amd64. The kernel taint was 12288 due to the locally built, unsigned modules. I started from a cold boot where both Wi-Fi and Bluetooth worked, disabled the existing shutdown workaround for this reboot, and performed a normal warm reboot to the same patched kernel. The warm reboot reproduced both failures. At the actual warm shutdown (01:35:26), the previous-boot journal shows that the Bluetooth core shutdown path and Realtek callback did run and reported success: Bluetooth: hci0: diag: hci_dev_shutdown: HCI_UP=1 HCI_UNREGISTER=0 shutdown_cb=btrtl_shutdown_realtek [btrtl] Bluetooth: hci0: diag: calling vendor shutdown callback Bluetooth: hci0: diag: btrtl_shutdown_realtek: sending HCI_OP_RESET Bluetooth: hci0: diag: btrtl_shutdown_realtek: HCI_OP_RESET completed OK Bluetooth: hci0: diag: vendor shutdown returned 0 However, there is no `btusb: diag: device_shutdown()` message and no `diag: btusb_disconnect` message in that boot journal. While checking why the btusb shutdown message was absent, I noticed that `usb_register_driver()` unconditionally assigns: new_driver->driver.shutdown = usb_shutdown_interface; Therefore the diagnostic callback assigned through `btusb_driver.driver.shutdown` is overwritten during USB driver registration. USB interface drivers expose their own callback through the top-level `struct usb_driver.shutdown` member instead (for example, uas_driver). A follow-up diagnostic callback would need the `struct usb_interface *` signature and this registration: static void btusb_shutdown(struct usb_interface *intf) ... .shutdown = btusb_shutdown, This explains the missing btusb shutdown log, although it does not by itself explain or fix the retained hardware state. I can test a corrected diagnostic or a specific USB reset/shutdown sequence if useful. For completeness, an identical successful HCI shutdown sequence also appears once during initial boot at 01:30:57. The sequence at 01:35:26 is the one from the tested warm shutdown. On the next boot, Bluetooth again failed to enumerate with error -71. The rtw88 diagnostic logging showed: rtw88_8723de 0000:02:00.0: diag: pre-toggle REG_SYS_PW_CTRL=0x12, poll offset=0x5 want=0x0 rtw88_8723de 0000:02:00.0: diag: post-toggle REG_SYS_PW_CTRL=0x1a, retry poll read=0x01 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 was created and the Bluetooth USB interfaces were absent. I had to use the 30-second complete power-off procedure to recover the combo device afterward. I attached `journal-kernel-previous.txt`, which is the requested complete `journalctl -k -b -1` output. I also attached `journal-kernel-current.txt` because it contains the rtw88 register diagnostics and the reproduced -71/-16 failures from the boot immediately following that shutdown. Regards, Snake El vie, 31 jul 2026 a la(s) 2:30 p.m., Lovekesh Solanki ([email protected]) escribió: > > 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 >
journal-kernel-previous.txt
(text/plain, 107.3 KB) - not displayed
journal-kernel-current.txt
(text/plain, 102 KB) - not displayed