Date: Mon, 10 Jul 2006 00:25:26 +0100 From: "Steven Hartland" <killing@multiplay.co.uk> To: <freebsd-hackers@freebsd.org> Subject: Re: 6.1 kernel panic Message-ID: <001401c6a3ae$f9a142d0$b3db87d4@multiplay.co.uk> References: <000f01c6a2fd$51da1470$b3db87d4@multiplay.co.uk> <000b01c6a304$1797aa50$b3db87d4@multiplay.co.uk> <20060709043922.GA9021@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Steve Kargl wrote: > On Sun, Jul 09, 2006 at 04:02:12AM +0100, Steven Hartland wrote: >> >> N.B. Kernel that panic'ed was a pure 6.1-RELEASE SMP I've just >> patched it -p3 to be sure. >> > > Add debugging to your kernel and send a backtrace I've been trying to obtain one but am having no luck. These are the options of added to the kernel as well as enabling dump using dumpon="AUTO" in rc.conf: makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options KTRACE # ktrace(1) support options KDB options DDB options GDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN Unfortunately these are having some very strange results. With the above make -j8 buildworld now hangs using 100 of a processor at the following point: [hang 100%] mkdep -f .depend -a -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/gen-perf.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/hash-table.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/iterator.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/key-list.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/list-node.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/main.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/new.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/options.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/read-line.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/trace.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/vectors.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc [/hang 100%] [top] PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1439 root 1 100 0 4620K 568K CPU1 0 5:02 99.17% cc1plus [/top] I know a dual 1.2Ghz PIII is not quick but after 10mins it should be done with this simple step. Other testing has shown that the crashes may be related to the RAID in 0+1. After the first crash the raid is in critical and from then no matter what I try I cant force the panic. > Please remove this stupid disclaimer. You sent your email to > a public mailing list. Not to mention, the disclaimer has no > legal relevance. Please ignore its added by the mail servers and doesnt even deserve commenting on, like most of the sigs you see on the list. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001401c6a3ae$f9a142d0$b3db87d4>