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
On Mon, Jul 14, 2008 at 9:12 AM, Rafael J. Wysocki <[email protected]> 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
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
On Thu, 24 Jul 2008 20:50:32 -0700
Max Krasnyansky <[email protected]> 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