linux-oem 4.15 can not suspend to idle XPS-13-9380

[Alex Tu]

it somehow s2i failed, from message , it seems the s2i process be blocked by thunderbolt device.

dmesg:
[193139.391652] pciehp 0000:04:04.0:pcie204: pcie_do_write_cmd: no response from device
[193139.391703] pciehp 0000:04:01.0:pcie204: pcie_do_write_cmd: no response from device
[193141.012736] PM: noirq suspend of devices failed
[193141.772467] ath10k_pci 0000:02:00.0: Unknown eventid: 118809
[193141.775359] ath10k_pci 0000:02:00.0: Unknown eventid: 90118
[193141.872317] thunderbolt 0000:05:00.0: control channel starting...

Not sure is it relative that I hot plug out WD19 docking before suspend.

reproduce rate:
random

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-1045-oem 4.15.0-1045.50
ProcVersionSignature: Ubuntu 4.15.0-1045.50-oem 4.15.18
Uname: Linux 4.15.0-1045-oem x86_64
ApportVersion: 2.20.9-0ubuntu7.7
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Sat Aug 17 00:02:08 2019
InstallationDate: Installed on 2019-08-11 (5 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
SourcePackage: linux-signed-oem
UpgradeStatus: No upgrade log present (probably fresh install)

[Alex Tu (alextu)]

the latest suspend is what I tried by pm_test, so when the issue happens, the issue always there even by pm_test before I reboot it.

[Alex Tu (alextu)]

this issue happens all the time on my machine now, then I tried mainline kernel.
It can not be reproduced on latest mainline kernel 5.2.8-050208-generic and 5.3.0-050300rc4-generic

btw, on the case of #3, pm_test failed at platform level but passed on devices level.

[Alex Tu (alextu)]

this issue can not be reproduced on linux-oem-osp1 5.0.0.1020.21.

[Alex Tu (alextu)]

I just found that s2i back to work after I removed multipass snap package.
BTW, the multipass version is multipass (beta) 0.8.0.

This issue looks not impact users who not installed multipass, so I'll lower the priority.

[Alex Tu (alextu)]

opened a new bug on multipass project:
https://github.com/CanonicalLtd/multipass/issues/1030

[Michał Sawicz (saviq)]

Hey,

Can you confirm whether this was when you had Multipass instances running (multipass list), or just when Multipass is installed?

Multipass just manages qemu/kvm VM - the same bug is likely to be caused by libvirt or a manually started qemu VM. In essence, this would be a bug in KVM (especially if a different kernel makes the issue go away), not in Multipass?

[Alex Tu (alextu)]

Hi saviq,

Followed #7, the machine can S2I well, then after I installing multipass again without running any instance, the S2I will fail.

hmm, it could be an issue of KVM, I will check that when I have spare time.

Btw, the S2I will not be impacted with virtual box 6.0.12-133076~Ubuntu~bionic , but it's not using KVM anyway.

[Alex Tu (alextu)]

just installed kvm+virt and initialated a vm instance then do S2I works well.
here list the installed packages version:

Start-Date: 2019-09-11 18:17:24
Commandline: apt-get install -y qemu-kvm libvirt-bin virtinst
Requested-By: alextu (1000)
Install: libusbredirparser1:amd64 (0.7.1-1, automatic), seabios:amd64 (1.10.2-1ubuntu1, automatic), libgovirt2:amd64 (0.3.4-2, automatic), libnl-route-3-200:amd64 (3.2.29-0ubuntu3, automatic), libaugeas0:amd64 (1.10.1-2, automatic), virtinst:amd64 (1:1.5.1-0ubuntu1.2), osinfo-db:amd64 (0.20180929-1ubuntu0.1, automatic), ipxe-qemu:amd64 (1.0.0+git-20180124.fbe8c52d-0ubuntu2.2, automatic), libxml2-utils:amd64 (2.9.4+dfsg1-6.1ubuntu1.2, automatic), libibverbs1:amd64 (17.1-1ubuntu0.1, automatic), libosinfo-1.0-0:amd64 (1.1.0-1, automatic), spice-client-glib-usb-acl-helper:amd64 (0.34-1.1build1, automatic), msr-tools:amd64 (1.3-2build1, automatic), bridge-utils:amd64 (1.5-15ubuntu1, automatic), python-libvirt:amd64 (4.0.0-1, automatic), augeas-lenses:amd64 (1.10.1-2, automatic), librbd1:amd64 (12.2.12-0ubuntu0.18.04.2, automatic), ibverbs-providers:amd64 (17.1-1ubuntu0.1, automatic), qemu-system-x86:amd64 (1:2.11+dfsg-1ubuntu7.18, automatic), libaio1:amd64 (0.3.110-5ubuntu0.1, automatic), ebtables:amd64 (2.0.10.4-3.5ubuntu2.18.04.3, automatic), libusbredirhost1:amd64 (0.7.1-1, automatic), libnetcf1:amd64 (1:0.2.8-1ubuntu2, automatic), libvirt-clients:amd64 (4.0.0-1ubuntu8.12, automatic), librdmacm1:amd64 (17.1-1ubuntu0.1, automatic), libspice-server1:amd64 (0.14.0-1ubuntu2.4, automatic), libvirt-daemon-driver-storage-rbd:amd64 (4.0.0-1ubuntu8.12, automatic), libphodav-2.0-common:amd64 (2.2-2, automatic), libgovirt-common:amd64 (0.3.4-2, automatic), libvirt-bin:amd64 (4.0.0-1ubuntu8.12), libxenstore3.0:amd64 (4.9.2-0ubuntu1, automatic), libgvnc-1.0-0:amd64 (0.7.2-1, automatic), qemu-utils:amd64 (1:2.11+dfsg-1ubuntu7.18, automatic), libvirt-daemon-system:amd64 (4.0.0-1ubuntu8.12, automatic), libcacard0:amd64 (1:2.5.0-3, automatic), python-ipaddr:amd64 (2.2.0-1, automatic), sharutils:amd64 (1:4.15.2-3, automatic), ipxe-qemu-256k-compat-efi-roms:amd64 (1.0.0+git-20150424.a25a16d-0ubuntu2, automatic), virt-viewer:amd64 (6.0-2, automatic), libspice-client-glib-2.0-8:amd64 (0.34-1.1build1, automatic), libxen-4.9:amd64 (4.9.2-0ubuntu1, automatic), libvirt-glib-1.0-0:amd64 (1.0.0-1, automatic), python-libxml2:amd64 (2.9.4+dfsg1-6.1ubuntu1.2, automatic), qemu-kvm:amd64 (1:2.11+dfsg-1ubuntu7.18), libvirt0:amd64 (4.0.0-1ubuntu8.12, automatic), libfdt1:amd64 (1.4.5-3, automatic), libiscsi7:amd64 (1.17.0-1.1, automatic), libphodav-2.0-0:amd64 (2.2-2, automatic), cpu-checker:amd64 (0.7-0ubuntu7, automatic), qemu-block-extra:amd64 (1:2.11+dfsg-1ubuntu7.18, automatic), gir1.2-libosinfo-1.0:amd64 (1.1.0-1, automatic), libspice-client-gtk-3.0-5:amd64 (0.34-1.1build1, automatic), librados2:amd64 (12.2.12-0ubuntu0.18.04.2, automatic), libgtk-vnc-2.0-0:amd64 (0.7.2-1, automatic), qemu-system-common:amd64 (1:2.11+dfsg-1ubuntu7.18, automatic), libvirt-daemon:amd64 (4.0.0-1ubuntu8.12, automatic)
End-Date: 2019-09-11 18:17:41

Start-Date: 2019-09-11 19:46:26
Commandline: apt-get install virt-manager
Requested-By: alextu (1000)
Inst...

[Michał Sawicz (saviq)]

If it doesn't require an instance to break S2I, that suggests something in our daemon after all.

I wouldn't think we'd be doing anything low-level enough to cause this, though…