OK guys I've been talking with another user who can recreate this crash
and the last bit of information we've learned seems to be leaning towards
interrupts/IRQ issues like someone (bz@ perhaps?) suggested.
I'm still trying to test this myself, but the other user was able to
recreate my crash pretty much on demand. The fix was to not use the first
NIC in the VM because it will always share an IRQ with mpt0. Once mpt0 is
on its own the crash does not seem to be reproducible anymore.
Before:
$ vmstat -i
interrupt total rate
irq1: atkbd0 378 0
irq6: fdc0 9 0
irq15: ata1 34 0
irq16: em1 687237 1
irq18: em0 mpt0 319094024 539
cpu0: timer 236770821 400
Total 556552503 940
After:
$ vmstat -i
interrupt total rate
irq1: atkbd0 38 0
irq6: fdc0 9 0
irq15: ata1 34 0
irq16: em1 2811 15
irq17: em2 5 0
cpu0: timer 71013 398
irq256: mpt0 12163 68
Total 86073 483
Is there any other way we can make mpt0 get its own dedicated IRQ without
having to do this? The problem is that it causes us to have to make
rc.conf changes, pf.conf changes, and who knows what other software could
be on these machines that is trying to bind to a specific NIC...
Thanks!
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
