Comment 39 for bug 1705748

Revision history for this message
Steve Roberts (drgrumpy) wrote :

Sorry for slow feedback....

Unfortunately the issue is still there:

Aug 15 12:52:58 phs08 kernel: [ 0.000000] Linux version 4.11.0-14-generic (root@ryzen) (gcc version 6.3.0 20170618 (Ubuntu 6.3.0-19ubuntu1) ) #20 SMP Wed Aug 9 20:56:51 CST 2017 (Ubuntu 4.11.0-14.20-generic 4.11.12)
Aug 15 12:52:58 phs08 kernel: [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.11.0-14-generic root=UUID=f7ae652b-cbf6-48b8-bc6a-d3963957ab57 ro

Tue Aug 15 13:31:03 BST 2017: performing suspend
Tue Aug 15 14:11:07 BST 2017: Awake.

Aug 15 14:11:07 phs08 kernel: [ 2297.422103] nvme nvme0: disabling APST...
Aug 15 14:11:07 phs08 kernel: [ 2297.423143] nvme nvme0: setting power state to 0...
...
Aug 15 14:11:07 phs08 kernel: [ 2302.067538] PM: resume of devices complete after 1158.582 msecs
Aug 15 14:11:07 phs08 kernel: [ 2302.067889] PM: Finishing wakeup.
Aug 15 14:11:07 phs08 kernel: [ 2302.067890] Restarting tasks ... done.
Aug 15 14:11:09 phs08 kernel: [ 2304.530720] r8169 0000:25:00.0 enp37s0: link up
Aug 15 14:11:13 phs08 kernel: [ 2307.860622] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Aug 15 14:11:13 phs08 kernel: [ 2307.864647] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Aug 15 14:11:13 phs08 kernel: [ 2307.872508] ata1.00: configured for UDMA/133
Aug 15 14:11:13 phs08 kernel: [ 2307.876591] ata2.00: configured for UDMA/133
Aug 15 14:14:02 phs08 kernel: [ 2477.191603] nvme 0000:01:00.0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0xffff
Aug 15 14:14:02 phs08 kernel: [ 2477.227261] pci_raw_set_power_state: 4 callbacks suppressed
Aug 15 14:14:02 phs08 kernel: [ 2477.227266] nvme 0000:01:00.0: Refused to change power state, currently in D3
Aug 15 14:14:02 phs08 kernel: [ 2477.227394] nvme nvme0: Removing after probe failure status: -19
Aug 15 14:14:02 phs08 kernel: [ 2477.255682] nvme0n1: detected capacity change from 500107862016 to 0

It still seems odd to me that this apparently occurs 2-3 mins after the system has woken up...

One thing that confuses me is that the suspend operations like:

"nvme nvme0: disabling APST..."

are recorded as happening after the system has woken up ! Is this a matter of them not being logged until the system has woken up or actually not executing until the system has woken up ?... either
way it is confusing to see suspend operations occuring after the system has resumed.