Date: Fri, 22 Apr 2011 20:08:41 -0400 From: Andrew Boyer <aboyer@averesystems.com> To: Steven Hartland <killing@multiplay.co.uk> Cc: freebsd-net@freebsd.org, Jack Vogel <jfvogel@gmail.com>, "Vogel, Jack" <jack.vogel@intel.com> Subject: Re: Intel ix (X520) disconnects when manipulating ips? Message-ID: <036FCFE4-98BA-4B90-A060-4597B68A3596@averesystems.com> In-Reply-To: <A38BF553D0DF4B9385E88EBB2CEDC103@multiplay.co.uk> References: <4E85F36598CB480AA8B9706881573CB9@multiplay.co.uk><521514204B99427691043FF127B6E841@multiplay.co.uk><BANLkTim8AYL4q63QqRasMm_s9sQ7etBW6g@mail.gmail.com><EFEE51362EF946398B49940E7B869F52@multiplay.co.uk><BANLkTimJpU119K=4-SD56WMBycW08GhkBA@mail.gmail.com> <BANLkTimJX5HPOnX=3hqf0Y=_n-Aqc4UoUg@mail.gmail.com> <A38BF553D0DF4B9385E88EBB2CEDC103@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Steve and Jack, You need to handle the SIOCSIFADDR ioctl or it gets passed up the stack = to ether_ioctl(). When it goes up the interface gets reset. See the = comments in em_ioctl() and igb_ioctl(). We fixed this in ixgbe in our internal tree and it seems to work fine = with 82598 and 82599. You also need to include opt_inet.h for the INET = #define to be valid. -Andrew On Apr 22, 2011, at 7:06 PM, Steven Hartland wrote: > Just double checked on igb1 on the same machine, adding an alias = causes > no loss in network from the primary or existing ip aliases for the = nic. >=20 > So this should be eliminating most variables except the driver? >=20 > Regards > Steve >=20 > ----- Original Message ----- From: "Jack Vogel" <jfvogel@gmail.com> > To: "Steven Hartland" <killing@multiplay.co.uk> > Cc: <freebsd-net@freebsd.org>; "Vogel, Jack" <jack.vogel@intel.com> > Sent: Friday, April 22, 2011 11:35 PM > Subject: Re: Intel ix (X520) disconnects when manipulating ips? >=20 >=20 >> OK, did some testing, this re-init with link transition will happen = on both >> the 1G >> drivers as well as ixgbe, its due to the stack/ioctl behavior when = you do >> the >> ifconfig. >> So, what are you comparing this to that DOESN'T do this?? If this = were to >> be kept from happening I'm not sure where the responsible code would = be >> but I'm pretty sure its not in the driver :) >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This e.mail is private and confidential between Multiplay (UK) Ltd. = and the person or entity to whom it is addressed. In the event of = misdirection, the recipient is prohibited from using, copying, printing = or otherwise disseminating it or any information contained in it.=20 > In the event of misdirection, illegible or incomplete transmission = please telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -------------------------------------------------- Andrew Boyer aboyer@averesystems.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?036FCFE4-98BA-4B90-A060-4597B68A3596>