New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

suspend: restart ehci_hcd module on resume for all netvms #299

Closed
marmarek opened this Issue Mar 8, 2015 · 4 comments

Comments

Projects
None yet
2 participants
@marmarek
Member

marmarek commented Mar 8, 2015

Reported by joanna on 18 Jul 2011 11:22 UTC
When using a 3G USB-based modem I noticed it breaks after resume (for two different modems actually).

I have fixed this by modifying our 01qubes-suspend-netvm script by adding rmmod and modprobe ehci_hcd on suspend and resume:

suspend_net()
{
    for VM in `get_running_netvms`; do
        qvm-run -u root --pass_io $VM 'service NetworkManager stop; for if in `ls /sys/class/net|grep -v "lo\|vif"`; do ip l s $if down; done; rmmod ehci_hcd'
    done
    # Ignore exit status from netvm...
    return 0
}

resume_net()
{
    for VM in `get_running_netvms`; do
        qvm-run -u root --pass_io $VM "modprobe ehci_hcd; service NetworkManager start"
    done
    # Ignore exit status from netvm...
    return 0
}

Now, my 3G connection is automatically brought up after resume :)

Do we want to commit those changes to core? Are there any reasons not to? Note that this is also executed for my NetVM that doesn't have any USB controller assigned and this doesn't break anything? (I have a separate UsbVM with all USB controllers there), which is also a NetVM.

Migrated-From: https://wiki.qubes-os.org/ticket/299

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by marmarek on 21 Jul 2011 00:40 UTC
Most likely this will fail when there are some USB devices connected during suspend (eg internal bluetooth adapter)- this is not so easy.
Perhaps this will requires some sysfs writes before (or instead of), like /sys/bus/usb/device/usb*/remove.

Member

marmarek commented Mar 8, 2015

Comment by marmarek on 21 Jul 2011 00:40 UTC
Most likely this will fail when there are some USB devices connected during suspend (eg internal bluetooth adapter)- this is not so easy.
Perhaps this will requires some sysfs writes before (or instead of), like /sys/bus/usb/device/usb*/remove.

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by joanna on 24 Jul 2011 11:21 UTC
It doesn't fail for my usbvm, even though it has a about half a dozen various USB devices connected:

Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 006: ID 0489:e00f Foxconn / Hon Hai 
Bus 001 Device 005: ID 05c6:9225 Qualcomm, Inc. Sony Gobi 2000 Wireless Modem
Bus 001 Device 004: ID 05ca:18b7 Ricoh Co., Ltd 
Bus 001 Device 003: ID 147e:1001 Upek 
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I've been using this setup (with ehci_hcd auto-removing before suspend and modprobe after) for more than a week and it seems to be working fine...

Member

marmarek commented Mar 8, 2015

Comment by joanna on 24 Jul 2011 11:21 UTC
It doesn't fail for my usbvm, even though it has a about half a dozen various USB devices connected:

Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 006: ID 0489:e00f Foxconn / Hon Hai 
Bus 001 Device 005: ID 05c6:9225 Qualcomm, Inc. Sony Gobi 2000 Wireless Modem
Bus 001 Device 004: ID 05ca:18b7 Ricoh Co., Ltd 
Bus 001 Device 003: ID 147e:1001 Upek 
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I've been using this setup (with ehci_hcd auto-removing before suspend and modprobe after) for more than a week and it seems to be working fine...

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Modified by joanna on 30 Jul 2011 09:17 UTC

Member

marmarek commented Mar 8, 2015

Modified by joanna on 30 Jul 2011 09:17 UTC

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by joanna on 30 Jul 2011 10:10 UTC
Implemented:
http://git.qubes-os.org/?p=joanna/core.git;a=commitdiff;h=7a12cbd0e8c8527fd5bbc7c734c664c7864465b6

In the worst case (i.e. if it was not possible to cleanly rmmod this module) this will have no effect (as we don't use -f option for rmmod, not && after rmmod).

Member

marmarek commented Mar 8, 2015

Comment by joanna on 30 Jul 2011 10:10 UTC
Implemented:
http://git.qubes-os.org/?p=joanna/core.git;a=commitdiff;h=7a12cbd0e8c8527fd5bbc7c734c664c7864465b6

In the worst case (i.e. if it was not possible to cleanly rmmod this module) this will have no effect (as we don't use -f option for rmmod, not && after rmmod).

@marmarek marmarek closed this Mar 8, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment