suspend fails - previous kernel works

[khitschler]

When I suspend the screen turns black and the mouse cursor remains frozen on the black screen. There is no reaction to any key or power-button press even Alt-Sysreq-B stays quiet. Only a hard power-up reset helps (yes, indeed with the front button pressed a longer time).

My previous kernel was ubuntu 5.0.0-29-generic. With this kernel I had no trouble with suspend. Since kernel ubuntu 5.0.0-31-generic or 5.0.0.32-generic suspend fails. I tried without luck the kernel 5.3.0-19-generic.

Its a desktop computer from Lenovo V530-15ARR

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-5.0.0-31-generic 5.0.0-31.33~18.04.1
ProcVersionSignature: Ubuntu 5.0.0-31.33~18.04.1-generic 5.0.21
Uname: Linux 5.0.0-31-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.8
Architecture: amd64
CurrentDesktop: KDE
Date: Sat Nov 2 16:55:39 2019
InstallationDate: Installed on 2019-06-17 (138 days ago)
InstallationMedia: Kubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210)
SourcePackage: linux-signed-hwe
UpgradeStatus: No upgrade log present (probably fresh install)

[khitschler (klaus-hitschler)]

The bug propagates through all kernel updates up to 5.0.0-36. I still stuck with 5.0.0-29.

Meanwhile and additionally I tried some BIOS updates from Lenovo without luck. The last BIOS update was o4dj* from 10.2019.

[khitschler (klaus-hitschler)]

I've done some effort to get more information about the bug.

1. BIOS updates with the Lenovo tools are a bit confusing. I still stuck at the BIOS Version O3TKT46A from 07/21/2019. I've opened a support thread at https://forums.lenovo.com/t5/Lenovo-Desktop-Towers/V530-15ARR-Desktop-Tower-BIOS-update-confusion/td-p/4636769 .

2. I've recognized a difference in behavior since kernel 5.3.0-28-generic #30~18.04.1-Ubuntu: Wehn I put the computer into suspend it first does something like a kernel oops with
* RIP: 0010:irq_startup+0xe1/0x100
and after that it shows a few lines later
* PM: suspend_common(): xhci_pci_suspend+0x0/0xd0 returns -110
* PM: pci_pm_suspend(): hcd_pci_suspend+0x0/0x30 returns -110
* PM: dpm_run_callback(): pci_pm_suspend+0x0/0x150 returns -110
* PM: Device 0000:04:00.4 failed to suspend async: error -110
* PM: Some devices failed to suspend, or early wake event detected
then it follows endless repeating kernel oops with
* RIP: 0010:dcn10_verify_allow_pstate_change_high+0x37/0x2d0 [amdgpu]

I've attached the snippet of the journalctl output.

[khitschler (klaus-hitschler)]

Then I compared to the behavior with the kernel 5.0.0-29-generic #31~18.04.1-Ubuntu with the proper suspend behavior from a user's view. There the computer also shows the kernel oops with
* RIP: 0010:irq_startup+0xe1/0xf0
but i ends with a proper suspend.

I've attached the snippet of this suspend, too.

[khitschler (klaus-hitschler)]

I think the bug is related to https://lkml.org/lkml/2019/11/4/13 since the CPU of my computer is a Raven Ridge model.

If there is a kernel available with the patch applied I'm willing to test the patch.

[khitschler (klaus-hitschler)]

I verified my guess through providing a kernel parameter at startup
  xhci-hcd.quirks=0x00020000

where the bit set is along xhci.h:
  #define XHCI_SLOW_SUSPEND BIT_ULL(17)

This quirk provide nearly the same as the patch mentioned in #5.

With kernel 5.3.0-28 and this parameter set the machine suspended without complaining :-) Unfortunately it did not resume :-(

With kernel 5.0.0-37 and this parameter set the machine suspended and resumed without complaining.

Since I misused the kernel parameter this maybe a side effect. If not it is a previously covered bug. This will be a new game.

Again: If there is a kernel available with the patch applied I'm willing to test the patch.

[khitschler (klaus-hitschler)]

With kernel 5.3.0-40 for me the suspend problem is solved. Still I face a resume problem. But that is another game.