From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 10:25:18 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF76816A4CE for ; Mon, 8 Dec 2003 10:25:18 -0800 (PST) Received: from gatekeeper.oremut02.us.wh.verio.net (gatekeeper.oremut02.us.wh.verio.net [198.65.168.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E3E743FBF for ; Mon, 8 Dec 2003 10:24:57 -0800 (PST) (envelope-from gritton@orem.verio.net) Received: from guppy.dmz.orem.verio.net (guppy.dmz.orem.verio.net [10.1.1.55]) 83B571E487D for ; Mon, 8 Dec 2003 11:23:38 -0700 (MST) Received: from guppy.dmz.orem.verio.net by guppy.dmz.orem.verio.net; Mon, 8 Dec 2003 11:23:33 -0700 (MST) Received: (from gritton@localhost) by guppy.dmz.orem.verio.net (8.12.9/8.12.6/Submit) id hB8INTVH046787; Mon, 8 Dec 2003 11:23:29 -0700 (MST) Sender: gritton@orem.verio.net From: jamie@gritton.org (James Gritton) To: Jun Kuriyama References: <7m8ylp6pn0.wl@black.imgsrc.co.jp> Date: 08 Dec 2003 11:23:29 -0700 In-Reply-To: Jun Kuriyama's message of "Sun, 07 Dec 2003 16:41:39 +0900" Message-ID: Lines: 44 X-Mailer: Gnus v5.7/Emacs 20.7 cc: Current Subject: Re: dev/em: Link is not up until 2 seconds after "ifconfig up" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2003 18:25:18 -0000 Jun Kuriyama writes: > My experimental 1U box which has em0 and em1 shows following result. > Doing "ifconfig em1 up" after "ifconfig em1 down", link is down 1 or > more seconds. I've had this problem too. You don't really notice it until you're trying to do virtual hosting and bring up in excess of 100 addresses on a box. At 3-4 seconds each, it can make reboots an interminable wait. I've hacked around the wait for adding aliases, but it's still there for the original setup, where a few seconds doesn't bother me. What's happening is every time you add an address, the driver's own ioctl handler calls ether_ioctl, which in turn calls the driver's if_init. I didn't fix the wait in em's if_init, but I did avoid calling it. The hack doesn't break anything in 4.7, but I don't know if that's just luck and something is waiting in the wings. I also don't know what it would do to Current. Anyway, in ether_ioctl, I only call if_init if the interface isn't already set up (as tested by the IFF_RUNNING flag, since ether_ioctl has already set IFF_UP): switch (ifa->ifa_addr->sa_family) { #ifdef INET case AF_INET: + /* Only initialize the interface when it first comes up. + * This works around a seconds-long freeze on the em(4) + * interface when adding virtual addresses. It might also + * do something bad, but it doesn't appear to. + */ + if (!(ifp->if_flags & IFF_RUNNING)) ifp->if_init(ifp->if_softc); /* before arpwhohas */ arp_ifinit(ifp, ifa); break; #endif Yes, this is only for AF_INET addresses, since that's all I care about. And yes, this still leaves the question as to why em hangs in the first place. I kind of have an answer to that, but not a fix. Em has a watchdog timer that runs every two seconds, and sets some current state from the hardware. Apparently, there's no way for the hardware to immediately know what state it's in: I tried shortening the initial invocation of this timer, and if I get much below a second it doesn't work until the next interval. My "doesn't work", I mean I get the same wait as before. - Jamie