On May 21, 2012, at 12:41 PM, Mark Felder wrote: > 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! >
You could try switching mpt to MSI. MSI interrupts are never shared. Add this to /boot/device.hints: > hint.mpt.0.msi_enable="1" -Andrew -------------------------------------------------- Andrew Boyer abo...@averesystems.com _______________________________________________ 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"
