From: Pekka Pietikainen <hidden> Date: 2004-09-20 21:24:53
Hiya
When trying to do /etc/init.d/network stop (or reboot) my
fc3test-all-updated-so-kernel-is-2.6.9-rc2-bk5ish, the thing hangs with a
"unregister_netdevice: waiting for tun6to4 to become free. Usage count = 1".
The 6to4 tunnel is over the kernel PPPoE tunnel in case that makes a
difference
What it's trying to do is /sbin/ip tunnel del tun6to4, which
works just fine when run by itself, when looking at /proc/net/dev the
device is no longer there at that point. I think the situation where it
breaks if the ppp device it's running on top of goes down just before. Just
a guess tho :-)
Any obvious explanations or should I poke further?
From: Jeff Garzik <hidden> Date: 2004-09-21 00:59:05
Pekka Pietikainen wrote:
Hiya
When trying to do /etc/init.d/network stop (or reboot) my
fc3test-all-updated-so-kernel-is-2.6.9-rc2-bk5ish, the thing hangs with a
"unregister_netdevice: waiting for tun6to4 to become free. Usage count = 1".
The 6to4 tunnel is over the kernel PPPoE tunnel in case that makes a
difference
I hit this _once_ on my gateway (NAT'ing firewall IPv4, now also IPv6
router).
No idea why it went away, I just assumed a more recent kernel fixed
something.
Jeff
From: Andre Tomt <hidden> Date: 2004-09-21 06:24:47
Jeff Garzik wrote:
I hit this _once_ on my gateway (NAT'ing firewall IPv4, now also IPv6
router).
No idea why it went away, I just assumed a more recent kernel fixed
something.
We've been seeing this all the time on 2.6.8.1 + "critical fixes".
Pretty much anytime a router with tunneling interfaces is taken down for
shutdown or reboot, it hangs spinning waiting for the tunnel devices to
get freed, as ifdown gets run.
It also happens when ifdown'ing them by themselfes.
It's rather annoying, as doing a sysrq-boot is pretty much the only way
out. Not good at all on a router :-)
I'm having some problems getting this reproduced in the lab setup, but I
did get a sysrq-t out of one of the affected production routers:
| Sep 18 00:53:36 ed-gw1 kernel: ip S C0350720 0 1725
1723 (NOTLB)
| Sep 18 00:53:36 ed-gw1: dd02ceb4 00000082 dd678190 c0350720 0000007c
dec44400 dd02c000 e00fddae
| Sep 18 00:53:36 ed-gw1 kernel: e25ac5eb 0000007c c14b36f0
00000199 0f055c16 0000007d dd678338 000351bf
| Sep 18 00:53:36 ed-gw1 kernel: dd02cec8 dec44400 dd02c000
c026cb73 dd02cec8 000351bf e0038d9c c0356380
| Sep 18 00:53:36 ed-gw1 kernel: Call Trace:
| Sep 18 00:53:36 ed-gw1 kernel: [pg0+534273454/1070096384]
addrconf_ifdown+0x3e/0x250 [ipv6]
| Sep 18 00:53:36 ed-gw1 kernel: [schedule_timeout+99/192]
schedule_timeout+0x63/0xc0
| Sep 18 00:53:36 ed-gw1 kernel: [process_timeout+0/16]
process_timeout+0x0/0x10
| Sep 18 00:53:36 ed-gw1 kernel: [netdev_wait_allrefs+85/288]
netdev_wait_allrefs+0x55/0x120
| Sep 18 00:53:36 ed-gw1 kernel: [netdev_run_todo+237/512]
netdev_run_todo+0xed/0x200
| Sep 18 00:53:36 ed-gw1 kernel: [dev_ioctl+438/752] dev_ioctl+0x1b6/0x2f0
| Sep 18 00:53:36 ed-gw1 kernel: [sock_ioctl+544/560]
sock_ioctl+0x220/0x230
| Sep 18 00:53:36 ed-gw1 kernel: [sys_ioctl+201/576] sys_ioctl+0xc9/0x240
| Sep 18 00:53:36 ed-gw1 kernel: [sysenter_past_esp+82/113]
sysenter_past_esp+0x52/0x71
The tunnel is defined like this in /etc/network/interfaces (Debian Sarge)
| auto vid
| iface vid inet6 v4tunnel
| address 2001:730:f:ffff::11
| netmask 126
| endpoint <remote ip>
| local <local ip>
| up /sbin/ip -6 route add 2001:730:f:12::/64 dev vid metric 1
| up /sbin/ip -6 tunnel change vid ttl 255
Next time I'm doing anything I'll be sure I run ifdown in verbose mode,
but my best guess is it failing at "ip tunnel del %iface%"
The kernel does not have NAT and/or connection tracking loaded on this
router. Connection tracking is available as modules, but not loaded. NAT
is not enabled at all.
From: David Woodhouse <dwmw2@infradead.org> Date: 2004-09-22 12:08:52
On Tue, 2004-09-21 at 08:24 +0200, Andre Tomt wrote:
Jeff Garzik wrote:
quoted
I hit this _once_ on my gateway (NAT'ing firewall IPv4, now also IPv6
router).
No idea why it went away, I just assumed a more recent kernel fixed
something.
We've been seeing this all the time on 2.6.8.1 + "critical fixes".
Pretty much anytime a router with tunneling interfaces is taken down for
shutdown or reboot, it hangs spinning waiting for the tunnel devices to
get freed, as ifdown gets run.
It's not just tunnel interfaces. It seems to be related to hot-unplug of
interfaces with live IPv6 addresses. I've seen it on my prism54 card too
on many recent kernels. All I have to do is insert it and remove it a
few times.
--
dwmw2
From: "David S. Miller" <davem@davemloft.net> Date: 2004-09-22 18:15:44
On Wed, 22 Sep 2004 13:08:52 +0100
David Woodhouse [off-list ref] wrote:
On Tue, 2004-09-21 at 08:24 +0200, Andre Tomt wrote:
quoted
Jeff Garzik wrote:
quoted
I hit this _once_ on my gateway (NAT'ing firewall IPv4, now also IPv6
router).
No idea why it went away, I just assumed a more recent kernel fixed
something.
We've been seeing this all the time on 2.6.8.1 + "critical fixes".
Pretty much anytime a router with tunneling interfaces is taken down for
shutdown or reboot, it hangs spinning waiting for the tunnel devices to
get freed, as ifdown gets run.
It's not just tunnel interfaces. It seems to be related to hot-unplug of
interfaces with live IPv6 addresses. I've seen it on my prism54 card too
on many recent kernels. All I have to do is insert it and remove it a
few times.
There is code in ipv6 which takes route references to devices and moves
that reference over to loopback. There might be bugs in that area, and
I would suggest debugging in that area.
In article [off-list ref] (at Wed, 22 Sep 2004 11:15:44 -0700), "David S. Miller" [off-list ref] says:
quoted
It's not just tunnel interfaces. It seems to be related to hot-unplug of
interfaces with live IPv6 addresses. I've seen it on my prism54 card too
on many recent kernels. All I have to do is insert it and remove it a
few times.
There is code in ipv6 which takes route references to devices and moves
that reference over to loopback. There might be bugs in that area, and
I would suggest debugging in that area.