USBVM Blocks S3 sleep #1419

DeltaHeavy · Nov 13, 2015

When I have the USB controllers under dom0 (no USBVM) dropping to S3 sleep takes just under a second.

However, when a USBVM has been assigned PCI devices (The two USB2.0 controllers, in my case), dropping to S3 sleep takes upward of 15 seconds.

I'm not entirely sure the nature of the bug - it may have something to do with the fact that detaching block devices from VMs with qvm-block has reported LibVirt errors ("failed to detach").

I'm sorry this is unspecific, let me know what output (dom0 / usbvm dmesg?) will help in diagnostics.

Thanks!

Do you have block devices (qvm-block) attached when going to sleep? This
might be a problem.
Anyway check logs in dom0 and USB VM (journalctl) to see what takes that
much time.

Also some USB 3.0 controllers makes problems with S3 sleep. If you
happen to have some of them, simply add xhci_pci module to
/rw/config/suspend-module-blacklist

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

marmarek · Nov 13, 2015

Do you have block devices (qvm-block) attached when going to sleep? This
might be a problem.
Anyway check logs in dom0 and USB VM (journalctl) to see what takes that
much time.

Also some USB 3.0 controllers makes problems with S3 sleep. If you
happen to have some of them, simply add xhci_pci module to
/rw/config/suspend-module-blacklist

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

No devices attached on sleep, I haven't tried sleeping with devices
attached although I assume that will go similarly or worse.

I was having pci reset issues with my usbvm so I disabled USB3 in the BIOS
a while ago.

I'll let you know what the logs look like, thanks as always.

Max
On Nov 13, 2015 12:58 PM, "Marek Marczykowski-Górecki" <
notifications@github.com> wrote:

Do you have block devices (qvm-block) attached when going to sleep? This
might be a problem.
Anyway check logs in dom0 and USB VM (journalctl) to see what takes that
much time.

Also some USB 3.0 controllers makes problems with S3 sleep. If you
happen to have some of them, simply add xhci_pci module to
/rw/config/suspend-module-blacklist

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

—
Reply to this email directly or view it on GitHub
#1419 (comment)
.

DeltaHeavy · Nov 13, 2015

No devices attached on sleep, I haven't tried sleeping with devices
attached although I assume that will go similarly or worse.

I was having pci reset issues with my usbvm so I disabled USB3 in the BIOS
a while ago.

I'll let you know what the logs look like, thanks as always.

Max
On Nov 13, 2015 12:58 PM, "Marek Marczykowski-Górecki" <
notifications@github.com> wrote:

Do you have block devices (qvm-block) attached when going to sleep? This
might be a problem.
Anyway check logs in dom0 and USB VM (journalctl) to see what takes that
much time.

Also some USB 3.0 controllers makes problems with S3 sleep. If you
happen to have some of them, simply add xhci_pci module to
/rw/config/suspend-module-blacklist

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

—
Reply to this email directly or view it on GitHub
#1419 (comment)
.

The only journalctl entries that seems to stand out:

Dom0

