Date: Sat, 7 Apr 2007 11:05:00 +0800 (CST) From: Tai-hwa Liang <avatar@mmlab.cse.yzu.edu.tw> To: Jack Vogel <jfvogel@gmail.com> Cc: freebsd-net <freebsd-net@freebsd.org>, freebsd-current <freebsd-current@freebsd.org>, freebsd-stable@freebsd.org Subject: Re: Stack panic with em driver unload Message-ID: <0704071047341.19686@www.mmlab.cse.yzu.edu.tw> In-Reply-To: <2a41acea0704051434p2b8c5902x868d0a5d6510aa01@mail.gmail.com> References: <2a41acea0704051434p2b8c5902x868d0a5d6510aa01@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0704071047341.19686>