Re: vlan panic in -CURRENT

On Sat, Feb 07, 2004 at 02:51:17AM -0600, Kevin Day wrote:
> 
> On Feb 6, 2004, at 5:50 PM, SUZUKI Shinsuke wrote:
> >
> >I can reproduce the problem, and here's the trace:
> >	  if_up->if_route->in6_if_up->in6_ifattach->in6_ifattach_link
> >	->in6_update_ifa->in6_addmulti->if_addmulti->vlan_ioctl
> >	->vlan_setmulti->if_delmulti->fxp_ioctl->fxp_mc_setup
> >
> >The reason of this panic lies in if_fxp.c; fxp's
> >ethernet-multicast-filter is configured before the initializtion of
> >fxp driver.
> >
> >The attached ad-hoc patch fixed the problem, but IMHO much further
> >considerataion is necessary; this happens when vlan is initialized
> >before the initialization of its physical interface, and there might
> >be a similar different bug (in other driver or in different situation).
> >
> >So could anyone see to it?
> >#I'm afraid I cannot, because I'm not a device-driver expert...
> >
> 
> Thanks a lot for tracking this down, I spent a few hours trying to 
> reproduce it and couldn't before I discovered something slightly odd. 
> This only seems to cause a panic if the fxp card has never been brought 
> up since power on. If I "ifconfig fxp0 up" then warm-reboot, I can't 
> make it crash. If I actually kill the power then try bringing up the 
> vlan without bringing fxp0 up first, it will crash. That took a VERY 
> long time to track down what was happening, but i've pretty much 
> confirmed that's what is happening for me. Kinda strange, but I suppose 
> I can understand what's happening.

While there probably is a legitimate bug in fxp0, I think we should
probably actually change the behavior of bonded interfaces like these
abit.  I haven't fully thought it through, but it seems that there's no
point in bringing a vlan up if its parent is down.  In an ideal world,
we might want to put it in an "I'd like to be up, but I can't be yet"
state that could cause it to go up when the interface goes up.  How
exactly that would work, I'm not sure.

One idea I've had would be a way for iterfaces to register to recieve
events related to other intefaces and respond accordingly.  On example
of this would be that it would almost certaintly make sense to destroy
vlans associated with an interface when the interface is removed.  This
could also be used to cause vlans to go up and down when their parents
do.  It would also allow fec and other multiplexing intefaces to respond
to events from their children asyncronously rather then relying on their
current polling stratigy.  Does this sound like a reasionable idea, or
are there massive pitfalls I've missed?

Hmm, now that I think about it, we might be able to/want to tie this
into the eventual devd notification framework for interface events.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4