From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 9 23:50:15 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36DB016A4DA for ; Sun, 9 Jul 2006 23:50:15 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 722D643D5A for ; Sun, 9 Jul 2006 23:50:14 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.0.1) with ESMTP id md50002751270.msg for ; Mon, 10 Jul 2006 00:50:17 +0100 Message-ID: <004401c6a3b2$59bad340$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: References: <000f01c6a2fd$51da1470$b3db87d4@multiplay.co.uk><000b01c6a304$1797aa50$b3db87d4@multiplay.co.uk><20060709043922.GA9021@troutmask.apl.washington.edu> <001401c6a3ae$f9a142d0$b3db87d4@multiplay.co.uk> Date: Mon, 10 Jul 2006 00:49:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Processed: multiplay.co.uk, Mon, 10 Jul 2006 00:50:17 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-MDAV-Processed: multiplay.co.uk, Mon, 10 Jul 2006 00:50:19 +0100 Subject: Re: 6.1 kernel panic X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2006 23:50:15 -0000 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@multiplay.co.uk.