Bug 4027 - assertion failed at net/ipv6/addrconf.c, plus halt fails
Summary: assertion failed at net/ipv6/addrconf.c, plus halt fails
Status: CLOSED CODE_FIX
Alias: None
Product: Networking
Classification: Unclassified
Component: IPV6 (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Hideaki YOSHIFUJI
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-01-12 15:38 UTC by John Goerzen
Modified: 2006-12-08 14:42 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.9 & 2.6.10, kernel.org tree
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
2.6.9 config file (25.58 KB, text/plain)
2005-01-12 15:39 UTC, John Goerzen
Details
dmesg log, 2.6.9 (24.34 KB, text/plain)
2005-01-12 15:40 UTC, John Goerzen
Details
2.6.10 dmesg log (24.57 KB, text/plain)
2005-01-12 15:41 UTC, John Goerzen
Details

Description John Goerzen 2005-01-12 15:38:18 UTC
Distribution:
Hardware Environment: Alpha 164LX 21164a 600MHz
Software Environment: Debian unstable
Problem Description:

During bootup, I am getting multiple instances ofitems like this, typically when
a daemon starts up:

Jan 12 17:23:38 erwin kernel: RTNL: assertion failed at net/ipv6/addrconf.c (1992)

Trace shows:

Jan 12 17:23:38 erwin kernel: Trace:
Jan 12 17:23:38 erwin kernel: [sk_free+324/336] sk_free+0x144/0x150
Jan 12 17:23:38 erwin kernel: [inet_release+128/160] inet_release+0x80/0xa0
Jan 12 17:23:38 erwin kernel: [sock_release+172/240] sock_release+0xac/0xf0
Jan 12 17:23:38 erwin kernel: [sock_close+48/112] sock_close+0x30/0x70
Jan 12 17:23:38 erwin kernel: [__fput+412/448] __fput+0x19c/0x1c0
Jan 12 17:23:38 erwin kernel: [fput+72/96] fput+0x48/0x60
Jan 12 17:23:38 erwin kernel: [filp_close+132/240] filp_close+0x84/0xf0
Jan 12 17:23:38 erwin kernel: [close_files+172/224] close_files+0xac/0xe0
Jan 12 17:23:38 erwin kernel: [put_files_struct+84/224] put_files_struct+0x54/0xe0
Jan 12 17:23:39 erwin kernel: [do_exit+508/1424] do_exit+0x1fc/0x590
Jan 12 17:23:39 erwin kernel: [do_group_exit+60/176] do_group_exit+0x3c/0xb0
Jan 12 17:23:39 erwin kernel: [entSys+164/192] entSys+0xa4/0xc0

The system appears to function normally after bootup.  

However, when it comes time to halt the system, I cannot.  It stalls with:

unregister_netdevice: waiting for sit1 to become free.  Usage count = 1

This machine is acting as a firewall.  I have two Ethernet devices in it; one
for the outside and one for the inside.  The outside speaks only IPv4.  Inside
speaks IPv4 and IPv6.  IPv6 is routed to the outside via sit1, using the public
6to4 router address.

I will attach dmesg logs, ksymoops output, configurations, etc.

This behavior was observed on both 2.6.9 and 2.6.10.

Please ask if there is any other information you would need to resolve this
problem.  I am quite happy to provide anything that may be of use.
Comment 1 John Goerzen 2005-01-12 15:39:05 UTC
Created attachment 4378 [details]
2.6.9 config file
Comment 2 John Goerzen 2005-01-12 15:40:25 UTC
Created attachment 4379 [details]
dmesg log, 2.6.9
Comment 3 John Goerzen 2005-01-12 15:41:52 UTC
Created attachment 4380 [details]
2.6.10 dmesg log
Comment 4 John Goerzen 2005-01-12 15:42:28 UTC
ksymoops did not appear to add anything useful to this.  Again, please ask if I
can help with debugging.
Comment 5 Sean Gwizdak 2005-07-05 07:12:52 UTC
I've seen the "halting" occur on a Linux 2.6.11 SMP machine as well, the
following message printed to the console when attempting to reboot:

unregister_netdevice: waiting for sit1 to become free.  Usage count = 1

I do not see the oops though on bootup. I believe this problem can only be
reproduced on certain machines. I see it occur on a dual PIII-550mhz system, but
not on a dual P4 2.4Ghz Xeon. To cause this problem, just enable both sit0 and
sit1, and try to reboot. When it fails on a system, it fails quite reliably.
Comment 6 Adrian Bunk 2006-11-26 08:09:25 UTC
Is this issue still present in kernel 2.6.18?
Comment 7 Hideaki YOSHIFUJI 2006-12-08 14:42:28 UTC
I do think this is acient and it is already fixed.

Note You need to log in before you can comment on or make changes to this bug.