Bug 74371

Hi, from the log, serial device blocks the system suspend.

(In reply to Lan Tianyu from comment #1)
> Hi, from the log, serial device blocks the system suspend.

yea,  but it should be suspend.

kernel 3.13 (<3.14) works good.  

and have no error text
"
[    0.294492] ACPI: \_PR_.P003: failed to get CPU APIC ID.
[    0.294495] ACPI: \_PR_.P004: failed to get CPU APIC ID.
[    0.294497] ACPI: \_PR_.P005: failed to get CPU APIC ID.
[    0.294500] ACPI: \_PR_.P006: failed to get CPU APIC ID.
"

[pc:~] lspci 
00:00.0 RAM memory: NVIDIA Corporation MCP61 Host Bridge (rev a1)
00:01.0 ISA bridge: NVIDIA Corporation MCP61 LPC Bridge (rev a2)
00:01.1 SMBus: NVIDIA Corporation MCP61 SMBus (rev a2)
00:01.2 RAM memory: NVIDIA Corporation MCP61 Memory Controller (rev a2)
00:02.0 USB controller: NVIDIA Corporation MCP61 USB 1.1 Controller (rev a3)
00:02.1 USB controller: NVIDIA Corporation MCP61 USB 2.0 Controller (rev a3)
00:04.0 PCI bridge: NVIDIA Corporation MCP61 PCI bridge (rev a1)
00:05.0 Audio device: NVIDIA Corporation MCP61 High Definition Audio (rev a2)
00:06.0 IDE interface: NVIDIA Corporation MCP61 IDE (rev a2)
00:07.0 Bridge: NVIDIA Corporation MCP61 Ethernet (rev a2)
00:08.0 IDE interface: NVIDIA Corporation MCP61 SATA Controller (rev a2)
00:08.1 IDE interface: NVIDIA Corporation MCP61 SATA Controller (rev a2)
00:09.0 PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2)
00:0b.0 PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2)
00:0c.0 PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2)
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Address Map
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Link Control
02:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2)
02:00.1 Audio device: NVIDIA Corporation High Definition Audio Controller (rev a1)
[pc:~] lsusb
Bus 001 Device 003: ID 1871:0101 Aveo Technology Corp. UVC camera (Bresser microscope)
Bus 001 Device 004: ID 05e3:0723 Genesys Logic, Inc. GL827L SD/MMC/MS Flash Card Reader
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 046a:0011 Cherry GmbH G83 (RS 6000) Keyboard
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

