From owner-freebsd-net@FreeBSD.ORG Sat Apr 7 03:25:03 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC65F16A401; Sat, 7 Apr 2007 03:25:03 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.freebsd.org (Postfix) with ESMTP id B738313C468; Sat, 7 Apr 2007 03:25:03 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id DC5898C9B50; Sat, 7 Apr 2007 11:05:00 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id C41808C9B4E; Sat, 7 Apr 2007 11:05:00 +0800 (CST) Date: Sat, 7 Apr 2007 11:05:00 +0800 (CST) From: Tai-hwa Liang To: Jack Vogel In-Reply-To: <2a41acea0704051434p2b8c5902x868d0a5d6510aa01@mail.gmail.com> Message-ID: <0704071047341.19686@www.mmlab.cse.yzu.edu.tw> References: <2a41acea0704051434p2b8c5902x868d0a5d6510aa01@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net , freebsd-current , freebsd-stable@freebsd.org Subject: Re: Stack panic with em driver unload X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 03:25:04 -0000 On Thu, 5 Apr 2007, Jack Vogel wrote: > Our test group uses a script that does 100 iterations of > a module load, then bring up all interfaces, and then > unload driver. > > Depending on the system in anything from just a few > iterations to 20 or more, the system will panic. Just a "me too" here. :p > Its doing an em_detach() which calls ether_ifdetach() > which goes to if_detach, in_delmulti_ifp, in_delmulti_locked, > and finally if_delmulti(). > > The panic is always happening on a cmpxchgq instruction > so I assume its the LOCK macro, whats odd is that its > not always the same reason, sometimes one register is > 0 so its a page fault trap, but on other iterations its a > general protection fault because the register is some > big invalid number :) I run into this panic regularly. Apparently the result and condition to trigger the panic are the same as yours: running "while true; do ifconfig xxx up; kldunload if_xxx; done" and ending up with panicking at the cmpxchgq instruction. > I am hardpressed to see this as a driver problem, but > I'm willing to be proven wrong, does someone who > knows the stack code better than me have any insights > or ideas? > > It also appears system dependent, I have a couple > machines I've tried to reproduce in on and have been > unable. I also am told it happens on both amd64 and > i386, but it seems easier to reproduce on the former. Dunno about amd64 since I only have i386 around; however, I'm sure the panic I observed is reproducible on my -CURRENT driver development box. > Lastly, from evidence so far I think this doesnt happen > on CURRENT, but the test group hasnt checked that > only I have and I dont have as much hardware :) FWIW, I usually run into this panic after upgrading to a newer HEAD. Sometimes I can make the aforementioned ifconfig/kldunload script to survive longer by doing a clean rebuild on my driver. -- Cheers, Tai-hwa Liang