current panics when Netgear WG511T ejected
Bruce M. Simpson
bms at FreeBSD.org
Tue Mar 27 00:41:55 UTC 2007
Tom Uffner wrote:
>
> slightly different this time, but it still panics. seems to be trying
> to delete nonexistent addresses. should it even be here? i don't have
> any multicast addrs defined, just one dhcp-assigned unicast addr.
Yup, it should be there.
The IP stack will always join 224.0.0.1, this is standards compliant
behaviour. Even if you have no multicast addresses explicitly configured
by yourself or any application, the multicast code is always used on any
system configured with INET.
I believe this new patch should fix your panic. Because the hardware is
being ejected, the netinet part of the stack won't see the detach first,
but net will, and this is where the panic is happening.
In this particular case, net is doing the cleanup because of the
unexpected detach. It looks like it is the ll_ifma which is causing
problems. The problem with ll_ifma is that it is also linked into the
if_multiaddrs tailq; we must link AF_LINK addresses in this tailq or
things like joining a link-layer group alone will not work. As such it
will get seen twice by the same function but in a different role.
Previously FreeBSD would just leak memory instead of panicking in
situations like this. I rewrote this code to null out the ifp's when
ifnet was detached, so that netinet could detect the detach of the
underlying layer, and not try to reenter the net code improperly; this
was particularly important to avoid bad situations with locking. If the
interface needs Giant, the locking is particularly nasty.
Regards,
BMS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: if.c.diff
Type: text/x-patch
Size: 1123 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20070327/779e27c2/if.c.bin
More information about the freebsd-current
mailing list