the suspension of the netvm (although this doesn't affect time when sys-usb has been deleted)
clock syncing (I don't have a clockVM set..?) although the time elapsed is a fraction of a second
libvirtd[867] EOF while reading data I/O error

sys-usb (usbvm)

nothing out of the ordinary

EDIT: Setting a clockVM had no effect

DeltaHeavy · Nov 15, 2015

The only journalctl entries that seems to stand out:

Dom0

the suspension of the netvm (although this doesn't affect time when sys-usb has been deleted)
clock syncing (I don't have a clockVM set..?) although the time elapsed is a fraction of a second
libvirtd[867] EOF while reading data I/O error

sys-usb (usbvm)

nothing out of the ordinary

EDIT: Setting a clockVM had no effect

You can still try with blacklisting module - in case of USB 2.0, it would be ehci_pci. Write it to /rw/config/suspend-module-blacklist

marmarek · Nov 28, 2015

You can still try with blacklisting module - in case of USB 2.0, it would be ehci_pci. Write it to /rw/config/suspend-module-blacklist

I couldn't seem the glean a full answer from some cursory googling, what
does the blacklisting actually do?

Thanks!
On Nov 28, 2015 3:30 PM, "Marek Marczykowski-Górecki" <
notifications@github.com> wrote:

You can still try with blacklisting module - in case of USB 2.0, it would
be ehci_pci. Write it to /rw/config/suspend-module-blacklist

—
Reply to this email directly or view it on GitHub
#1419 (comment)
.

DeltaHeavy · Nov 30, 2015

I couldn't seem the glean a full answer from some cursory googling, what
does the blacklisting actually do?

Thanks!
On Nov 28, 2015 3:30 PM, "Marek Marczykowski-Górecki" <
notifications@github.com> wrote:

You can still try with blacklisting module - in case of USB 2.0, it would
be ehci_pci. Write it to /rw/config/suspend-module-blacklist

—
Reply to this email directly or view it on GitHub
#1419 (comment)
.

I couldn't seem the glean a full answer from some cursory googling, what does the blacklisting actually do?

It will unload the module before suspend and load it back after resume (if was loaded at suspend time). Described here: https://www.qubes-os.org/doc/config-files/

marmarek · Dec 26, 2015

I couldn't seem the glean a full answer from some cursory googling, what does the blacklisting actually do?

It will unload the module before suspend and load it back after resume (if was loaded at suspend time). Described here: https://www.qubes-os.org/doc/config-files/

Duly noted, thanks as always.

That said, it doesn't seem to have solved the issue. From lsusb.py I
noticed the device referred to as ehci_hcd, but trying that in the
blacklist didn't work either. Is there a way to list those IDs of hub
devices to tell what exactly to put in the blacklist?

Thanks!

I couldn't seem the glean a full answer from some cursory googling, what
does the blacklisting actually do?

It will unload the module before suspend and load it back after resume (if
was loaded at suspend time). Described here:
https://www.qubes-os.org/doc/config-files/

—
Reply to this email directly or view it on GitHub
#1419 (comment)
.

DeltaHeavy · Dec 28, 2015

Duly noted, thanks as always.

That said, it doesn't seem to have solved the issue. From lsusb.py I
noticed the device referred to as ehci_hcd, but trying that in the
blacklist didn't work either. Is there a way to list those IDs of hub
devices to tell what exactly to put in the blacklist?

Thanks!

I couldn't seem the glean a full answer from some cursory googling, what
does the blacklisting actually do?

It will unload the module before suspend and load it back after resume (if
was loaded at suspend time). Described here:
https://www.qubes-os.org/doc/config-files/

—
Reply to this email directly or view it on GitHub
#1419 (comment)
.

In latest kernels, ehci_hcd was split into ehci_hcd and ehci_pci - the later one is actually bound to the device (and depends on ehci_hcd), so this is the one to blacklist.

Anyway, I have similar issue on one laptop, will look into that closer.

marmarek · Dec 28, 2015

In latest kernels, ehci_hcd was split into ehci_hcd and ehci_pci - the later one is actually bound to the device (and depends on ehci_hcd), so this is the one to blacklist.

Anyway, I have similar issue on one laptop, will look into that closer.

Thanks. I'll try some configurations as well and let you know if anything
comes of it.
On Dec 28, 2015 4:17 AM, "Marek Marczykowski-Górecki" <
notifications@github.com> wrote:

In latest kernels, ehci_hcd was split into ehci_hcd and ehci_pci - the
later one is actually bound to the device (and depends on ehci_hcd), so
this is the one to blacklist.

Anyway, I have similar issue on one laptop, will look into that closer.

—
Reply to this email directly or view it on GitHub
#1419 (comment)
.

DeltaHeavy · Dec 28, 2015

Thanks. I'll try some configurations as well and let you know if anything
comes of it.
On Dec 28, 2015 4:17 AM, "Marek Marczykowski-Górecki" <
notifications@github.com> wrote:

In latest kernels, ehci_hcd was split into ehci_hcd and ehci_pci - the
later one is actually bound to the device (and depends on ehci_hcd), so
this is the one to blacklist.

Anyway, I have similar issue on one laptop, will look into that closer.

—
Reply to this email directly or view it on GitHub
#1419 (comment)
.

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-3.1.12-1.fc21 has been pushed to the r3.1 testing repository for the Fedora fc21 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r3.1-current-testing

QubesOS/qubes-issues

Join GitHub today

USBVM Blocks S3 sleep #1419

Comments

DeltaHeavy commented Nov 13, 2015

This comment has been minimized.

marmarek commented Nov 13, 2015

This comment has been minimized.

DeltaHeavy commented Nov 13, 2015

This comment has been minimized.

DeltaHeavy commented Nov 15, 2015

This comment has been minimized.

marmarek commented Nov 28, 2015

This comment has been minimized.

DeltaHeavy commented Nov 30, 2015

This comment has been minimized.

marmarek commented Dec 26, 2015

marmarek added C: core C: kernel P: minor labels Dec 26, 2015

marmarek added this to the Release 3.1 milestone Dec 26, 2015

This comment has been minimized.

DeltaHeavy commented Dec 28, 2015

This comment has been minimized.

marmarek commented Dec 28, 2015

This comment has been minimized.

DeltaHeavy commented Dec 28, 2015

marmarek referenced this issue Dec 29, 2015

marmarek added the bug label Jan 10, 2016

marmarek closed this in marmarek/old-qubes-core-agent-linux@cb5c457 Jan 11, 2016

This comment has been minimized.

marmarek commented Jan 12, 2016

marmarek added the r3.1-fc21-cur-test label Jan 12, 2016

This comment has been minimized.

marmarek commented Jan 12, 2016

marmarek added the r3.1-fc22-cur-test label Jan 12, 2016

This comment has been minimized.

marmarek commented Jan 12, 2016

marmarek added the r3.1-fc23-cur-test label Jan 12, 2016

This comment has been minimized.

marmarek commented Jan 12, 2016

marmarek added r3.1-fc21-stable and removed r3.1-fc21-cur-test labels Jan 12, 2016

This comment has been minimized.

marmarek commented Jan 12, 2016

marmarek added r3.1-fc22-stable and removed r3.1-fc22-cur-test labels Jan 12, 2016

This comment has been minimized.

marmarek commented Jan 12, 2016

marmarek added r3.1-fc23-stable and removed r3.1-fc23-cur-test labels Jan 12, 2016

This comment has been minimized.

marmarek commented Jan 13, 2016

marmarek added the r3.1-jessie-cur-test label Jan 13, 2016

This comment has been minimized.

marmarek commented Jan 13, 2016

marmarek added the r3.1-stretch-cur-test label Jan 13, 2016

This comment has been minimized.

marmarek commented Jan 13, 2016

marmarek added the r3.1-wheezy-cur-test label Jan 13, 2016

This comment has been minimized.

marmarek commented Jan 13, 2016

marmarek added r3.1-jessie-stable and removed r3.1-jessie-cur-test labels Jan 13, 2016

This comment has been minimized.

marmarek commented Jan 13, 2016

marmarek added r3.1-wheezy-stable and removed r3.1-wheezy-cur-test labels Jan 13, 2016

marmarek added a commit to QubesOS/qubes-core-agent-linux that referenced this issue Jan 15, 2016

This comment has been minimized.

marmarek commented Jan 15, 2016

marmarek added the r3.0-fc20-testing label Jan 15, 2016

This comment has been minimized.

marmarek commented Jan 15, 2016

marmarek added the r3.0-fc21-testing label Jan 15, 2016

This comment has been minimized.

marmarek commented Jan 15, 2016

marmarek added the r3.0-fc22-testing label Jan 15, 2016

This comment has been minimized.

marmarek commented Jan 15, 2016

marmarek added the r3.0-fc23-testing label Jan 15, 2016

This comment has been minimized.

marmarek commented Jan 15, 2016

marmarek added the r3.0-jessie-testing label Jan 15, 2016

This comment has been minimized.

marmarek commented Jan 15, 2016

marmarek added the r3.0-wheezy-testing label Jan 15, 2016

marmarek closed this in `marmarek/old-qubes-core-agent-linux@cb5c457` Jan 11, 2016