(In reply to wxg4net from comment #2)
> (In reply to Lan Tianyu from comment #1)
> > Hi, from the log, serial device blocks the system suspend.
> 
> yea,  but it should be suspend.
> 
> kernel 3.13 (<3.14) works good. 

So this is a regression. Could you do git bisect?

> 
> and have no error text
> "
> [    0.294492] ACPI: \_PR_.P003: failed to get CPU APIC ID.
> [    0.294495] ACPI: \_PR_.P004: failed to get CPU APIC ID.
> [    0.294497] ACPI: \_PR_.P005: failed to get CPU APIC ID.
> [    0.294500] ACPI: \_PR_.P006: failed to get CPU APIC ID.
> "

This is another issue and not related with system suspend.

ok i will try.

@Lan Tianyu. i just paste it as follows. (my english is not very good , but i am working on it)

[pc:~/Source/linux] git bisect bad
202317a573b20d77a9abb7c16a3fd5b40cef3d9d is the first bad commit
commit 202317a573b20d77a9abb7c16a3fd5b40cef3d9d
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Fri Nov 22 21:54:37 2013 +0100

    ACPI / scan: Add acpi_device objects for all device nodes in the namespace
    
    Modify the ACPI namespace scanning code to register a struct
    acpi_device object for every namespace node representing a device,
    processor and so on, even if the device represented by that namespace
    node is reported to be not present and not functional by _STA.
    
    There are multiple reasons to do that.  First of all, it avoids
    quite a lot of overhead when struct acpi_device objects are
    deleted every time acpi_bus_trim() is run and then added again
    by a subsequent acpi_bus_scan() for the same scope, although the
    namespace objects they correspond to stay in memory all the time
    (which always is the case on a vast majority of systems).
    
    Second, it will allow user space to see that there are namespace
    nodes representing devices that are not present at the moment and may
    be added to the system.  It will also allow user space to evaluate
    _SUN for those nodes to check what physical slots the "missing"
    devices may be put into and it will make sense to add a sysfs
    attribute for _STA evaluation after this change (that will be
    useful for thermal management on some systems).
    
    Next, it will help to consolidate the ACPI hotplug handling among
    subsystems by making it possible to store hotplug-related information
    in struct acpi_device objects in a standard common way.
    
    Finally, it will help to avoid a race condition related to the
    deletion of ACPI namespace nodes.  Namely, namespace nodes may be
    deleted as a result of a table unload triggered by _EJ0 or _DCK.
    If a hotplug notification for one of those nodes is triggered
    right before the deletion and it executes a hotplug callback
    via acpi_hotplug_execute(), the ACPI handle passed to that
    callback may be stale when the callback actually runs.  One way
    to work around that is to always pass struct acpi_device pointers
    to hotplug callbacks after doing a get_device() on the objects in
    question which eliminates the use-after-free possibility (the ACPI
    handles in those objects are invalidated by acpi_scan_drop_device(),
    so they will trigger ACPICA errors on attempts to use them).
    
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>

:040000 040000 35dbf7e48aefa948423794c493735c1f53888ca7 468f72c1d2701c915ea11dad167a037ae17ee442 M	Documentation
:040000 040000 dab9b3c433acff383f2e4388b69cdb5c70165419 8c9784d505369210a42bc69aeffdacf623e5f7ac M	drivers
:040000 040000 d22abfd7cfccd5212bde95b41ca354f51aa8630d b99738ef79bd9e9d7392f6e400029b5a1622aefc M	include

Please provide the output of acpidump.

Created attachment 133011 [details]
acpidump

Created attachment 133021 [details]
dmesg-for first bad commit

Created attachment 133041 [details]
serial.patch

Please try this patch.

(In reply to Lan Tianyu from comment #10)
> Created attachment 133041 [details]
> serial.patch
> 
> Please try this patch.

it do not work 
pciture；http://t.cn/8sjcDfH

Now, what shall we do next?

Could you provide dmesg on good kernel?

Created attachment 133121 [details]
dmesg-kernel-3.13.10-ck

Created attachment 133131 [details]
acpidump-kernel-3.13.10-ck

Hi, I have just experienced the same error and can recreate it by reapplying kernel 3.14.  What extra info is needed to help?

$ lspci
00:00.0 Host bridge: NVIDIA Corporation MCP79 Host Bridge (rev b1)
00:00.1 RAM memory: NVIDIA Corporation MCP79 Memory Controller (rev b1)
00:03.0 ISA bridge: NVIDIA Corporation MCP79 LPC Bridge (rev b2)
00:03.1 RAM memory: NVIDIA Corporation MCP79 Memory Controller (rev b1)
00:03.2 SMBus: NVIDIA Corporation MCP79 SMBus (rev b1)
00:03.3 RAM memory: NVIDIA Corporation MCP79 Memory Controller (rev b1)
00:03.4 RAM memory: NVIDIA Corporation MCP79 Memory Controller (rev b1)
00:03.5 Co-processor: NVIDIA Corporation MCP79 Co-processor (rev b1)
00:04.0 USB controller: NVIDIA Corporation MCP79 OHCI USB 1.1 Controller (rev b1)
00:04.1 USB controller: NVIDIA Corporation MCP79 EHCI USB 2.0 Controller (rev b1)
00:06.0 USB controller: NVIDIA Corporation MCP79 OHCI USB 1.1 Controller (rev b1)
00:06.1 USB controller: NVIDIA Corporation MCP79 EHCI USB 2.0 Controller (rev b1)
00:08.0 Audio device: NVIDIA Corporation MCP79 High Definition Audio (rev b1)
00:09.0 PCI bridge: NVIDIA Corporation MCP79 PCI Bridge (rev b1)
00:0a.0 Ethernet controller: NVIDIA Corporation MCP79 Ethernet (rev b1)
00:0b.0 IDE interface: NVIDIA Corporation MCP79 SATA Controller (rev b1)
00:0c.0 PCI bridge: NVIDIA Corporation MCP79 PCI Express Bridge (rev b1)
00:15.0 PCI bridge: NVIDIA Corporation MCP79 PCI Express Bridge (rev b1)
00:16.0 PCI bridge: NVIDIA Corporation MCP79 PCI Express Bridge (rev b1)
01:06.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 02)
02:00.0 VGA compatible controller: NVIDIA Corporation G92 [GeForce 9800 GT] (rev a2)
04:00.0 IDE interface: JMicron Technology Corp. JMB368 IDE controller
$ lsusb
Bus 004 Device 004: ID 04d9:1603 Holtek Semiconductor, Inc. Keyboard
Bus 004 Device 003: ID 046d:c408 Logitech, Inc. Marble Mouse (4-button)
Bus 004 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
$ lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                2
On-line CPU(s) list:   0,1
Thread(s) per core:    1
Core(s) per socket:    2
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 23
Model name:            Intel(R) Core(TM)2 Duo CPU     E7300  @ 2.66GHz
Stepping:              6
CPU MHz:               1603.000
CPU max MHz:           2670.0000
CPU min MHz:           1603.0000
BogoMIPS:              5335.85
L1d cache:             32K
L1i cache:             32K
L2 cache:              3072K
NUMA node0 CPU(s):     0,1

There are two errors mentioned in the report, the

ACPI: \_PR_.P003: failed to get CPU APIC ID.

one which should be worked around by commit f778d1218f10
(ACPI / scan: reduce log level of "ACPI: \_PR_.CPU4: failed
to get CPU APIC ID") in 3.15-rc1 and later.

The second one is the serial suspend issue.

Which of the problems do you mean?

(In reply to wxg4net from comment #12)
> Now, what shall we do next?

I suppose that pnpacpi_suspend() fails for you, but we don't know which part of it fails.

Actually, I was wrong, it's pnp_stop_dev() that fails.

Moreover, the error message tells us that the protocol's ->disable() callback returns an error code and that's pnpacpi_disable_resources() for the ACPI protocol.

Now, the only reason why that can fail is because

acpi_evaluate_object(handle, "_DIS", NULL, NULL)

returns an error code, which is quite obvious in your case, because there's no _DIS for that device in the ACPI tables of your system.  That is not a BIOS bug, but a bug in pnpacpi_disable_resources() which should check for that particular case.

Created attachment 134281 [details]
PNP / ACPI: Check if _DIS is present in pnpacpi_disable_resources()

Can you please check if this patch helps?

Both issues occur with 3.14 only.  I see almost identical results as wxg4net.

$ dmesg | grep fail
[    0.129027] ACPI: \_PR_.P003: failed to get CPU APIC ID.
[    0.129031] ACPI: \_PR_.P004: failed to get CPU APIC ID.
[    0.129363] acpi PNP0A03:00: _OSC failed (AE_SUPPORT); disabling ASPM
[   80.215565] serial 00:0a: disable failed
[   80.215577] PM: Device 00:0a failed to suspend: error -5
[   80.270098] PM: Some devices failed to suspend, or early wake event detected
[   87.625801] serial 00:0a: disable failed
[   87.625812] PM: Device 00:0a failed to suspend: error -5
[   87.680101] PM: Some devices failed to suspend, or early wake event detected
[   95.043763] serial 00:0a: disable failed
[   95.043774] PM: Device 00:0a failed to suspend: error -5
[   95.100102] PM: Some devices failed to suspend, or early wake event detected

And here is one of the suspend attempts in detail:

[   74.227178] PM: Syncing filesystems ... done.
[   74.232772] PM: Preparing system for mem sleep
[   74.737994] Freezing user space processes ... (elapsed 0.002 seconds) done.
[   74.740107] Freezing remaining freezable tasks ... (elapsed 5.471 seconds) done.
[   80.211817] PM: Entering mem sleep
[   80.211847] Suspending console(s) (use no_console_suspend to debug)
[   80.215257] sd 3:0:0:0: [sdb] Stopping disk
[   80.215301] sd 2:0:0:0: [sda] Synchronizing SCSI cache
[   80.215565] serial 00:0a: disable failed
[   80.215574] dpm_run_callback(): pnp_bus_suspend+0x0/0x20 returns -5
[   80.215577] PM: Device 00:0a failed to suspend: error -5
[   80.216104] sd 2:0:0:0: [sda] Stopping disk
[   80.270098] PM: Some devices failed to suspend, or early wake event detected
[   80.271486] sd 2:0:0:0: [sda] Starting disk
[   80.271567] sd 3:0:0:0: [sdb] Starting disk
[   80.590030] ata7: SATA link down (SStatus 0 SControl 300)
[   80.590041] ata8: SATA link down (SStatus 0 SControl 300)
[   80.590051] ata5: SATA link down (SStatus 0 SControl 300)
[   80.590073] ata6: SATA link down (SStatus 0 SControl 300)
[   80.593212] PM: resume of devices complete after 323.109 msecs
[   80.614945] PM: Finishing wakeup.
[   80.614947] Restarting tasks ... done.

Thanks.

So what about the patch in comment #20?

Suspend now works with that patch!  If I understand your description this means  the error is detected but not hidden, which fits what can now be seen in the log.

$ dmesg | grep fail
[    0.126395] ACPI: \_PR_.P003: failed to get CPU APIC ID.
[    0.126399] ACPI: \_PR_.P004: failed to get CPU APIC ID.
[    0.126734] acpi PNP0A03:00: _OSC failed (AE_SUPPORT); disabling ASPM
[   34.265683] serial 00:0a: activation failed
[   34.265690] PM: Device 00:0a failed to resume: error -5

Previously the suspend would fail 3 times but now it succeeds on the first attempt.

Thanks a lot for testing!

What you're seeing now is an analogous problem during resume: we are trying to use the _SRS method which is missing.

Created attachment 134481 [details]
PNP / ACPI: Check if _DIS and _SRS are present when disabling/enabling devices

Please check if this patch fixes the resume error too.

That definitely fixed it.  The only remaining error message is the earlier one which you say is gone as of 3.15-rc1.

Congratulations on your bug hunt.

Thanks!

Patch: https://patchwork.kernel.org/patch/4096201/

Good! to Lan Tianyu and Rafael J. Wysocki thanks very much.

*** Bug 74831 has been marked as a duplicate of this bug. ***

In Linux 3.15-rc4:

commit a8d22396302b7e4e5f0a594c1c1594388c29edaf
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Wed Apr 30 22:36:33 2014 +0200

    PNP / ACPI: Do not return errors if _DIS or _SRS are not present