6.1 kernel panic

[Steven Hartland]

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 at multiplay.co.uk.