From owner-cvs-src@FreeBSD.ORG Thu Aug 18 19:58:39 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81DF016A41F; Thu, 18 Aug 2005 19:58:39 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from www.portaone.com (support.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id B96A143D45; Thu, 18 Aug 2005 19:58:38 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.49] (lesnik.portaone.com [195.140.246.50] (may be forged)) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j7IJwWlb049479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Aug 2005 21:58:33 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <4304E866.3030405@portaone.com> Date: Thu, 18 Aug 2005 22:58:30 +0300 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <200508181429.j7IET16d038533@repoman.freebsd.org> <200508181238.05411.jhb@FreeBSD.org> <4304D6B9.8050603@portaone.com> <200508181538.32988.jhb@FreeBSD.org> In-Reply-To: <200508181538.32988.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-6; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.2/1033/Thu Aug 18 19:52:45 2005 on www.portaone.com X-Virus-Status: Clean X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.0 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on www.portaone.com 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-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Maxim.Sobolev@portaone.com List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2005 19:58:39 -0000 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(). > 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. > 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(). -Maxim