http://bugzilla.opensuse.org/show_bug.cgi?id=1206767 http://bugzilla.opensuse.org/show_bug.cgi?id=1206767#c2 --- Comment #2 from Larry Finger --- Created attachment 863759 --> http://bugzilla.opensuse.org/attachment.cgi?id=863759&action=edit Script to unload/reload the RTW8723DE driver when suspending/resuming As stated in README.md in my repo at https://github.com/lwfinger/rtw88.git, which is the actual source for the openSUSE code, some BIOSs have trouble changing power state from D3hot to D0. We believe this to be a BUG in the BIOS, not the driver, as most computers work without difficulty. The workaround is to copy the attached file "suspend_rtw8723de" into /usr/lib/systemd/system-sleep/suspend_rtw8723de, and run the command sudo chmod a+x /usr/lib/systemd/system-sleep/suspend_rtw8723de This script will unload the driver upon suspend or hibernate and reload it upon resume, which avoids the problems with power-state change in the PCI bus. -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1206767 http://bugzilla.opensuse.org/show_bug.cgi?id=1206767#c4 --- Comment #4 from Dave Plater --- I've tried this but I still get a freeze on exit from sleep (you left out the "fi" part of your script btw). I created for the external build module: cat /usr/lib/systemd/system-sleep/suspend_rtw8723de #!/bin/sh if [ "${1}" == "pre" ]; then modprobe -rv rtw_8723de elif [ "${1}" == "post" ]; then modprobe -v rtw_8723de fi and for the kernel's driver: cat /usr/lib/systemd/system-sleep/suspend_rtw88_8723de #!/bin/sh if [ "${1}" == "pre" ]; then modprobe -rv rtw88_8723de elif [ "${1}" == "post" ]; then modprobe -v rtw88_8723de fi I've made /etc/modprobe files for both flavors as well. That's step one, step two is to make the module load as if I had booted to runlevel 1 and then executed init 5 to bring up the gui and I can rattle along until something happens to either the hp's bios or the kernel to reverse whatever brought this on. With the 6.0 kernels I was experiencing spurious wifi disabling and blue tooth enabling on exit from sleep. Then the 6.1.0 kernel caused a lockup as the gui was about to start. The 6.1.1 kernel made things worse in that I can only boot as far as the wifi start stage. It's also possible that my bios was updated by windows 10 and brought on the problem. How can I get logs of the process when it fails? I'm a bit confused by the difference between logs generated by journalctl, /var/log/ Can you see anything wrong with what I have done? -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1206767 http://bugzilla.opensuse.org/show_bug.cgi?id=1206767#c6 --- Comment #6 from Dave Plater --- (In reply to Larry Finger from comment #5)

Do you have access to another Linux computer? If so, then netconsole is a way to get the dmesg log dumped when there is a crash.

The procedure is somewhat involved, thus I will await your positive answer before writing it out.

