You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm running latest release (5.3) and after x minutes getting:
[ 6828.584671] mwifiex_pcie 0000:02:00.0: PREP_CMD: FW in reset state
[ 6828.584687] mwifiex_pcie 0000:02:00.0: failed to get signal information
[ 6828.584755] mwifiex_pcie 0000:02:00.0: PREP_CMD: FW in reset state
[ 6828.584763] mwifiex_pcie 0000:02:00.0: failed to get signal information
[ 6834.587608] mwifiex_pcie 0000:02:00.0: PREP_CMD: FW in reset state
[ 6834.587623] mwifiex_pcie 0000:02:00.0: failed to get signal information
[ 6834.587698] mwifiex_pcie 0000:02:00.0: PREP_CMD: FW in reset state
[ 6834.587706] mwifiex_pcie 0000:02:00.0: failed to get signal information
only reboot solve the wifi crash for me....
I'm running sp 2017 ubuntu 19.10
As far as I know. pretty much every device is affected by this in some way, except for the 7th generation models which have Intel WiFi chips. It seems to be some sort of (runtime) power-management/suspend issue.
I think it has been discussed on jakeday/linux-surface a couple of times by now. So maybe let's keep this issue to try and collect all that information.
Regarding wifi dropouts while using or idle (not after suspend):
SP2017 owner reported on Gitter linux-surface/community room that disabling L1 substates (IIRC) fixed the issue.
(Disable L1 substates for all ASPM capable devices: echo powersave | sudo tee /sys/module/pcie_aspm/parameters/policy)
(I don't know an easy way to disable the substates only for wifi device)
For my Surface 3 (non-pro), disabling L1 states (disabling only substates is not enough) for wifi device is needed (jakeday/linux-surface#456)
Is there any influence on power consumption doing that?
Unfortunately, yes. Bad impact on power consumption when idle or suspend (s2idle). (not sure when using) Especially, if you disable ASPM L1 state, it will break S0ix on suspend (you can check the residency: sudo cat /sys/kernel/debug/pmc_core/slp_s0_residency_usec).
You might need a patch from sebanc (jakeday/linux-surface#420 (comment)) to achieve S0ix states on suspend when you disable L1 state. At least it's the case on my Surface 3.
You might need a patch from sebanc (jakeday/linux-surface#420 (comment)) to achieve S0ix states on suspend when you disable L1 state. At least it's the case on my Surface 3.
Sorry but I may have said incorrect thing.
(It seems to be true only on my Chromium OS 4.19 kernel… (The kernel may have other power management patches). Sorry to make everyone confused.)
(On Arch Linux kernel (both 5.4 and 4.19) + Surface patches, I need to re-enable L1 state before suspend to achieve S0ix even with the patch from sebanc.)
If you are going to disable L1 state when you use your device, re-enabling the L1 state before suspend may be the best idea to achieve S0ix again. And disable L1 state again after suspend.
You might need a patch from sebanc (jakeday/linux-surface#420 (comment)) to achieve S0ix states on suspend when you disable L1 state. At least it's the case on my Surface 3.
Sorry but I may have said incorrect thing.
(It seems to be true only on my Chromium OS 4.19 kernel… (The kernel may have other power management patches). Sorry to make everyone confused.)
(On Arch Linux kernel (both 5.4 and 4.19) + Surface patches, I need to re-enable L1 state before suspend to achieve S0ix even with the patch from sebanc.)
If you are going to disable L1 state when you use your device, re-enabling the L1 state before suspend may be the best idea to achieve S0ix again. And disable L1 state again after suspend.
Activity
GrayHatter commentedon Dec 4, 2019
Retracted, it's the Surface Pro... I swear, I can read....
qzed commentedon Dec 4, 2019
As far as I know. pretty much every device is affected by this in some way, except for the 7th generation models which have Intel WiFi chips. It seems to be some sort of (runtime) power-management/suspend issue.
I think it has been discussed on jakeday/linux-surface a couple of times by now. So maybe let's keep this issue to try and collect all that information.
Links
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109681
Ubuntu Bugs: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1730924
Other issues:
(will update this with more links to relevant jakeday/linux-surface issues)
Possible Work-Arounds
[-]wifi dropouts on sp 2017[/-][+]WiFi Power-Management/Firmware issue (mwifiex)[/+]kitakar5525 commentedon Dec 5, 2019
(Copy from https://gitter.im/linux-surface/support?at=5de7a513f65fec1c8ebe1b00)
Unfortunately, yes. Bad impact on power consumption when idle or suspend (s2idle). (not sure when using) Especially, if you disable ASPM L1 state, it will break S0ix on suspend (you can check the residency:
sudo cat /sys/kernel/debug/pmc_core/slp_s0_residency_usec).You might need a patch from sebanc (jakeday/linux-surface#420 (comment)) to achieve S0ix states on suspend when you disable L1 state. At least it's the case on my Surface 3.kitakar5525 commentedon Dec 6, 2019
Sorry but I may have said incorrect thing.
(It seems to be true only on my Chromium OS 4.19 kernel… (The kernel may have other power management patches). Sorry to make everyone confused.)
(On Arch Linux kernel (both 5.4 and 4.19) + Surface patches, I need to re-enable L1 state before suspend to achieve S0ix even with the patch from sebanc.)
If you are going to disable L1 state when you use your device, re-enabling the L1 state before suspend may be the best idea to achieve S0ix again. And disable L1 state again after suspend.
qzed commentedon Dec 9, 2019
Thanks! I yet have to find the time to look into that
spokV commentedon Dec 11, 2019
How do i re-enable it again?
kitakar5525 commentedon Dec 11, 2019
On the script which you used to disable ASPM (
ASPM_SETTING=0means you disabled both L0s and L1), setASPM_SETTING=3instead to enable L0s and L1.You can check ASPM state:
spokV commentedon Dec 11, 2019
just need to call it from the sleep script?
148 remaining items
scsi: target: core: Fix deadlock due to recursive locking
scsi: target: core: Fix deadlock due to recursive locking
RDMA/irdma: Avoid free the non-cqp_request scratch
RDMA/irdma: Avoid free the non-cqp_request scratch
fbcon: always restore the old font data in fbcon_do_set_font()
fbcon: always restore the old font data in fbcon_do_set_font()
Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()
perf ui browser: Don't save pointer to stack memory
Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()
ocfs2: fix DIO failure due to insufficient transaction credits
tracing/net_sched: NULL pointer dereference in perf_trace_qdisc_reset()
riscv: Fix linear mapping checks for non-contiguous memory regions
clocksource/drivers/sh_cmt: Address race condition for clock events
block: Fix potential deadlock while freezing queue and acquiring sysf…
Bluetooth: MGMT: Fix UAF of hci_conn_params in add_device_complete