Date: Wed, 16 Jul 2008 17:00:43 +0200 From: Kris Kennaway <kris@FreeBSD.org> To: John Sullivan <john@basicnets.co.uk> Cc: freebsd-stable@freebsd.org, 'Michael Grant' <mgrant@grant.org> Subject: Re: Fresh 7.0 Install: Fatal Trap 12 panic when put under load Message-ID: <487E0D1B.2060902@FreeBSD.org> In-Reply-To: <BF6724CD748744908D602889CCF119F1@emea.hubersuhner.net> References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> <20080716031640.7DC744500E@ptavv.es.net> <A6F1ACCEE35A4BC49FC9DFA561ED1131@emea.hubersuhner.net> <62b856460807160743v3fce951eg1b2bd9e50a35ba1d@mail.gmail.com> <BF6724CD748744908D602889CCF119F1@emea.hubersuhner.net>
index | next in thread | previous in thread | raw e-mail
John Sullivan wrote: > >> John, a question, how is swap set up on your system? I was >> swapping to a file (a memory disk device /dev/md0). I was >> doing this because for some reason lost in ancient history, >> this machine was not set up with a real swap partition. >> Hence, no crash dump. > > Swap is a partition on the 1st disk. > >> Last night I repartitioned a second disk, set up a real swap >> partition and now I'm currently waiting for this to happen >> again so I can get a crash dump. > > I will try creating a swap partition on my second drive to see if that improves things ... I am able to cause a panic "on demand" > but a crash dump is rarely written (presumably because the system believes the device is not accessible?). I must have crashed it > 10-20 times now with various corruptions of the panic screen - once it had blue text with "trap 12 trap 12" all over the screen, I > liked that one ;-). > > I did manage to complete a "make index" while the background FSCK was running, once it had finished, performing the same task caused > a panic locking the machine up again with no crash dump. OK, the first thing to do is disable bg fsck, then force a full fsck of all filesystems. bg fsck does a poor job of fixing arbitrary filesystem corruption (it's not designed to do so, in fact), and you can get into a situation where corrupted filesystems cause further panics. Removing KDB_UNATTENDED from your kernel will allow you to interact with the debugger and obtain backtraces etc, which is useful when dumps are not being saved. Krishome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?487E0D1B.2060902>