Stack panic with em driver unload

[Tai-hwa Liang]

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