6.1 kernel panic

Steven Hartland killing at multiplay.co.uk
Sun Jul 9 23:50:15 UTC 2006


Removing the following fixes the compile hang yet results
in the array going offline with WRITE_DMA errors.
options INVARIANTS
options INVARIANT_SUPPORT
options WITNESS
options WITNESS_SKIPSPIN

I'm rapidly coming to the conclusion there is something quite
broken with driver support for 0+1 on this chipset ( Promise PDC20267 ).

Steven Hartland wrote:
> 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.


================================================
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.



More information about the freebsd-hackers mailing list