Bug 59401
| Summary: | Atom-based machine resumes immediately from S3 suspend | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Zoltan Boszormenyi (zboszor) |
| Component: | Power-Sleep-Wake | Assignee: | acpi_power-sleep-wake |
| Status: | CLOSED PATCH_ALREADY_AVAILABLE | ||
| Severity: | high | CC: | aaron.lu, eburuschkin, lenb, sangshuduo, stilden, tianyu.lan |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | v3.7+ | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
dmesg
Kernel .config Verbose lspci with device names Verbose lspci with vendor:device IDs acpidump after boot acpidump after suspend dmesg after two suspend/resume cycles kernel log from 3.13-rc3+ with very verbose ACPI messages |
||
|
Description
Zoltan Boszormenyi
2013-06-07 08:00:47 UTC
Created attachment 103771 [details]
dmesg
dmesg after an immediate resume. The first suspend after booting up resulted in immediate resuming.
Created attachment 103781 [details]
Kernel .config
Created attachment 103791 [details]
Verbose lspci with device names
Created attachment 103801 [details]
Verbose lspci with vendor:device IDs
(In reply to comment #0) > However, the attached dmesg still has: > > pcieport 0000:00:1c.1: System wakeup enabled by ACPI > > This device is disabled by default in > /sys/devices/pci0000\:00/0000\:00\:1c.1/power/wakeup so I have tried > explicitly > enabling then disabling it. Still, the next suspend resulted in an immediate > resume. From the dmesg, the 1c.1 is a PCI bridge that connects to the Ethernet controller. Is it possible that this is related to Wake On Lan? Is there a BIOS setup option for WOL? Thanks. Yes, there is a Wake-on-LAN option in the BIOS and it is currently enabled. But previously I have tested it with being disabled and it didn't help. I will try with both this BIOS setting disabled and disabling all the devices via the sysfs wakeup files. No, it didn't help either. Also, after resume, some devices re-gain their wakeup enabled state: # find /sys -name "wakeup" | while read i ; do DEV="$i" ; ENAB="`cat $i`" ; if [ "$ENAB" = "enabled" ]; then echo $DEV ; fi ; done /sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.0/power/wakeup /sys/devices/pci0000:00/0000:00:1d.0/power/wakeup /sys/devices/pci0000:00/0000:00:1d.1/usb3/3-2/power/wakeup /sys/devices/pci0000:00/0000:00:1d.1/power/wakeup /sys/devices/pci0000:00/0000:00:1d.2/power/wakeup /sys/devices/pci0000:00/0000:00:1d.3/power/wakeup The previous dmesg contains a testing leftover kernel command line parameter: acpi_sleep=nonvs,old_ordering but it doesn't make any difference if it's there or not. Please provide the output of "cat /proc/acpi/wakeup". After booting up:
# cat /proc/acpi/wakeup
Device S-state Status Sysfs node
P0P1 S4 *disabled pci:0000:00:1e.0
PS2K S4 *enabled pnp:00:03
USB0 S4 *enabled pci:0000:00:1d.0
USB1 S4 *enabled pci:0000:00:1d.1
USB2 S4 *enabled pci:0000:00:1d.2
USB3 S4 *enabled pci:0000:00:1d.3
EUSB S4 *enabled pci:0000:00:1d.7
P0P4 S4 *disabled pci:0000:00:1c.0
P0P5 S4 *disabled pci:0000:00:1c.1
P0P6 S4 *disabled
P0P7 S4 *disabled pci:0000:00:1c.3
P0P8 S4 *disabled
P0P9 S4 *disabled
After touching the sysfs wakeup files with the below script:
# cat /proc/acpi/wakeup
Device S-state Status Sysfs node
P0P1 S4 *disabled pci:0000:00:1e.0
PS2K S4 *disabled pnp:00:03
USB0 S4 *disabled pci:0000:00:1d.0
USB1 S4 *disabled pci:0000:00:1d.1
USB2 S4 *disabled pci:0000:00:1d.2
USB3 S4 *disabled pci:0000:00:1d.3
EUSB S4 *disabled pci:0000:00:1d.7
P0P4 S4 *disabled pci:0000:00:1c.0
P0P5 S4 *disabled pci:0000:00:1c.1
P0P6 S4 *disabled
P0P7 S4 *disabled pci:0000:00:1c.3
P0P8 S4 *disabled
P0P9 S4 *disabled
The initially enabled devices in sysfs:
# find /sys -name "wakeup" | while read i ; \
do \
DEV="$i" ; \
ENAB="`cat $i`" ; \
if [ "$ENAB" = "enabled" ]; then \
echo $DEV ; \
echo "disabled" >$DEV ; \
fi ; \
done
/sys/devices/pnp0/00:03/power/wakeup
/sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.0/power/wakeup
/sys/devices/pci0000:00/0000:00:1d.0/power/wakeup
/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-2/power/wakeup
/sys/devices/pci0000:00/0000:00:1d.1/power/wakeup
/sys/devices/pci0000:00/0000:00:1d.2/power/wakeup
/sys/devices/pci0000:00/0000:00:1d.3/power/wakeup
/sys/devices/pci0000:00/0000:00:1d.7/power/wakeup
/sys/devices/LNXSYSTM:00/LNXPWRBN:00/power/wakeup
All devices with a wakeup file:
# find /sys -name "wakeup"
/sys/devices/pnp0/00:03/power/wakeup
/sys/devices/pnp0/00:06/tty/ttyS0/power/wakeup
/sys/devices/pnp0/00:07/tty/ttyS1/power/wakeup
/sys/devices/pnp0/00:08/tty/ttyS2/power/wakeup
/sys/devices/pnp0/00:09/tty/ttyS3/power/wakeup
/sys/devices/pnp0/00:0a/tty/ttyS4/power/wakeup
/sys/devices/pci0000:00/0000:00:1b.0/power/wakeup
/sys/devices/pci0000:00/0000:00:1c.0/power/wakeup
/sys/devices/pci0000:00/0000:00:1c.1/power/wakeup
/sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.0/power/wakeup
/sys/devices/pci0000:00/0000:00:1c.3/power/wakeup
/sys/devices/pci0000:00/0000:00:1d.0/usb2/power/wakeup
/sys/devices/pci0000:00/0000:00:1d.0/power/wakeup
/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1/power/wakeup
/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-2/power/wakeup
/sys/devices/pci0000:00/0000:00:1d.1/usb3/power/wakeup
/sys/devices/pci0000:00/0000:00:1d.1/power/wakeup
/sys/devices/pci0000:00/0000:00:1d.2/usb4/power/wakeup
/sys/devices/pci0000:00/0000:00:1d.2/power/wakeup
/sys/devices/pci0000:00/0000:00:1d.3/usb5/power/wakeup
/sys/devices/pci0000:00/0000:00:1d.3/power/wakeup
/sys/devices/pci0000:00/0000:00:1d.7/usb1/power/wakeup
/sys/devices/pci0000:00/0000:00:1d.7/power/wakeup
/sys/devices/pci0000:00/0000:00:1e.0/power/wakeup
/sys/devices/pci0000:00/0000:00:1f.2/power/wakeup
/sys/devices/platform/serial8250.3/tty/ttyS5/power/wakeup
/sys/devices/LNXSYSTM:00/LNXPWRBN:00/power/wakeup
Please attach the output of acpidump. From the previous output, all wakeup should be disabled. Created attachment 103831 [details]
acpidump after boot
Created attachment 103841 [details]
acpidump after suspend
These are the two acpidump outputs that are different. It doesn't make any difference (in their md5sum) if the wakeup sources in sysfs are disabled or not. However, there is a difference. When acpidump is run after boot, there is this message: # ./acpidump >acpidump-after-boot-1.out Wrong checksum for generic table! After suspend/resume the message appears twice: # acpidump >acpidump-after-suspend.out Wrong checksum for generic table! Wrong checksum for generic table! Ping. I have provided the acpidump output almost 3 weeks ago. Is it the proper one? I used the kernel acpidump tool from the kernel GIT, in the linux/tools/power/acpi directory. (In reply to comment #15) > Ping. > > I have provided the acpidump output almost 3 weeks ago. Is it the proper one? > I used the kernel acpidump tool from the kernel GIT, in the > linux/tools/power/acpi directory. Yes it is the proper one, thanks. And I do not have any idea why this happened at the moment, sorry. Can you please try building the kernel with CONFIG_PM_RUNTIME not set? Thanks. (In reply to Aaron Lu from comment #17) > Can you please try building the kernel with CONFIG_PM_RUNTIME not set? > Thanks. I can do that next week. ATM I am on holiday and away from my office desktop. I have tested the released 3.10.1 plus an extra patch from https://lkml.org/lkml/2013/7/11/661 to avoid the regression mentioned on LKML with suspend in http://marc.info/?t=137380792100003&r=1&w=2 That happened with this machine, too. I tried both with and without PM_RUNTIME being set and both kernels gave me the same result: the first suspend was successful but the second one resulted in an immediate resume. dmesg for the "PM_RUNTIME not set" run will be attached. It contains the warning messages mentioned previously in https://bugs.freedesktop.org/show_bug.cgi?id=65497 , I think the two problems have some common root. I have also tested (or tried to test) these below with and without CONFIG_PM_RUNTIME. - 3.11-rc1 plus the ext4 fixes landed in GIT very soon after rc1 plus the above patch - linux-next branch from the linux-pm repository from git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git As of writing this, this branch contains 3.11-rc1 plus some fixes including the above patch. The result in each configuration is similar to the above mail with the described regression. After "echo -n 'mem' >/sys/power/state" the machine seems to go into suspend but the power LED stays lit and cannot be resumed by pressing the power button. Pressing the power button for 4 seconds can turn the computer off. Created attachment 106888 [details]
dmesg after two suspend/resume cycles
dmesg for 3.10.1
Created attachment 117961 [details]
kernel log from 3.13-rc3+ with very verbose ACPI messages
I have just tested kernel version 3.13.0-rc3-00157-g17b2112-dirty , the "dirty" is because of the one liner patch to increase the LVDS timeout to 2000ms from 1000ms. I added kernel command line options acpi.debug_layer=0xffffffff acpi.debug_level=0xffffffff.
Unfortunately a lot of logs were lost before klogd actually started, this is why the log starts so strangely. CONFIG_LOG_BUF_SHIFT=21, the maximum.
The logs should contain traces of two suspend-resume cycles, the second suspend resumed immediately.
The above mentioned patch is at https://bugs.freedesktop.org/show_bug.cgi?id=65497#c5 It seems the patches in the linux-pm/linux-next tree make suspend/resume working reliably. It's at https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/log/?h=linux-next , currently at commit efef6dba52777eac8bf2a866caa2d8d80f4e84b0. I have tested this machine using AHCI mode and 50 attempts out of 50 suspends were successful without immedate resuming. I will also test this kernel using IDE mode (both "Enhanced" and "Compatible") to see whether there is any difference when using the ata_piix driver in Linux. As far as I know, the linux-next tree is targeted for 3.14, which won't be released before May 2014, but we can use the patches over 3.13. > I have tested this machine using AHCI mode and 50 attempts out of 50
> suspends were successful without immediate resuming.
Great!
Unfortunately, unclear from above which patch helped.
If it is still an issue w/ upstream kernel, please re-open.
|