From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 19:52:01 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BBFB916A404 for ; Mon, 9 Apr 2007 19:52:01 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.235]) by mx1.freebsd.org (Postfix) with ESMTP id 2F92413C46A for ; Mon, 9 Apr 2007 19:52:01 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so1155815nza for ; Mon, 09 Apr 2007 12:52:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IjclXNn8IOy8eOPwuPL0HFR+dbT3xTuNtSfOqo8C0XnfhfufVAWf15GW119vVqEh5O0Co2OGdZDQ3/yczOFvLWcVsFSZeCWonsNI2BWd7dKYaC6ZwLjvmkvFsdKK1PcYDFKqtnDVIEeezDJt4GaKp3JAvKq3VDVRAclMDviuxIQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=m+Ii9kWW/IwJTYyDU2PEOcjs5oL9MQQT1PsjnJRCxm+QGipAIoDk8LMSrn5jJgrbIDWi6IibLHMg5pAtPMySY0GuwDqn9cS/oy7eIBfd0oAux8VTpAKfHgSFhVEJKbojl/B+cb74T+g5Umb8F6JOxC1OJrvxhBmGWYUNxJQRE7M= Received: by 10.115.78.1 with SMTP id f1mr2450740wal.1176148319618; Mon, 09 Apr 2007 12:51:59 -0700 (PDT) Received: by 10.114.103.15 with HTTP; Mon, 9 Apr 2007 12:51:53 -0700 (PDT) Message-ID: <2a41acea0704091251q38683a1byce7e1fe2deb6bbf2@mail.gmail.com> Date: Mon, 9 Apr 2007 12:51:53 -0700 From: "Jack Vogel" To: "Tai-hwa Liang" In-Reply-To: <0704071047341.19686@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0704051434p2b8c5902x868d0a5d6510aa01@mail.gmail.com> <0704071047341.19686@www.mmlab.cse.yzu.edu.tw> Cc: freebsd-net , freebsd-current , freebsd-stable@freebsd.org Subject: Re: Stack panic with em driver unload X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Apr 2007 19:52:01 -0000 On 4/6/07, Tai-hwa Liang wrote: > 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. > I have learned what causes it, at least in our test group's setup... They have an entry in /etc/rc.conf for the device like: ifconfig_emX="addr netmask" And then the script they run assigns emX a DIFFERENT address, thats why you get into the multicast code and then hit the panic. I still would like to see the panic not happen, but to avoid it just dont go assigning different addresses :) Cheers, Jack