Surface Pro 6: Wireless interface disappears and locks up after suspend #369
Comments
|
Probably connected to https://github.com/jakeday/linux-surface/issues/348, also if you're using KDE and latte-dock, you might need to restart latte-dock with "latte-dock -r" in order for the wifi icon to show up, after the network manager get's started by the sleep script. |
|
@ZZZXXX0110 Hm, I did look at the issue before posting this one, but it seems different. In this one, the wifi interface literally disappears from Linux and it looks like its because a kernel thread locks up somehow. I'll try to do other things next time I reproduce it. I'll add that it doesn't happen 100% of the time, but maybe 10% of the time. |
|
@DolceTriade Can you try this again with the latest kernel and setup.sh script? |
|
Yes, I haven't tried this recently, but I've had a 100% repro rate when I hibernate to disk. |
|
From the comment on Ubuntu launchpad
We can avoid this type of lockup if we disable dump and reset: Disable mwifiex dump and reset to prevent mwifiex_pcie module freezing
which results in preventing the system from shutting down cleanly.
diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index 9cfcdf6..3ca9854 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -1004,11 +1004,11 @@ mwifiex_cmd_timeout_func(struct timer_list *t)
return;
}
- if (adapter->if_ops.device_dump)
- adapter->if_ops.device_dump(adapter);
+ //if (adapter->if_ops.device_dump)
+ //adapter->if_ops.device_dump(adapter);
- if (adapter->if_ops.card_reset)
- adapter->if_ops.card_reset(adapter);
+ //if (adapter->if_ops.card_reset)
+ //adapter->if_ops.card_reset(adapter);
}
voidEDIT |
|
And about crashing after suspend issue, I found a way to reset wifi card using acpi_call.
# Reset Wi-Fi for SB1
echo '\_SB.PCI0.RP12.PXSX.PRWF._RST' > /proc/acpi/call
echo 1 > "/sys/bus/pci/devices/0000:00:1d.3/remove"
sleep 1
echo 1 > /sys/bus/pci/rescan
sleep 1
DSDT of SB1 about |
|
Or simply disable d3cold for Wi-Fi and remove/reload # /usr/lib/systemd/system-sleep/sleep
case $1/$2 in
post/*)
modprobe -r mwifiex_pcie
modprobe -i mwifiex_pcie |
|
Of course, we can disable D3 state of Wi-Fi card by kernel side, but I don't like to do so because I observed higher power consumption during suspend. I prefer to reset the Wi-Fi card by diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 6bc27b7f..bffb78ad 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -1332,6 +1332,9 @@ DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AL, PCI_ANY_ID,
occur when mode detecting */
DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_VIA, PCI_ANY_ID,
PCI_CLASS_STORAGE_IDE, 8, quirk_no_ata_d3);
+/* Marvell Wi-Fi 88W8897 cannot wakeup from D3 state after s2idle
+ on Surface devices */
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MARVELL, 0x2b38, quirk_no_ata_d3);
/*
* This was originally an Alpha-specific thing, but it really fits here.(This example has another problem; applies quirk to all Marvell Wi-Fi 88W8897 card, even to devices which are not affected by this issue like Surface 3.) |
|
Excellent comments! This doesn't happen very often with me for the new kernel when I close the lid (this used to happen like 25% of the time on the old build) but suspend to ram and suspend to disk appear broken for me on the new kernel. Since I don't see any new regressions related to this, I assumed this was a "me" problem. I've been trying to fix it whenever I get a chance but haven't had much luck. Also, suspend isn't that critical of a feature for me because I don't mind hooking it up to power when I'm not using it. |
|
Ok, I upgraded again to 4.19.23 and that appeared to fix suspend and hibernate and I haven't been able to reproduce the wifi locking up. I'll close this now. Thanks! |
|
Sorry, maybe I said the wrong thing. I can reset Wi-Fi card just removing the PCI bridge which is connected by Wi-Fi card and then, rescan the PCI devices. No need to use # reset wifi for SB1
echo 1 > "/sys/bus/pci/devices/0000:00:1d.3/remove"
sleep 1
echo 1 > /sys/bus/pci/rescan
sleep 1(Current EDIT dmesg says: Then, I issued the set of commands I mentioned in #369 (comment) and Wi-Fi is working again. |
|
I have the same problem on SP6 with the latest release，also， kworker is blocked： [13293.335402] INFO: task kworker/3:1:5018 blocked for more than 120 seconds. It seems the wifi driver has some bug， which cause the kworker to stuck。 |
|
Alright @qzed I have already closed my other issue because the error I was facing was not Void linux specific. Don't know if you have read up on it, but if not, I was having troubles getting the device to wake up from suspend:
I remapped the power button in the acpi A couple of days ago I did some more research. I added to my pre suspend script and what do you know, now it will wake up again just fine. However, I'm facing the exact same problem described in this thread now. Wifi locks up completely and needs a reboot to work again. |
I want to start by saying that this is not like other issues that have been reported before where the WiFi is simply not connected after waking up from suspend. In this case, the wireless interface actually disappears from the list of interfaces that Linux shows. Furthermore, attempts to remove the mwifiex_pcie module hang forever. Lastly, I also cannot shutdown the system successfully because it seems there is a stuck kernel thread that doesn't die and therefore prevents the system from shutting down cleanly.
Below are kernel logs prior to suspend and after waking up from suspend:
Then, here are logs are running "sudo modprobe -r mwifiex_pcie":
The text was updated successfully, but these errors were encountered: