On Thursday, May 31, 2012 11:11:11 am Mark Felder wrote: > So when this hang happens, there never is a real panic. It just sits in a > state which I describe as like being in a deadlock. How would I go about > getting a crashdump if it never panics? Is it possible to do the dump over > a network or something because I don't believe it can write through the > controller at all.
You can break into ddb and run 'call doadump'. It should use polled IO, so there is a slight chance of it working. > Also, thank you for the KTR_SCHED tip. This is the type of info I was > looking for. Unfortunately I've only ever seen this crash once on a kernel > with debugging enabled. The machine which is currently prepared to do this > work used to crash a few times a week and now it has 70 days uptime... > however, it is an example of a machine with mpt0 and em0 sharing an IRQ so > I might be able to trigger it using Dane's method. > > $ vmstat -i > interrupt total rate > irq1: atkbd0 392 0 > irq6: fdc0 9 0 > irq14: ata0 34 0 > irq18: em0 mpt0 1189748491 218 > cpu0: timer 2174263198 400 > Total 3364012124 619 > > > I'm doing my best to get you guys the info you need, but this is one heck > of a Heisenbug... Thanks. -- John Baldwin _______________________________________________ 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"
