Date: Sat, 7 Feb 2004 12:50:29 -0800 From: Brooks Davis <brooks@one-eyed-alien.net> To: Kevin Day <toasty@dragondata.com> Cc: freebsd-current@freebsd.org Subject: Re: vlan panic in -CURRENT Message-ID: <20040207205028.GA9025@Odin.AC.HMC.Edu> In-Reply-To: <CB1A9D0F-594A-11D8-8CA2-000A95A8A1F2@dragondata.com> References: <356CD0A4-5828-11D8-A138-000A95A8A1F2@dragondata.com> <20040206183306.GA13801@Odin.AC.HMC.Edu> <x7hdy3rcmv.wl%suz@crl.hitachi.co.jp> <CB1A9D0F-594A-11D8-8CA2-000A95A8A1F2@dragondata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 07, 2004 at 02:51:17AM -0600, Kevin Day wrote: >=20 > 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... > > >=20 > Thanks a lot for tracking this down, I spent a few hours trying to=20 > reproduce it and couldn't before I discovered something slightly odd.=20 > This only seems to cause a panic if the fxp card has never been brought= =20 > up since power on. If I "ifconfig fxp0 up" then warm-reboot, I can't=20 > make it crash. If I actually kill the power then try bringing up the=20 > vlan without bringing fxp0 up first, it will crash. That took a VERY=20 > long time to track down what was happening, but i've pretty much=20 > confirmed that's what is happening for me. Kinda strange, but I suppose= =20 > 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 --=20 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 --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAJU+UXY6L6fI4GtQRAoqUAJ4hHQdesBRSPk/mSMHBDzXBXpBASACggw8A jwObp2KtcwZ37ptvm5Trufg= =WaZf -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040207205028.GA9025>