[SB1,SP4] Cannot achieve S0ix states on suspend #554
Comments
|
Suspend status script # Get CPU model (script from neofetch)
awk -F '\\s*: | @' \
'/model name|Hardware|Processor|^cpu model|chip type|^cpu type/ {
cpu=$2; if ($1 == "Hardware") exit } END { print cpu }' "/proc/cpuinfo"; \
\
cat /etc/os-release | grep NAME; \
echo -n "uname -r: "; uname -r; \
sudo grep -H . /sys/devices/virtual/dmi/id/product_name; \
sudo grep -H . /sys/devices/virtual/dmi/id/product_sku; \
sudo grep -H . /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us; \
sudo grep -H . /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us; \
sudo grep -H . /sys/kernel/debug/pmc_core/package_cstate_show; \
sudo grep -H . /sys/kernel/debug/pmc_core/slp_s0_residency_usec; \
sudo grep -H . /sys/kernel/debug/pmc_atom/sleep_state; \
sudo grep -H . /sys/kernel/debug/telemetry/s0ix_residency_usecEnable some debug output sudo su -c "echo 1 > /sys/power/pm_debug_messages"
sudo su -c "echo 1 > /sys/module/printk/parameters/ignore_loglevel"
sudo su -c "echo 1 > /sys/kernel/debug/clear_warn_once"
sudo su -c "echo 1 > /sys/module/acpi/parameters/aml_debug_output"
# dynamic_debug
sudo su -c 'echo "file drivers/pci/pci-acpi.c +p" > /sys/kernel/debug/dynamic_debug/control'
sudo su -c 'echo "file drivers/pci/pci-driver.c +p" > /sys/kernel/debug/dynamic_debug/control'
sudo su -c 'echo "file drivers/acpi/sleep.c +p" > /sys/kernel/debug/dynamic_debug/control'
sudo su -c 'echo "file drivers/platform/x86/intel_pmc_core.c +p" > /sys/kernel/debug/dynamic_debug/control'
sudo su -c 'echo "file drivers/base/power/wakeup.c +p" > /sys/kernel/debug/dynamic_debug/control'
sudo su -c 'echo "file drivers/acpi/device_pm.c +p" > /sys/kernel/debug/dynamic_debug/control' |
|
Currently, I don't reload any modules in system-sleep/sleep script. #!/bin/sh
PATH_CPULPI_US=/sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us
PATH_SLPS0_US=/sys/kernel/debug/pmc_core/slp_s0_residency_usec
case $1/$2 in
pre/*)
echo "pre-suspend state" > /dev/kmsg
echo "$(basename $PATH_CPULPI_US): $(cat $PATH_CPULPI_US) usec" > /dev/kmsg
echo "$(basename $PATH_SLPS0_US): $(cat $PATH_SLPS0_US) usec" > /dev/kmsg
;;
post/*)
echo "post-suspend state" > /dev/kmsg
echo "$(basename $PATH_CPULPI_US): $(cat $PATH_CPULPI_US) usec" > /dev/kmsg
echo "$(basename $PATH_SLPS0_US): $(cat $PATH_SLPS0_US) usec" > /dev/kmsg
systemctl restart usbguard.service
;;
esacAfter about 10 sec suspend: Intel(R) Core(TM) i7-6600U CPU
NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
uname -r: 5.2.9-arch1-1-surface
/sys/devices/virtual/dmi/id/product_name:Surface Book
/sys/devices/virtual/dmi/id/product_sku:Surface_Book
/sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us:21353923
grep: /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us: No such file or directory
/sys/kernel/debug/pmc_core/package_cstate_show:Package C2 : 0x6bcdd0a824
/sys/kernel/debug/pmc_core/package_cstate_show:Package C3 : 0x5fb997c7c
/sys/kernel/debug/pmc_core/package_cstate_show:Package C6 : 0x5c6af736f4
/sys/kernel/debug/pmc_core/package_cstate_show:Package C7 : 0x1eb3ef0
/sys/kernel/debug/pmc_core/package_cstate_show:Package C8 : 0xe3f2d9f80
/sys/kernel/debug/pmc_core/package_cstate_show:Package C9 : 0xe516188
/sys/kernel/debug/pmc_core/package_cstate_show:Package C10 : 0xdf600bc70
/sys/kernel/debug/pmc_core/slp_s0_residency_usec:0
grep: /sys/kernel/debug/pmc_atom/sleep_state: No such file or directoryBTW, I can achieve PC10 on even runtime by reloading mwifiex modules and reconfiguring ASPM on wifi device [1] twice, that's why References |
|
Status of $ cd /sys/kernel/debug/pmc_core/
$ grep -H . *
ltr_show:SOUTHPORT_A LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0
ltr_show:SOUTHPORT_B LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0
ltr_show:SATA LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0
ltr_show:GIGABIT_ETHERNET LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0
ltr_show:XHCI LTR: RAW: 0x8828 Non-Snoop(ns): 0 Snoop(ns): 40960
ltr_show:Reserved LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0
ltr_show:ME LTR: RAW: 0xc000c00 Non-Snoop(ns): 0 Snoop(ns): 0
ltr_show:EVA LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0
ltr_show:SOUTHPORT_C LTR: RAW: 0x88a088a0 Non-Snoop(ns): 163840 Snoop(ns): 163840
ltr_show:HD_AUDIO LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0
ltr_show:LPSS LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0
ltr_show:SOUTHPORT_D LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0
ltr_show:SOUTHPORT_E LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0
ltr_show:CAMERA LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0
ltr_show:ESPI LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0
ltr_show:SCC LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0
ltr_show:ISH LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0
ltr_show:CURRENT_PLATFORM LTR: RAW: 0x40201 Non-Snoop(ns): 0 Snoop(ns): 0
ltr_show:AGGREGATED_SYSTEM LTR: RAW: 0x1442a15 Non-Snoop(ns): 0 Snoop(ns): 0
mphy_core_lanes_power_gating_status:MPHY CORE LANE 0 State: Power gated
mphy_core_lanes_power_gating_status:MPHY CORE LANE 1 State: Power gated
mphy_core_lanes_power_gating_status:MPHY CORE LANE 2 State: Power gated
mphy_core_lanes_power_gating_status:MPHY CORE LANE 3 State: Power gated
mphy_core_lanes_power_gating_status:MPHY CORE LANE 4 State: Power gated
mphy_core_lanes_power_gating_status:MPHY CORE LANE 5 State: Power gated
mphy_core_lanes_power_gating_status:MPHY CORE LANE 6 State: Power gated
mphy_core_lanes_power_gating_status:MPHY CORE LANE 7 State: Power gated
mphy_core_lanes_power_gating_status:MPHY CORE LANE 8 State: Power gated
mphy_core_lanes_power_gating_status:MPHY CORE LANE 9 State: Power gated
mphy_core_lanes_power_gating_status:MPHY CORE LANE 10 State: Power gated
mphy_core_lanes_power_gating_status:MPHY CORE LANE 11 State: Power gated
mphy_core_lanes_power_gating_status:MPHY CORE LANE 12 State: Not power gated
mphy_core_lanes_power_gating_status:MPHY CORE LANE 13 State: Power gated
mphy_core_lanes_power_gating_status:MPHY CORE LANE 14 State: Power gated
mphy_core_lanes_power_gating_status:MPHY CORE LANE 15 State: Power gated
package_cstate_show:Package C2 : 0x1343d47e0c4
package_cstate_show:Package C3 : 0xb6c236520
package_cstate_show:Package C6 : 0x11909781b88
package_cstate_show:Package C7 : 0x43e3d68
package_cstate_show:Package C8 : 0x2367863c7c
package_cstate_show:Package C9 : 0x2671bd1310
package_cstate_show:Package C10 : 0xdf600bc70
pch_ip_power_gating_status:PCH IP: 0 - PMC State: On
pch_ip_power_gating_status:PCH IP: 1 - OPI-DMI State: On
pch_ip_power_gating_status:PCH IP: 2 - SPI / eSPI State: On
pch_ip_power_gating_status:PCH IP: 3 - XHCI State: On
pch_ip_power_gating_status:PCH IP: 4 - SPA State: Off
pch_ip_power_gating_status:PCH IP: 5 - SPB State: Off
pch_ip_power_gating_status:PCH IP: 6 - SPC State: On
pch_ip_power_gating_status:PCH IP: 7 - GBE State: Off
pch_ip_power_gating_status:PCH IP: 8 - SATA State: Off
pch_ip_power_gating_status:PCH IP: 9 - HDA-PGD0 State: Off
pch_ip_power_gating_status:PCH IP: 10 - HDA-PGD1 State: Off
pch_ip_power_gating_status:PCH IP: 11 - HDA-PGD2 State: Off
pch_ip_power_gating_status:PCH IP: 12 - HDA-PGD3 State: Off
pch_ip_power_gating_status:PCH IP: 13 - RSVD State: Off
pch_ip_power_gating_status:PCH IP: 14 - LPSS State: Off
pch_ip_power_gating_status:PCH IP: 15 - LPC State: Off
pch_ip_power_gating_status:PCH IP: 16 - SMB State: Off
pch_ip_power_gating_status:PCH IP: 17 - ISH State: Off
pch_ip_power_gating_status:PCH IP: 18 - P2SB State: Off
pch_ip_power_gating_status:PCH IP: 19 - DFX State: Off
pch_ip_power_gating_status:PCH IP: 20 - SCC State: Off
pch_ip_power_gating_status:PCH IP: 21 - RSVD State: Off
pch_ip_power_gating_status:PCH IP: 22 - FUSE State: On
pch_ip_power_gating_status:PCH IP: 23 - CAMERA State: Off
pch_ip_power_gating_status:PCH IP: 24 - RSVD State: Off
pch_ip_power_gating_status:PCH IP: 25 - USB3-OTG State: Off
pch_ip_power_gating_status:PCH IP: 26 - EXI State: Off
pch_ip_power_gating_status:PCH IP: 27 - CSE State: Off
pch_ip_power_gating_status:PCH IP: 28 - CSME_KVM State: Off
pch_ip_power_gating_status:PCH IP: 29 - CSME_PMT State: Off
pch_ip_power_gating_status:PCH IP: 30 - CSME_CLINK State: Off
pch_ip_power_gating_status:PCH IP: 31 - CSME_PTIO State: Off
pch_ip_power_gating_status:PCH IP: 32 - CSME_USBR State: Off
pch_ip_power_gating_status:PCH IP: 33 - CSME_SUSRAM State: Off
pch_ip_power_gating_status:PCH IP: 34 - CSME_SMT State: Off
pch_ip_power_gating_status:PCH IP: 35 - RSVD State: Off
pch_ip_power_gating_status:PCH IP: 36 - CSME_SMS2 State: Off
pch_ip_power_gating_status:PCH IP: 37 - CSME_SMS1 State: Off
pch_ip_power_gating_status:PCH IP: 38 - CSME_RTC State: Off
pch_ip_power_gating_status:PCH IP: 39 - CSME_PSF State: Off
pll_status:MIPI PLL State: Idle
pll_status:GEN2 USB2PCIE2 PLL State: Active
pll_status:DMIPCIE3 PLL State: Active
pll_status:SATA PLL State: Idle
slp_s0_residency_usec:0 |
|
sudo lspci -nnvvv
|
|
Decompiled DSDT for SB1 available at note-linux-on-surface-book-1/dsdt.dsl at master · kitakar5525/note-linux-on-surface-book-1 |
|
dmesg suspend log 2019-08-18-dmesg-suspend-log-excerpt
with color (html format, rename it to .html)
Suspicious output:
I understand I think it's weird. |
|
Progress on another devices
Intel Atom S0ix debugging patch (old)
|
|
|
@StollD sudo su -c "cd /sys/kernel/debug/pmc_core/; grep -H . *"(I will update my old comment) |
|
Yep, that worked. Updated my comment too. |
|
@StollD Thank you for your info! |
|
I can see no special difference... I've got stuck. |
|
@StollD Can you still achieve S0ix when you use distribution's (without jakeday patches) 5.2.y kernel? |
|
No, using the default fedora kernel I cannot get into S0ix. Also, mirroring from gitter: After updating my BIOS and reinstalling Linux, I had some issues to get into s0ix too. When I compared my logs with the ones I sent you I noticed that the cameras suddenly were reported as not power manageable (that error didn't come up for me with the old BIOS). I disabled the cameras in the BIOS and now my s0ix works again, so maybe that could fix your problems too? |
|
Thank you for your info! It's interesting for me that the default fedora kernel cannot achieve S0ix. The only thing that comes to mind is NVMe power management patch in 0002-suspend.patch. The NVMe patch is from 5.3-rc. So, if you are interested, try 5.3-rc (without jakeday patches) to see you can still achieve S0ix there.
I disabled all cameras, but unfortunately, I still cannot achieve the states. I'm now trying Intel's SoC Watch. I hope I can find something interesting with it. |
|
It doesn't work with 5.3-rc5 either, sadly. Using the stock kernels it doesn't even get into the higher packages (C7-10 just show 0). Building a kernel with just But I discovered something else: As it turns out, my camera fix that I posted earlier was a false positive. Since I reinstalled linux getting into S0ix was very unreliable. Sometimes it worked, but most of the time it didn't. When I disabled every device you can disable in the BIOS everything worked again (tested extensively by suspending and resuming all over again for like the last hour). Then I reenabled the devices one by one, and: It seemed to be Bluetooth. When I enabled that in the BIOS S0ix was broken again. And given that I disable Bluetooth, I can enable every other device (inc. cameras), and S0ix still worked. On my old install I disabled Bluetooth, because if it was enabled the WiFi speed at my university tanked, so that would explain why it worked flawless for me before. Note: Even just disabling Bluetooth in the OS and rebooting seems to be enough I hope this helps people trying to get Kaby Lake devices into S0ix. I don't think it will work on Sky Lake, since |
|
Thank you for your investigation! Regarding
I think that I just cannot read via MMIO interface. (I don't know well about MMIO, though.) Some links regarding
The |
|
I think I know why it isn't detected. Using your acpidump [1] I disassembled the LPIT from your SB1 and from my SB2, and noticed that for the SB1 the adress space where S0ix residency is stored is set to if (info->gaddr.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
info->iomem_addr = ioremap_nocache(info->gaddr.address,
info->gaddr.bit_width / 8);
if (!info->iomem_addr)
return;
/* Silently fail, if cpuidle attribute group is not present */
sysfs_add_file_to_group(&cpu_subsys.dev_root->kobj,
&dev_attr_low_power_idle_system_residency_us.attr,
"cpuidle");
} else if (info->gaddr.space_id == ACPI_ADR_SPACE_FIXED_HARDWARE) {
/* Silently fail, if cpuidle attribute group is not present */
sysfs_add_file_to_group(&cpu_subsys.dev_root->kobj,
&dev_attr_low_power_idle_cpu_residency_us.attr,
"cpuidle");
}For comparison, here are both LPIT tables: SB1: SB2: So, what I am wondering now: Is it possible that your system actually gets into S0ix but the kernel cannot show you that it worked? |
|
Actually, when you look further into the LPIT table, you can find the same SB1: SB2: These are the entries that store the value from The only conclusion I can draw from this tbh, is that both values (CPU and system residency) might be connected somehow, or that the HW description on the SB1 is bugged :P
|
I cannot say for sure, but at least Link to the commit about Link to the spec (the link in the commit is broken) |
I never did an exact measurement, but thats similar to what I have noticed with S0ix working. I will do an exact test overnight, with S0ix disabled / sabotaged, and then a more exact one with S0ix enabled.
If you look at the version of that driver in if (lpit_read_residency_count_address(&slp_s0_addr))
pmcdev->base_addr = PMC_BASE_ADDR_DEFAULT;
else
pmcdev->base_addr = slp_s0_addr - pmcdev->map->slp_s0_offset;The values outputted from that driver are then just read from that address + an offset ( And given that value is effectively guessed I would be careful with trusting anything that driver outputs to be honest. But I also don't know if the surfaces change that memory address, or if they even can, so take everything I say with a grain of salt. But given that the kernel engineers made calculating it the default, it seems to be changeable. I will try to modify my driver to output the calculated address. But since we don't know if it changed it is potentially useless. I am still looking through the spec, so if I find something I will post it of course. (for example a way to get the PCM base address from the DSDT)
|
Actually no, I am stupid. That address is read from ACPI and I posted the dump above. So Of course it doesn't mean it is the same for SB1 as well but it definitly increases my confusion. EDIT: But then, on the other hand, if both addresses are the same, both values in sysfs are backed by the same field. So if the address doesn't exist in LPIT for SB1, I doubt that the PMC driver would return anything sane, even with the correct base address. Figuring this out might really bow down to suspending the surface overnight and comparing the battery consumtion, as stupid as it might sound. |
|
@kitakar5525 Have you tried using $ sudo turbostat -q -S -s GFX%rc6,Pkg%pc2,Pkg%pc8,Pkg%pc9,CPU%LPI,SYS%LPIrun this and leave it running. It will output a new measurement every 5 seconds. While the command is still running, suspend, then resume. If the The commands that were used in the guide (combining turbostat and the command that puts the computer to sleep) didn't work for me, but doing what I wrote above works. |
|
Yes, I tried turbostat but it seems that it relies on $ sudo turbostat -q -S -s GFX%rc6,Pkg%pc2,Pkg%pc8,Pkg%pc9,CPU%LPI,SYS%LPI
GFX%rc6 Pkg%pc2 Pkg%pc8 Pkg%pc9 CPU%LPI
[...]
# after about 1 min suspend
100.37 0.93 0.16 0.01 91.81
[...]I also don't calculate the consumption regularly, but there are two samples for recent results. On my SB1:
I feel it tend to get lower consumption per hour if it sleeps longer. You can use upower to show current (tablet+base combined) battery percentage |
Ah, damm, I missed that when checking the source code.
After suspending for 12 hours in S0ix my SB2 lost exactly 12% of battery, so 1%/h. Still working on getting numbers without S0ix. But it doesn't seem too far off from your results. |
OK. Thank you for testing. |
|
Suspended again for 10 hours, without S0ix, and it lost 20% of battery life in that time. So 2%/h without S0ix. The CPU still entered PC10 though. Given this result it doesn't sound like my idea that the SB1 enters S0ix without exposing it properly is of much value, sorry. |
I see… Another result on Linux 5.2.9
I will collect data on Windows using the SoC Watch and sleepstudy ( 1.6 %/h battery drain sounds not so bad, but I'm just curious about achieving S0ix : ) |
For those who want to use SoC WatchYou can download SoC Watch as a package from Choose For Linux, standalone version is also available. If you prefer this version, choose Optionally, you can use Usage guide On WindowsIf you want to use EDIT: 2019-11-05 You may need to disable Secure Boot to use On LinuxYou need to patch the driver source (just one line) to use on Linux 5.2. 0001-socwatch_driver-update-to-build-on-5.2.patch
From e32a64ed67094fcf19277b2eda1888e9c80246a3 Mon Sep 17 00:00:00 2001
From: kitakar5525 <[email protected]>
Date: Sat, 24 Aug 2019 01:53:02 +0900
Subject: [PATCH] socwatch_driver: update to build on 5.2
---
src/sw_trace_notifier_provider.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/sw_trace_notifier_provider.c b/src/sw_trace_notifier_provider.c
index 8c78790..0962e27 100644
--- a/src/sw_trace_notifier_provider.c
+++ b/src/sw_trace_notifier_provider.c
@@ -1428,7 +1428,7 @@ static int sw_probe_cpufreq_notifier_i(struct notifier_block *block, unsigned lo
{
struct cpufreq_freqs *freqs = data;
static struct sw_trace_notifier_data *node = NULL;
- int cpu = freqs->cpu;
+ int cpu = freqs->policy->cpu;
if (state == CPUFREQ_PRECHANGE) {
pw_pr_debug("CPU %d reports a CPUFREQ_PRECHANGE for target CPU %d at TSC = %llu\n", RAW_CPU(), cpu, sw_timestamp());
--
2.23.0
</p>
</details>
|
kitakar5525
added a commit
to kitakar5525/linux-kernel
that referenced
this issue
Apr 23, 2020
On Windows, it seems that wifi parent bridge will not enter D3 state
(stay on D0 state) [1]. And on Linux, disabling the D3 state for the
bridge fixes driver crashing after suspend.
This commit disables the parent bridge D3 state on driver initialization
to fix driver crashing after suspend.
NOTE_1: The driver does not crash on LTS 4.4 series but does crash on
LTS 4.9 series. Maybe commit 9d26d3a ("PCI: Put PCIe ports
into D3 during suspend") changed the bridge D-state behavior.
NOTE_2: As a side effect, it reports parent bridge is in D3hot. I'm not
sure why.
acpi device:4b: Cannot transition to power state D0 for parent in D3hot
Power state of the parent bridge on SB1 before this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D0
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
Power state of the parent bridge on SB1 after this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D3hot
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
NOTE_3: This change is needed for SP4 and later generations that use
mwifiex (i.e. SP4/SP5/SP6, SB1/SB2 and SL1/SL2). Not needed for
Surface 3 but safe to apply as this change doesn't break S0ix.
Not sure if needed for SP1/SP2 and SP3. Anyway, I think applying
this change to all the devices may be safe regarding S0ix because
Surface 3 can achieve S0ix anyway even when this patch applied.
So, let's apply this change for all the devices for now.
[1] jakeday/linux-surface#554 (comment)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
kitakar5525
added a commit
to kitakar5525/linux-kernel
that referenced
this issue
Apr 23, 2020
On Windows, it seems that wifi parent bridge will not enter D3 state
(stay on D0 state) [1]. And on Linux, disabling the D3 state for the
bridge fixes driver crashing after suspend.
This commit disables the parent bridge D3 state on driver initialization
to fix driver crashing after suspend.
NOTE_1: The driver does not crash on LTS 4.4 series but does crash on
LTS 4.9 series. Maybe commit 9d26d3a ("PCI: Put PCIe ports
into D3 during suspend") changed the bridge D-state behavior.
NOTE_2: As a side effect, it reports parent bridge is in D3hot. I'm not
sure why.
acpi device:4b: Cannot transition to power state D0 for parent in D3hot
Power state of the parent bridge on SB1 before this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D0
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
Power state of the parent bridge on SB1 after this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D3hot
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
NOTE_3: This change is needed for SP4 and later generations that use
mwifiex (i.e. SP4/SP5/SP6, SB1/SB2 and SL1/SL2). Not needed for
Surface 3 but safe to apply as this change doesn't break S0ix.
Not sure if needed for SP1/SP2 and SP3. Anyway, I think applying
this change to all the devices may be safe regarding S0ix because
Surface 3 can achieve S0ix anyway even when this patch applied.
So, let's apply this change for all the devices for now.
[1] jakeday/linux-surface#554 (comment)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
kitakar5525
added a commit
to kitakar5525/linux-kernel
that referenced
this issue
Apr 23, 2020
On Windows, it seems that wifi parent bridge will not enter D3 state
(stay on D0 state) [1]. And on Linux, disabling the D3 state for the
bridge fixes driver crashing after suspend.
This commit disables the parent bridge D3 state on driver initialization
to fix driver crashing after suspend.
NOTE_1: The driver does not crash on LTS 4.4 series but does crash on
LTS 4.9 series. Maybe commit 9d26d3a ("PCI: Put PCIe ports
into D3 during suspend") changed the bridge D-state behavior.
NOTE_2: As a side effect, it reports parent bridge is in D3hot. I'm not
sure why.
acpi device:4b: Cannot transition to power state D0 for parent in D3hot
Power state of the parent bridge on SB1 before this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D0
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
Power state of the parent bridge on SB1 after this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D3hot
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
NOTE_3: This change is needed for SP4 and later generations that use
mwifiex (i.e. SP4/SP5/SP6, SB1/SB2 and SL1/SL2). Not needed for
Surface 3 but safe to apply as this change doesn't break S0ix.
Not sure if needed for SP1/SP2 and SP3. Anyway, I think applying
this change to all the devices may be safe regarding S0ix because
Surface 3 can achieve S0ix anyway even when this patch applied.
So, let's apply this change for all the devices for now.
[1] jakeday/linux-surface#554 (comment)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
kitakar5525
added a commit
to linux-surface/kernel
that referenced
this issue
Apr 24, 2020
On Windows, it seems that wifi parent bridge will not enter D3 state
(stay on D0 state) [1]. And on Linux, disabling the D3 state for the
bridge fixes driver crashing after suspend.
This commit disables the parent bridge D3 state on driver initialization
to fix driver crashing after suspend.
NOTE_1: The driver does not crash on LTS 4.4 series but does crash on
LTS 4.9 series. Maybe commit 9d26d3a ("PCI: Put PCIe ports
into D3 during suspend") changed the bridge D-state behavior.
NOTE_2: As a side effect, it reports parent bridge is in D3hot. I'm not
sure why.
acpi device:4b: Cannot transition to power state D0 for parent in D3hot
Power state of the parent bridge on SB1 before this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D0
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
Power state of the parent bridge on SB1 after this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D3hot
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
NOTE_3: This change is needed for SP4 and later generations that use
mwifiex (i.e. SP4/SP5/SP6, SB1/SB2 and SL1/SL2). Not needed for
Surface 3 but safe to apply as this change doesn't break S0ix.
Not sure if needed for SP1/SP2 and SP3. Anyway, I think applying
this change to all the devices may be safe regarding S0ix because
Surface 3 can achieve S0ix anyway even when this patch applied.
So, let's apply this change for all the devices for now.
[1] jakeday/linux-surface#554 (comment)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
(cherry picked from commit 028e378
from PR #44)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
kitakar5525
added a commit
to linux-surface/kernel
that referenced
this issue
Apr 24, 2020
On Windows, it seems that wifi parent bridge will not enter D3 state
(stay on D0 state) [1]. And on Linux, disabling the D3 state for the
bridge fixes driver crashing after suspend.
This commit disables the parent bridge D3 state on driver initialization
to fix driver crashing after suspend.
NOTE_1: The driver does not crash on LTS 4.4 series but does crash on
LTS 4.9 series. Maybe commit 9d26d3a ("PCI: Put PCIe ports
into D3 during suspend") changed the bridge D-state behavior.
NOTE_2: As a side effect, it reports parent bridge is in D3hot. I'm not
sure why.
acpi device:4b: Cannot transition to power state D0 for parent in D3hot
Power state of the parent bridge on SB1 before this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D0
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
Power state of the parent bridge on SB1 after this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D3hot
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
NOTE_3: This change is needed for SP4 and later generations that use
mwifiex (i.e. SP4/SP5/SP6, SB1/SB2 and SL1/SL2). Not needed for
Surface 3 but safe to apply as this change doesn't break S0ix.
Not sure if needed for SP1/SP2 and SP3. Anyway, I think applying
this change to all the devices may be safe regarding S0ix because
Surface 3 can achieve S0ix anyway even when this patch applied.
So, let's apply this change for all the devices for now.
[1] jakeday/linux-surface#554 (comment)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
(cherry picked from commit 028e378
from PR #44)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
StollD
pushed a commit
to linux-surface/kernel
that referenced
this issue
Jun 1, 2020
On Windows, it seems that wifi parent bridge will not enter D3 state
(stay on D0 state) [1]. And on Linux, disabling the D3 state for the
bridge fixes driver crashing after suspend.
This commit disables the parent bridge D3 state on driver initialization
to fix driver crashing after suspend.
NOTE_1: The driver does not crash on LTS 4.4 series but does crash on
LTS 4.9 series. Maybe commit 9d26d3a ("PCI: Put PCIe ports
into D3 during suspend") changed the bridge D-state behavior.
NOTE_2: As a side effect, it reports parent bridge is in D3hot. I'm not
sure why.
acpi device:4b: Cannot transition to power state D0 for parent in D3hot
Power state of the parent bridge on SB1 before this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D0
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
Power state of the parent bridge on SB1 after this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D3hot
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
NOTE_3: This change is needed for SP4 and later generations that use
mwifiex (i.e. SP4/SP5/SP6, SB1/SB2 and SL1/SL2). Not needed for
Surface 3 but safe to apply as this change doesn't break S0ix.
Not sure if needed for SP1/SP2 and SP3. Anyway, I think applying
this change to all the devices may be safe regarding S0ix because
Surface 3 can achieve S0ix anyway even when this patch applied.
So, let's apply this change for all the devices for now.
[1] jakeday/linux-surface#554 (comment)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
qzed
pushed a commit
to linux-surface/kernel
that referenced
this issue
Aug 3, 2020
On Windows, it seems that wifi parent bridge will not enter D3 state
(stay on D0 state) [1]. And on Linux, disabling the D3 state for the
bridge fixes driver crashing after suspend.
This commit disables the parent bridge D3 state on driver initialization
to fix driver crashing after suspend.
NOTE_1: The driver does not crash on LTS 4.4 series but does crash on
LTS 4.9 series. Maybe commit 9d26d3a ("PCI: Put PCIe ports
into D3 during suspend") changed the bridge D-state behavior.
NOTE_2: As a side effect, it reports parent bridge is in D3hot. I'm not
sure why.
acpi device:4b: Cannot transition to power state D0 for parent in D3hot
Power state of the parent bridge on SB1 before this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D0
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
Power state of the parent bridge on SB1 after this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D3hot
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
NOTE_3: This change is needed for SP4 and later generations that use
mwifiex (i.e. SP4/SP5/SP6, SB1/SB2 and SL1/SL2). Not needed for
Surface 3 but safe to apply as this change doesn't break S0ix.
Not sure if needed for SP1/SP2 and SP3. Anyway, I think applying
this change to all the devices may be safe regarding S0ix because
Surface 3 can achieve S0ix anyway even when this patch applied.
So, let's apply this change for all the devices for now.
[1] jakeday/linux-surface#554 (comment)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
|
Apologies if this is the wrong place, but this thread was helpful to me in figuring out why my Surface Go wasn't hitting s0ix, so I'm leaving my notes here. This is with a Surface Go 1 with 8GB RAM and 128GB storage. I'm currently running the Ubuntu 20.04 OEM kernel series (5.6.0-1021-oem). I saw in this issue that some people had success with turning off Bluetooth or WiFi in the BIOS. I went through turning each device off one at a time in UEFI settings. The SD card reader doesn't work anyway - I get a lot of these messages with a card inserted. Either way, since the SD card reader doesn't work, and I don't need it currently, this is a good workaround. Would this be good information to add to the Surface Go page on the wiki? https://github.com/linux-surface/linux-surface/wiki/Surface-Go |
Hmm. If I recall correctly, I've never heard that SD card reader doesn't work.
Waiting for the result. |
qzed
pushed a commit
to linux-surface/kernel
that referenced
this issue
Aug 28, 2020
On Windows, it seems that wifi parent bridge will not enter D3 state
(stay on D0 state) [1]. And on Linux, disabling the D3 state for the
bridge fixes driver crashing after suspend.
This commit disables the parent bridge D3 state on driver initialization
to fix driver crashing after suspend.
NOTE_1: The driver does not crash on LTS 4.4 series but does crash on
LTS 4.9 series. Maybe commit 9d26d3a ("PCI: Put PCIe ports
into D3 during suspend") changed the bridge D-state behavior.
NOTE_2: As a side effect, it reports parent bridge is in D3hot. I'm not
sure why.
acpi device:4b: Cannot transition to power state D0 for parent in D3hot
Power state of the parent bridge on SB1 before this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D0
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
Power state of the parent bridge on SB1 after this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D3hot
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
NOTE_3: This change is needed for SP4 and later generations that use
mwifiex (i.e. SP4/SP5/SP6, SB1/SB2 and SL1/SL2). Not needed for
Surface 3 but safe to apply as this change doesn't break S0ix.
Not sure if needed for SP1/SP2 and SP3. Anyway, I think applying
this change to all the devices may be safe regarding S0ix because
Surface 3 can achieve S0ix anyway even when this patch applied.
So, let's apply this change for all the devices for now.
[1] jakeday/linux-surface#554 (comment)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
qzed
pushed a commit
to linux-surface/kernel
that referenced
this issue
Aug 28, 2020
On Windows, it seems that wifi parent bridge will not enter D3 state
(stay on D0 state) [1]. And on Linux, disabling the D3 state for the
bridge fixes driver crashing after suspend.
This commit disables the parent bridge D3 state on driver initialization
to fix driver crashing after suspend.
NOTE_1: The driver does not crash on LTS 4.4 series but does crash on
LTS 4.9 series. Maybe commit 9d26d3a ("PCI: Put PCIe ports
into D3 during suspend") changed the bridge D-state behavior.
NOTE_2: As a side effect, it reports parent bridge is in D3hot. I'm not
sure why.
acpi device:4b: Cannot transition to power state D0 for parent in D3hot
Power state of the parent bridge on SB1 before this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D0
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
Power state of the parent bridge on SB1 after this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D3hot
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
NOTE_3: This change is needed for SP4 and later generations that use
mwifiex (i.e. SP4/SP5/SP6, SB1/SB2 and SL1/SL2). Not needed for
Surface 3 but safe to apply as this change doesn't break S0ix.
Not sure if needed for SP1/SP2 and SP3. Anyway, I think applying
this change to all the devices may be safe regarding S0ix because
Surface 3 can achieve S0ix anyway even when this patch applied.
So, let's apply this change for all the devices for now.
[1] jakeday/linux-surface#554 (comment)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
qzed
pushed a commit
to linux-surface/kernel
that referenced
this issue
Aug 28, 2020
On Windows, it seems that wifi parent bridge will not enter D3 state
(stay on D0 state) [1]. And on Linux, disabling the D3 state for the
bridge fixes driver crashing after suspend.
This commit disables the parent bridge D3 state on driver initialization
to fix driver crashing after suspend.
NOTE_1: The driver does not crash on LTS 4.4 series but does crash on
LTS 4.9 series. Maybe commit 9d26d3a ("PCI: Put PCIe ports
into D3 during suspend") changed the bridge D-state behavior.
NOTE_2: As a side effect, it reports parent bridge is in D3hot. I'm not
sure why.
acpi device:4b: Cannot transition to power state D0 for parent in D3hot
Power state of the parent bridge on SB1 before this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D0
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
Power state of the parent bridge on SB1 after this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D3hot
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
NOTE_3: This change is needed for SP4 and later generations that use
mwifiex (i.e. SP4/SP5/SP6, SB1/SB2 and SL1/SL2). Not needed for
Surface 3 but safe to apply as this change doesn't break S0ix.
Not sure if needed for SP1/SP2 and SP3. Anyway, I think applying
this change to all the devices may be safe regarding S0ix because
Surface 3 can achieve S0ix anyway even when this patch applied.
So, let's apply this change for all the devices for now.
[1] jakeday/linux-surface#554 (comment)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
(cherry picked from commit 028e378
from PR #44)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
qzed
pushed a commit
to linux-surface/kernel
that referenced
this issue
Aug 28, 2020
On Windows, it seems that wifi parent bridge will not enter D3 state
(stay on D0 state) [1]. And on Linux, disabling the D3 state for the
bridge fixes driver crashing after suspend.
This commit disables the parent bridge D3 state on driver initialization
to fix driver crashing after suspend.
NOTE_1: The driver does not crash on LTS 4.4 series but does crash on
LTS 4.9 series. Maybe commit 9d26d3a ("PCI: Put PCIe ports
into D3 during suspend") changed the bridge D-state behavior.
NOTE_2: As a side effect, it reports parent bridge is in D3hot. I'm not
sure why.
acpi device:4b: Cannot transition to power state D0 for parent in D3hot
Power state of the parent bridge on SB1 before this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D0
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
Power state of the parent bridge on SB1 after this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D3hot
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
NOTE_3: This change is needed for SP4 and later generations that use
mwifiex (i.e. SP4/SP5/SP6, SB1/SB2 and SL1/SL2). Not needed for
Surface 3 but safe to apply as this change doesn't break S0ix.
Not sure if needed for SP1/SP2 and SP3. Anyway, I think applying
this change to all the devices may be safe regarding S0ix because
Surface 3 can achieve S0ix anyway even when this patch applied.
So, let's apply this change for all the devices for now.
[1] jakeday/linux-surface#554 (comment)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
(cherry picked from commit 028e378
from PR #44)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
Yep, it was a dead SD card; a known good card mounts fine. The SD card reader still prevents the system from reaching s0ix, with or without a card present. I think I'm actually going to switch to using hibernate. (Edit: It was actually But, if someone didn't want to use hibernate, switching off the SD card reader in the BIOS will allow a Surface Go 1 to reach s0ix. |
That's probably not going to work on the Go. The change only concerns System Aggregator Module (SAM) devices, which the Go does (as far as I know) not have. I don't have a clue how the keyboard of the Go is connected, but it's not via SAM. So it's basically a different issue. |
If the SD card reader still breaks S0ix on s2idle, this info helps people having S0ix issue on SGO. So, feel free to add this info to the wiki. If someone knows more, they would improve the wiki anyway :) |
|
Thanks, I added a brief note in the wiki. |
kitakar5525
added a commit
to kitakar5525/linux-kernel
that referenced
this issue
Sep 16, 2020
On Windows, it seems that wifi parent bridge will not enter D3 state
(stay on D0 state) [1]. And on Linux, disabling the D3 state for the
bridge fixes driver crashing after suspend.
This commit disables the parent bridge D3 state on driver initialization
to fix driver crashing after suspend.
NOTE_1: The driver does not crash on LTS 4.4 series but does crash on
LTS 4.9 series. Maybe commit 9d26d3a ("PCI: Put PCIe ports
into D3 during suspend") changed the bridge D-state behavior.
NOTE_2: As a side effect, it reports parent bridge is in D3hot. I'm not
sure why.
acpi device:4b: Cannot transition to power state D0 for parent in D3hot
Power state of the parent bridge on SB1 before this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D0
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
Power state of the parent bridge on SB1 after this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D3hot
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
NOTE_3: This change is needed for SP4 and later generations that use
mwifiex (i.e. SP4/SP5/SP6, SB1/SB2 and SL1/SL2). Not needed for
Surface 3 but safe to apply as this change doesn't break S0ix.
Not sure if needed for SP1/SP2 and SP3. Anyway, I think applying
this change to all the devices may be safe regarding S0ix because
Surface 3 can achieve S0ix anyway even when this patch applied.
So, let's apply this change for all the devices for now.
[1] jakeday/linux-surface#554 (comment)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
(cherry picked from commit 028e378
from PR linux-surface#44)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
kitakar5525
added a commit
to kitakar5525/linux-kernel
that referenced
this issue
Sep 22, 2020
On Windows, it seems that wifi parent bridge will not enter D3 state
(stay on D0 state) [1]. And on Linux, disabling the D3 state for the
bridge fixes driver crashing after suspend.
This commit disables the parent bridge D3 state on driver initialization
to fix driver crashing after suspend.
NOTE_1: The driver does not crash on LTS 4.4 series but does crash on
LTS 4.9 series. Maybe commit 9d26d3a ("PCI: Put PCIe ports
into D3 during suspend") changed the bridge D-state behavior.
NOTE_2: As a side effect, it reports parent bridge is in D3hot. I'm not
sure why.
acpi device:4b: Cannot transition to power state D0 for parent in D3hot
Power state of the parent bridge on SB1 before this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D0
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
Power state of the parent bridge on SB1 after this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D3hot
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
NOTE_3: This change is needed for SP4 and later generations that use
mwifiex (i.e. SP4/SP5/SP6, SB1/SB2 and SL1/SL2). Not needed for
Surface 3 but safe to apply as this change doesn't break S0ix.
Not sure if needed for SP1/SP2 and SP3. Anyway, I think applying
this change to all the devices may be safe regarding S0ix because
Surface 3 can achieve S0ix anyway even when this patch applied.
So, let's apply this change for all the devices for now.
[1] jakeday/linux-surface#554 (comment)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
(cherry picked from commit c650ba4)
Signed-off-by: Tsuchiya Yuto <[email protected]>
kitakar5525
added a commit
to kitakar5525/linux-kernel
that referenced
this issue
Oct 1, 2020
On Windows, it seems that wifi parent bridge will not enter D3 state
(stay on D0 state) [1]. And on Linux, disabling the D3 state for the
bridge fixes driver crashing after suspend.
This commit disables the parent bridge D3 state on driver initialization
to fix driver crashing after suspend.
NOTE_1: The driver does not crash on LTS 4.4 series but does crash on
LTS 4.9 series. Maybe commit 9d26d3a ("PCI: Put PCIe ports
into D3 during suspend") changed the bridge D-state behavior.
NOTE_2: As a side effect, it reports parent bridge is in D3hot. I'm not
sure why.
acpi device:4b: Cannot transition to power state D0 for parent in D3hot
Power state of the parent bridge on SB1 before this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D0
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
Power state of the parent bridge on SB1 after this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D3hot
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
NOTE_3: This change is needed for SP4 and later generations that use
mwifiex (i.e. SP4/SP5/SP6, SB1/SB2 and SL1/SL2). Not needed for
Surface 3 but safe to apply as this change doesn't break S0ix.
Not sure if needed for SP1/SP2 and SP3. Anyway, I think applying
this change to all the devices may be safe regarding S0ix because
Surface 3 can achieve S0ix anyway even when this patch applied.
So, let's apply this change for all the devices for now.
[1] jakeday/linux-surface#554 (comment)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
(cherry picked from commit c650ba4)
Signed-off-by: Tsuchiya Yuto <[email protected]>
kitakar5525
added a commit
to kitakar5525/linux-kernel
that referenced
this issue
Oct 6, 2020
On Windows, it seems that wifi parent bridge will not enter D3 state
(stay on D0 state) [1]. And on Linux, disabling the D3 state for the
bridge fixes driver crashing after suspend.
This commit disables the parent bridge D3 state on driver initialization
to fix driver crashing after suspend.
NOTE_1: The driver does not crash on LTS 4.4 series but does crash on
LTS 4.9 series. Maybe commit 9d26d3a ("PCI: Put PCIe ports
into D3 during suspend") changed the bridge D-state behavior.
NOTE_2: As a side effect, it reports parent bridge is in D3hot. I'm not
sure why.
acpi device:4b: Cannot transition to power state D0 for parent in D3hot
Power state of the parent bridge on SB1 before this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D0
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
Power state of the parent bridge on SB1 after this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D3hot
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
NOTE_3: This change is needed for SP4 and later generations that use
mwifiex (i.e. SP4/SP5/SP6, SB1/SB2 and SL1/SL2). Not needed for
Surface 3 but safe to apply as this change doesn't break S0ix.
Not sure if needed for SP1/SP2 and SP3. Anyway, I think applying
this change to all the devices may be safe regarding S0ix because
Surface 3 can achieve S0ix anyway even when this patch applied.
So, let's apply this change for all the devices for now.
[1] jakeday/linux-surface#554 (comment)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
(cherry picked from commit c650ba4)
Signed-off-by: Tsuchiya Yuto <[email protected]>
kitakar5525
added a commit
to kitakar5525/linux-kernel
that referenced
this issue
Oct 12, 2020
On Windows, it seems that wifi parent bridge will not enter D3 state
(stay on D0 state) [1]. And on Linux, disabling the D3 state for the
bridge fixes driver crashing after suspend.
This commit disables the parent bridge D3 state on driver initialization
to fix driver crashing after suspend.
NOTE_1: The driver does not crash on LTS 4.4 series but does crash on
LTS 4.9 series. Maybe commit 9d26d3a ("PCI: Put PCIe ports
into D3 during suspend") changed the bridge D-state behavior.
NOTE_2: As a side effect, it reports parent bridge is in D3hot. I'm not
sure why.
acpi device:4b: Cannot transition to power state D0 for parent in D3hot
Power state of the parent bridge on SB1 before this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D0
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
Power state of the parent bridge on SB1 after this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D3hot
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
NOTE_3: This change is needed for SP4 and later generations that use
mwifiex (i.e. SP4/SP5/SP6, SB1/SB2 and SL1/SL2). Not needed for
Surface 3 but safe to apply as this change doesn't break S0ix.
Not sure if needed for SP1/SP2 and SP3. Anyway, I think applying
this change to all the devices may be safe regarding S0ix because
Surface 3 can achieve S0ix anyway even when this patch applied.
So, let's apply this change for all the devices for now.
[1] jakeday/linux-surface#554 (comment)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
qzed
pushed a commit
to linux-surface/kernel
that referenced
this issue
Oct 16, 2020
On Windows, it seems that wifi parent bridge will not enter D3 state
(stay on D0 state) [1]. And on Linux, disabling the D3 state for the
bridge fixes driver crashing after suspend.
This commit disables the parent bridge D3 state on driver initialization
to fix driver crashing after suspend.
NOTE_1: The driver does not crash on LTS 4.4 series but does crash on
LTS 4.9 series. Maybe commit 9d26d3a ("PCI: Put PCIe ports
into D3 during suspend") changed the bridge D-state behavior.
NOTE_2: As a side effect, it reports parent bridge is in D3hot. I'm not
sure why.
acpi device:4b: Cannot transition to power state D0 for parent in D3hot
Power state of the parent bridge on SB1 before this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D0
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
Power state of the parent bridge on SB1 after this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D3hot
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
NOTE_3: This change is needed for SP4 and later generations that use
mwifiex (i.e. SP4/SP5/SP6, SB1/SB2 and SL1/SL2). Not needed for
Surface 3 but safe to apply as this change doesn't break S0ix.
Not sure if needed for SP1/SP2 and SP3. Anyway, I think applying
this change to all the devices may be safe regarding S0ix because
Surface 3 can achieve S0ix anyway even when this patch applied.
So, let's apply this change for all the devices for now.
[1] jakeday/linux-surface#554 (comment)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
qzed
pushed a commit
to linux-surface/kernel
that referenced
this issue
Oct 16, 2020
On Windows, it seems that wifi parent bridge will not enter D3 state
(stay on D0 state) [1]. And on Linux, disabling the D3 state for the
bridge fixes driver crashing after suspend.
This commit disables the parent bridge D3 state on driver initialization
to fix driver crashing after suspend.
NOTE_1: The driver does not crash on LTS 4.4 series but does crash on
LTS 4.9 series. Maybe commit 9d26d3a ("PCI: Put PCIe ports
into D3 during suspend") changed the bridge D-state behavior.
NOTE_2: As a side effect, it reports parent bridge is in D3hot. I'm not
sure why.
acpi device:4b: Cannot transition to power state D0 for parent in D3hot
Power state of the parent bridge on SB1 before this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D0
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
Power state of the parent bridge on SB1 after this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D3hot
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
NOTE_3: This change is needed for SP4 and later generations that use
mwifiex (i.e. SP4/SP5/SP6, SB1/SB2 and SL1/SL2). Not needed for
Surface 3 but safe to apply as this change doesn't break S0ix.
Not sure if needed for SP1/SP2 and SP3. Anyway, I think applying
this change to all the devices may be safe regarding S0ix because
Surface 3 can achieve S0ix anyway even when this patch applied.
So, let's apply this change for all the devices for now.
[1] jakeday/linux-surface#554 (comment)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
(cherry picked from commit 028e378
from PR #44)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
qzed
pushed a commit
to linux-surface/kernel
that referenced
this issue
Oct 16, 2020
On Windows, it seems that wifi parent bridge will not enter D3 state
(stay on D0 state) [1]. And on Linux, disabling the D3 state for the
bridge fixes driver crashing after suspend.
This commit disables the parent bridge D3 state on driver initialization
to fix driver crashing after suspend.
NOTE_1: The driver does not crash on LTS 4.4 series but does crash on
LTS 4.9 series. Maybe commit 9d26d3a ("PCI: Put PCIe ports
into D3 during suspend") changed the bridge D-state behavior.
NOTE_2: As a side effect, it reports parent bridge is in D3hot. I'm not
sure why.
acpi device:4b: Cannot transition to power state D0 for parent in D3hot
Power state of the parent bridge on SB1 before this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D0
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
Power state of the parent bridge on SB1 after this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D3hot
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
NOTE_3: This change is needed for SP4 and later generations that use
mwifiex (i.e. SP4/SP5/SP6, SB1/SB2 and SL1/SL2). Not needed for
Surface 3 but safe to apply as this change doesn't break S0ix.
Not sure if needed for SP1/SP2 and SP3. Anyway, I think applying
this change to all the devices may be safe regarding S0ix because
Surface 3 can achieve S0ix anyway even when this patch applied.
So, let's apply this change for all the devices for now.
[1] jakeday/linux-surface#554 (comment)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
(cherry picked from commit 028e378
from PR #44)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
qzed
pushed a commit
to linux-surface/kernel
that referenced
this issue
Oct 17, 2020
On Windows, it seems that wifi parent bridge will not enter D3 state
(stay on D0 state) [1]. And on Linux, disabling the D3 state for the
bridge fixes driver crashing after suspend.
This commit disables the parent bridge D3 state on driver initialization
to fix driver crashing after suspend.
NOTE_1: The driver does not crash on LTS 4.4 series but does crash on
LTS 4.9 series. Maybe commit 9d26d3a ("PCI: Put PCIe ports
into D3 during suspend") changed the bridge D-state behavior.
NOTE_2: As a side effect, it reports parent bridge is in D3hot. I'm not
sure why.
acpi device:4b: Cannot transition to power state D0 for parent in D3hot
Power state of the parent bridge on SB1 before this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D0
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
Power state of the parent bridge on SB1 after this commit:
$ grep -H . /sys/bus/pci/devices/0000:00:1d.3/firmware_node/{power_state,real_power_state}
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/power_state:D3hot
/sys/bus/pci/devices/0000:00:1d.3/firmware_node/real_power_state:D3hot
NOTE_3: This change is needed for SP4 and later generations that use
mwifiex (i.e. SP4/SP5/SP6, SB1/SB2 and SL1/SL2). Not needed for
Surface 3 but safe to apply as this change doesn't break S0ix.
Not sure if needed for SP1/SP2 and SP3. Anyway, I think applying
this change to all the devices may be safe regarding S0ix because
Surface 3 can achieve S0ix anyway even when this patch applied.
So, let's apply this change for all the devices for now.
[1] jakeday/linux-surface#554 (comment)
Signed-off-by: Tsuchiya Yuto (kitakar5525) <[email protected]>
Wanted to add a comment that I am seeing this error ( It seems like this may be an upstream Realtek driver or kernel bug: https://bbs.archlinux.org/viewtopic.php?id=244223 and https://bugzilla.kernel.org/show_bug.cgi?id=202473 detail similar issues. |
@yesrod Your comment is linked to at https://github.com/linux-surface/linux-surface/wiki/Surface-Go So because of this I'm wondering, are you still seeing these issues on newer kernels? I have a Surface Go 1 4GB RAM 64GB Storage model running Arch Linux with Gnome 3.38.2 under Wayland, Linux Kernel 5.9.14-arch1-1-surface. The kernel is from the Arch Linux repository that the https://github.com/linux-surface project has running. Gnome about panel in Gnome settings reports the following specs I do not see any issues with the SD card. In fact I have my entire /home partition on a LUKS encrypted F2FS formatted 400GB Sandisk Micro SD card. Suspend also seems to work here after setting up the correct Wi-FI and Bluetooth firmware for the ath10k chip by removing both And replacing with the correct board.bin and adding I do see this in my dmesg Despite the usbhid lines complaining about a "suspend error -5" I see that suspend does work. I should add that my Surface keyboard cover, cobalt blue version, seems to work fine after each suspend. I even have hibernation working to a LUKS encrypted swap partition on the internal eMMC. I no longer have any Windows installed to my Surface Go. When there are firmware updates I boot to a 128GB USB Thumb drive running a copy of "Windows To Go" I set up with rufus, which seems to run indistinguishably from a standard copy of Windows 10, it's only running slower as I suspect due to running off a slower USB drive. If anyone wants me to post some more logs from my setup let me know. |
|
I seem to have been able to get deep sleep working on the Surface Go 1 I have. What I see in my dmesg after adding 'mem_sleep_default=deep' to my kernel parameters and suspending. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
My Surface Book 1 (Skylake) cannot achieve S0ix states (on Windows, it is called Modern Standby or Connected Standby) even if I followed the document [1].
Some SB2 users (Kaby Lake and Kaby Lake R) reported their device can achieve S0ix states
References
The text was updated successfully, but these errors were encountered: