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

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

[Rafael J. Wysocki]

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

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

[Rafael J. Wysocki]

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

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

[Ray Lee]

On Mon, Jul 14, 2008 at 9:12 AM, Rafael J. Wysocki <rjw@sisk.pl> 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

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

On Mon, Jul 14, 2008 at 9:12 AM, Rafael J. Wysocki <rjw@sisk.pl> 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

Re: TAP (and TUN?) devices not working after resume

[Ray Lee]

On Mon, Jul 14, 2008 at 9:12 AM, Rafael J. Wysocki <rjw@sisk.pl> 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

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

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

[Max Krasnyansky]

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

Re: TAP (and TUN?) devices not working after resume

[Max Krasnyansky]

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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

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

[James Le Cuirot]

On Thu, 24 Jul 2008 20:50:32 -0700
Max Krasnyansky <maxk@qualcomm.com> wrote:

> > On Monday, 14 of July 2008, James Le Cuirot wrote:  
> >>
> >> 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.  
> 
> 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

Sorry about the crazy delay here, I didn't need to use QEMU for ages
and I don't like firing up Windows unless I have too. :D I'm not sure
about 2.6.26 but this appears to be fixed in 2.6.27.

Thanks,
James

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

[James Le Cuirot]

On Thu, 24 Jul 2008 20:50:32 -0700
Max Krasnyansky <maxk@qualcomm.com> wrote:

> > On Monday, 14 of July 2008, James Le Cuirot wrote:  
> >>
> >> 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.  
> 
> 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

Sorry about the crazy delay here, I didn't need to use QEMU for ages
and I don't like firing up Windows unless I have too. :D I'm not sure
about 2.6.26 but this appears to be fixed in 2.6.27.

Thanks,
James

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

[Max Krasnyansky]

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