From owner-cvs-all@FreeBSD.ORG Thu Aug 18 20:50:26 2005 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DFC616A420; Thu, 18 Aug 2005 20:50:26 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D5D943D53; Thu, 18 Aug 2005 20:50:25 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[10.50.40.201]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 18 Aug 2005 17:05:26 -0400 From: John Baldwin To: Maxim.Sobolev@portaone.com Date: Thu, 18 Aug 2005 16:23:58 -0400 User-Agent: KMail/1.8 References: <200508181429.j7IET16d038533@repoman.freebsd.org> <200508181538.32988.jhb@FreeBSD.org> <4304E866.3030405@portaone.com> In-Reply-To: <4304E866.3030405@portaone.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508181624.00106.jhb@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/re if_re.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2005 20:50:26 -0000 On Thursday 18 August 2005 03:58 pm, Maxim Sobolev wrote: > John Baldwin wrote: > >>Well, see kern/85005. IMO some generic approach should be worked out and > >>implemented since I think many other network drivers may be affected by > >>the same problem. > > > > I've still yet to see what the real panic is. For one thing, if the > > foo_stop method does its jobs, the ethernet hardware shouldn't be > > generating interrupts. The stop method should be shutting the card down > > (i.e. turning off the receiver and transmitter for example). Is your > > ethernet driver sharing an interrupt with another device and the other > > device is > > Yes, this is the case here. It shares interrupt with IDE controller. > Panic happens in the re_rxeof() when the driver tries to dereference > sc->rl_ldata.rl_rx_mbuf[i], which has already been deallocated in the > re_stop(). Ok. > > interrupting? In that case, the ethernet driver would have the same > > panic if you did an 'ifconfig foo0 down' and then the other device > > interrupted. So, I > > No, I don't think it would since 'ifconfig foo0 down' resets IFF_UPP. Ah, yes. > > think clearing IFF_UPP in foo_shutdown() is wrong. foo_stop() should > > really be sufficient, and foo_intr() should be able to handle a spurious > > interrupt while the interface is stopped without panicing since it > > already needs to do so to handle the shared interrupt case. > > Apparently it doesn't handle it, which has been probably masked by the > IFF_UPP check in the re_intr(), so that this problem only happened at > shutdown, when IFF_UPP isn't cleared after re_stop(). Right. I think the better fix is for the driver to check the flag it manages and knows about (IFF_DRV_RUNNING) rather than IFF_UP in its interrupt handler and to revert the change to re_shutdown(). The vr(4) driver should probably be similarly fixed (check RUNNING in interrupt handler and just call stop in its shutdown method). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org