Re: Stack panic with em driver unload
On 4/6/07, Tai-hwa Liang [EMAIL PROTECTED] 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stack panic with em driver unload
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Stack panic with em driver unload
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. 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 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. 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 :) Cheers, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
