Closed DolceTriade closed 5 years ago
ZZZXXX0110
commented
5 years ago 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.
DolceTriade
commented
5 years ago @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.
jakeday
commented
5 years ago @DolceTriade Can you try this again with the latest kernel and setup.sh script?
DolceTriade
commented
5 years ago Yes, I haven't tried this recently, but I've had a 100% repro rate when I hibernate to disk.
kitakar5525
commented
5 years ago 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
I can confirm this patch works most of the time against prevents the system from shutting down cleanly when mwifiex_pcie crashed.
kitakar5525
commented
5 years ago And about crashing after suspend issue, I found a way to reset wifi card using acpi_call.
RP12 and 00:1d.3 can be different from device to device.
EDIT: I think the equivalent value to SP6 is RP04. For the other devices, search your DSDT for _RST
# 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 100:1d.3 is PCI bridge connected by Wi-Fi card.
$ lspci -nnvt
-[0000:00]-
[...]
+-1d.3-[03]----00.0 Marvell Technology Group Ltd. 88W8897 [AVASTAR] 802.11ac Wireless [11ab:2b38]
$ lspci -nn
00:1d.3 PCI bridge [0604]: Intel Corporation Device [8086:9d1b] (rev f1)DSDT of SB1 about RP12 is:
Scope (_SB.PCI0.RP12.PXSX)
{
PowerResource (PRWF, 0x05, 0x0000)
{
Name (_STA, One) // _STA: Status
Method (_ON, 0, NotSerialized) // _ON_: Power On
{
If ((_STA == Zero))
{
SGOV (0x02000012, One)
Sleep (0x96)
SGOV (0x02000015, One)
Sleep (0x64)
_STA = One
}
}
Method (_OFF, 0, NotSerialized) // _OFF: Power Off
{
If ((_STA == One))
{
SGOV (0x02000012, Zero)
Sleep (0x96)
SGOV (0x02000015, Zero)
Sleep (0x64)
_STA = Zero
}
}
Method (_RST, 0, NotSerialized) // _RST: Device Reset
{
SGOV (0x02000012, Zero)
Sleep (0xFA)
SGOV (0x02000012, One)
Sleep (0xFA)
_STA = One
}
}Or simply disable d3cold for Wi-Fi and remove/reload mwifiex_pcie module after suspend works for SB1.
However, I think it is not power-efficient to disable D3 state.
$ lspci -nn | grep -i marvell
03:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88W8897 [AVASTAR] 802.11ac Wireless [11ab:2b38]sudo su -c "echo 0 > '/sys/bus/pci/devices/0000:03:00.0/d3cold_allowed'" # for SB1
sudo su -c "echo 0 > '/sys/bus/pci/devices/0000:01:00.0/d3cold_allowed'" # for SP6
sudo su -c "echo 0 > /sys/bus/pci/devices/0000:$(lspci | grep -i Marvell | cut -d " " -f 1)/d3cold_allowed" # For the other devices# /usr/lib/systemd/system-sleep/sleep
case $1/$2 in
post/*)
modprobe -r mwifiex_pcie
modprobe -i mwifiex_pcieOf 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 acpi_call for now.
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.)
DolceTriade
commented
5 years ago 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.
DolceTriade
commented
5 years ago 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!
kitakar5525
commented
5 years ago 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 acpi_call.
# 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 /lib/systemd/system-sleep/sleep in this repo does not work for my Surface Book with Performance Base, too.)
EDIT
Sorry again. Without issuingecho '\_SB.PCI0.RP12.PXSX.PRWF._RST' > /proc/acpi/call, I get the message Authentication required by wireless Network from NetworkManager. Wi-Fi is not usable then.
dmesg says:
kern :info : [Tue Feb 19 21:45:46 2019] mwifiex_pcie 0000:03:00.0: cmd_wait_q terminated: -110Then, I issued the set of commands I mentioned in https://github.com/jakeday/linux-surface/issues/369#issuecomment-464722366 and Wi-Fi is working again.
minrui-hust
commented
5 years ago 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. [13293.335405] Tainted: G W 4.19.27-surface-linux-surface #2 [13293.335405] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
It seems the wifi driver has some bug， which cause the kworker to stuck。
minikN
commented
5 years ago 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:
Update regarding the suspend/resume issue.
I took this script and copied the
prepart to/etc/zzz.d/suspend/sleepand thepostpart to/etc/zzz.d/resume/resume.Going into suspend is working properly now, also waking up is working, however, after it woke up, it suspends immediately afterwards.
Seems like there is one piece missing.
I remapped the power button in the acpi handler.sh to send the device to sleep. In other words, the power button was the only button that did anything to the surface.
A couple of days ago I did some more research. I added
echo enabled > /sys/bus/usb/devices/1-7/power/wakeup
echo enabled > /sys/bus/usb/devices/usb1/power/wakeup
echo enabled > /sys/bus/usb/devices/usb2/power/wakeupto 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":