Date: Thu, 31 May 2012 11:57:42 -0400 From: John Baldwin <jhb@freebsd.org> To: Mark Felder <feld@feld.me> Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash Message-ID: <201205311157.42909.jhb@freebsd.org> In-Reply-To: <op.we6hsx0m34t2sn@tech304> References: <op.wbwe9s0k34t2sn@tech304> <201205311048.45813.jhb@freebsd.org> <op.we6hsx0m34t2sn@tech304>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201205311157.42909.jhb>