> 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 <rbscott@xxxxxxxxxxx> 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. >
