Re: [Suspend-devel] TAP (and TUN?) devices not working after resume - Kernel

This is a discussion on Re: [Suspend-devel] TAP (and TUN?) devices not working after resume - Kernel ; On Monday, 14 of July 2008, James Le Cuirot wrote: > Hi, Hi, > uswsusp works great on my machine except for one thing. I use a TAP > device for QEMU and after resuming from suspend, it doesn't work ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: [Suspend-devel] TAP (and TUN?) devices not working after resume

  1. Re: [Suspend-devel] TAP (and TUN?) devices not working after resume

    On Monday, 14 of July 2008, James Le Cuirot wrote:
    > Hi,


    Hi,

    > uswsusp works great on my machine except for one thing. I use a TAP
    > device for QEMU and after resuming from suspend, it doesn't work
    > anymore until I delete it and recreate it. This is rather annoying
    > because if I have QEMU open, it means I have to close it before
    > recreating the interface and then boot Windows up again. I use OpenVPN
    > to create/delete the interface but I think that's all it does. The rest
    > is done by the kernel. So I'm guessing something's up with the TUN/TAP
    > driver or uswsusp itself. I'm using version 0.8. Sorry if this has
    > already been fixed.


    This is a kernel problem, adding kernel-related CCs.

    Thanks,
    Rafael
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [Suspend-devel] TAP (and TUN?) devices not working after resume

    On Mon, Jul 14, 2008 at 9:12 AM, Rafael J. Wysocki wrote:
    > On Monday, 14 of July 2008, James Le Cuirot wrote:
    >> uswsusp works great on my machine except for one thing. I use a TAP
    >> device for QEMU and after resuming from suspend, it doesn't work
    >> anymore until I delete it and recreate it. This is rather annoying
    >> because if I have QEMU open, it means I have to close it before
    >> recreating the interface and then boot Windows up again. I use OpenVPN
    >> to create/delete the interface but I think that's all it does. The rest
    >> is done by the kernel. So I'm guessing something's up with the TUN/TAP
    >> driver or uswsusp itself. I'm using version 0.8. Sorry if this has
    >> already been fixed.

    >
    > This is a kernel problem, adding kernel-related CCs.


    Oh, hmm. I noticed this about a year ago after a kernel upgrade, and
    threw the below into /etc/acpi/resume.d/91-openvpn.sh to fix the issue
    on resume. It was supposed to be temporary until I could track down
    whether this was a kernel issue or whatnot, but then I sorta, uhm,
    forgot to report it. But yeah, I see the same issue -- after resume,
    the TUN device has disappeared, and openvpn needs to be told to close
    and reopen for it to work again.

    #!/bin/sh
    # poke openvpn to rebuild the tunnel
    if pidof openvpn > /dev/null; then
    killall -SIGHUP openvpn
    fi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. references:in-reply-to:content-type:



    Rafael J. Wysocki wrote:
    > On Monday, 14 of July 2008, James Le Cuirot wrote:
    >> Hi,

    >
    > Hi,
    >
    >> uswsusp works great on my machine except for one thing. I use a TAP
    >> device for QEMU and after resuming from suspend, it doesn't work
    >> anymore until I delete it and recreate it. This is rather annoying
    >> because if I have QEMU open, it means I have to close it before
    >> recreating the interface and then boot Windows up again. I use OpenVPN
    >> to create/delete the interface but I think that's all it does. The rest
    >> is done by the kernel. So I'm guessing something's up with the TUN/TAP
    >> driver or uswsusp itself. I'm using version 0.8. Sorry if this has
    >> already been fixed.

    >
    > This is a kernel problem, adding kernel-related CCs.


    I bet it's flow control related. I've fixed a bug in flow control handling for
    persistent devices recently.
    btw Does it still happen with >= 2.6.26 ?

    I'll play with some test code on my laptop and see if I can reproduce this issue.

    Max
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread