Two other recent reports are:
1. Buggy applications that hold packets in their input queue forever,
and/or netfilters. The socket buffer's contain a reference for
packets in flight.
that may be it, but I am not sure which queue you are talking about,
but there is an application that is using the netfiler ip_queue to
queue packets to user space. in this application, these packets can
be held in user space for extended periods of time (up to 30/60
seconds), and then they are either dropped or released. Could this
possibly be creating a problem?
I don't believe that the system is using any of the VLAN code.
I have found an appearant leak of a route object, which holds a
reference
to a device. I reproduced in both 2.6.11 and 2.6.13 using 802.1Q
VLANs.
I have a patch that will print out the place of the leaked reference
against 2.6.13.
http://www.candelatech.com/oss/rfcnt.patch
Enable the feature in the Networking section of Kconfig.
Ben, i will incorporate this patch and let you know if i turn up any
results.
thanks,
--robert
On Aug 31, 2005, at 9:37 PM, Stephen Hemminger wrote:
On Wed, 31 Aug 2005 19:04:01 -0700
Robert Scott <[EMAIL PROTECTED]> wrote:
Hello,
I know that this bug has been discussed before at length on this
mailing list, but previous post seemed to indicate that it was fixed
before kernel 2.6.12. I am still seeing this occasionally in kernel
2.6.12.3. The system is running knoppix, and IPV6 is not compiled
into the kernel(other posts mentioned numerous problems with the IPV6
code). But every so often, when bringing down the bridge (it doesn't
happen every time), the process hangs, and the following message
appears in dmesg repeatedly:
'unregister_netdevice: waiting for br0 to become free. Usage count
= 1'
None of the processes involved can be killed, and an attempt to run
an ifconfig results in a process that is also waiting forever. At
this point the box must be rebooted forcefully.
Two questions.
1. In a previous post, someone mentioned one solution was to
commenting out the check that is hanging in the kernel. Does this
check preventing something terrible from happening(i assumed that it
does), or is it safe to remove it
Really bad idea, because if the thing that is holding the reference
like packets stuck in some dead queue, ever get processed the kernel
will die.
2. Any ideas of something to try in order to make this repeatable?
Two other recent reports are:
1. Buggy applications that hold packets in their input queue forever,
and/or netfilters. The socket buffer's contain a reference for
packets in flight.
2. The VLAN code had a number of reference bugs, if you look through
recent netdev mailing list you will see the discussion.
_______________________________________________
Bridge mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/bridge