I've a leap 15.4 pc with a Tumbleweed partition I've got an old fashioned DB7 serial socket on the back and a raspberry pi 3b which is most probably better than the pc. The instruction will be good for me. The most primitive interface on the laptop is ethernet no serial and I've mislaid my usb serial dongle. I found the point of sleep in the journal but there's no wake up message even though the screen from pre sleep displays. -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1206767 http://bugzilla.opensuse.org/show_bug.cgi?id=1206767#c8 Takashi Iwai changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai@suse.com --- Comment #8 from Takashi Iwai --- In general, we need to identify at which timing it crashes. I suppose that the crash happens at re-loading the module after the resume (without the module). If so, you can omit the re-loading part ("post" in the script), and verify that the desktop is still up after the resume, then manually load the module. This will have a better chance to catch the crash log. OTOH, if the crash happens before the re-loading, it means that there was already some corruption (or other reason). -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1206767 http://bugzilla.opensuse.org/show_bug.cgi?id=1206767#c10 --- Comment #10 from Dave Plater --- Also the given options will only load in the rtw_8723de-kmp-default modules and give an error if I attempt to use them with the kernel derived modules. rtw_8723de-kmp-default is from home:plater/rtw88 -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1206767 http://bugzilla.opensuse.org/show_bug.cgi?id=1206767#c12 Larry Finger changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #863759|0 |1 is obsolete| | --- Comment #12 from Larry Finger --- Created attachment 863818 --> http://bugzilla.opensuse.org/attachment.cgi?id=863818&action=edit Script to unload/reload the RTW8723DE driver when suspending/resuming I upgraded the suspend file to detect which driver for the RTW8873DE is loaded. If neither, it merely exits. If either driver is loaded, it will save the name in a file in /root, and unload the driver. At "post" time, if that file in /root does not exist, the routine exits, otherwise it sleeps for an additional time, reloads the original driver, and deletes the file in /root. I set the sleep time to 15. If you have found a better value, then edit the script. -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1206767 http://bugzilla.opensuse.org/show_bug.cgi?id=1206767#c14 --- Comment #14 from Larry Finger --- The script should handle rtw_8723de or rtw88_8723de, whichever you are using. I am going to ask my contact at Realtek if he has any suggestions. The log certainly shows that the device has trouble restarting, even after a 15 sec delay. What load options are you using? -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1206767 http://bugzilla.opensuse.org/show_bug.cgi?id=1206767#c16 --- Comment #16 from Larry Finger --- Thanks to the answer about the logs. My contact at Realtek did not have any suggestions about this problem. He did send me the latest vendor driver, but it does not build on kernels newer than 5.15. Are you satisfied with the current state, or do you want me to modify the newest vendor driver and post the zip file here so that you can build it on your system? -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1206767 http://bugzilla.opensuse.org/show_bug.cgi?id=1206767#c18 --- Comment #18 from Dave Plater --- Created attachment 863912 --> http://bugzilla.opensuse.org/attachment.cgi?id=863912&action=edit Same dmesg --clear the dmesg -w then sleep then wake with wicked. You will notice the big difference between the behavior of the driver under network manager and under wicked. -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1206767 http://bugzilla.opensuse.org/show_bug.cgi?id=1206767#c20 --- Comment #20 from Dave Plater --- See also: https://forum.manjaro.org/t/laptop-overheating-with-rtw-8723de/129718 -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1206767 http://bugzilla.opensuse.org/show_bug.cgi?id=1206767#c21 --- Comment #21 from Larry Finger --- Created attachment 863985 --> http://bugzilla.opensuse.org/attachment.cgi?id=863985&action=edit Alternative driver for rtw_8723de Attached is the vendor driver for the chip. Note: I have not tested this driver. -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1206767 http://bugzilla.opensuse.org/show_bug.cgi?id=1206767#c23 --- Comment #23 from Larry Finger --- I do not understand why running make does not provide a module. The last few lines of a make on my system are CC [M] /home/finger/rtl8723de_new/hal/btc/halbtc8723d2ant.o CC [M] /home/finger/rtl8723de_new/platform/platform_ops.o CC [M] /home/finger/rtl8723de_new/core/rtw_mp.o LD [M] /home/finger/rtl8723de_new/8723de.o MODPOST /home/finger/rtl8723de_new/Module.symvers CC [M] /home/finger/rtl8723de_new/8723de.mod.o LD [M] /home/finger/rtl8723de_new/8723de.ko BTF [M] /home/finger/rtl8723de_new/8723de.ko Skipping BTF generation for /home/finger/rtl8723de_new/8723de.ko due to unavailability of vmlinux make[1]: Leaving directory '/usr/src/linux-5.14.21-150400.24.38-obj/x86_64/default' Clearly, it builds 8723de.ko. As you now realize, your assumptions about HP were not correct. Almost all the problems with the rtw88 and rtw89 drivers arise with Lenovo or HP. I do not recall any difficulties with Dell or Toshiba models. I have a Toshiba that I bought in 2014, and it still runs very well, particularly as I upgraded it with a 2 TB SSD and 12 GB RAM. I know nothing of midnight commander. Have you filed a bug on that issue? -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1206767 http://bugzilla.opensuse.org/show_bug.cgi?id=1206767#c25 --- Comment #25 from Dave Plater --- Tumbleweed doesn't like my laptop anymore. After unsuccessfully trying to build a 6.0.12 kernel, which is the last kernel that my laptop doesn't freeze with, to try to build rtl8723de_new against it. I've downgraded to Leap:15.4 keeping the old home directory and it's a pleasure to use my laptop again. The startup time, with the same services, is half what it used to be and: https://forum.manjaro.org/t/laptop-overheating-with-rtw-8723de/129718 which has the exact same symptoms as I had including the increase in running temperature. Keep the bug open maybe a fix will happen in the future. -- You are receiving this mail because: You are the assignee for the bug.