From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 22:57:00 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7B5916A418; Sun, 29 Jul 2007 22:57:00 +0000 (UTC) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (unknown [IPv6:2001:5a8:4:2140:21b:fcff:fe24:feef]) by mx1.freebsd.org (Postfix) with ESMTP id B68E613C457; Sun, 29 Jul 2007 22:57:00 +0000 (UTC) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.14.1/8.14.1) with ESMTP id l6TMv0OI054580; Sun, 29 Jul 2007 15:57:00 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.14.1/8.14.1/Submit) id l6TMv0qv054579; Sun, 29 Jul 2007 15:57:00 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: freebsd-current@freebsd.org Date: Sun, 29 Jul 2007 15:57:00 -0700 User-Agent: KMail/1.9.6 References: <20070721174631.S561@10.0.0.1> <20070727133342.GA12179@rulez.sk> <200707291552.57528.peter@wemm.org> In-Reply-To: <200707291552.57528.peter@wemm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707291557.00283.peter@wemm.org> Cc: Milos Vyletel , current@freebsd.org, Kris Kennaway Subject: Re: ULE status, invalid load, buildkernel times. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2007 22:57:01 -0000 On Sunday 29 July 2007, Peter Wemm wrote: > On Friday 27 July 2007, Milos Vyletel wrote: > > On Fri, Jul 27, 2007 at 09:26:40AM -0400, Kris Kennaway wrote: > > > On Fri, Jul 27, 2007 at 09:48:32AM +0200, Milos Vyletel wrote: > > > > On Thu, Jul 26, 2007 at 06:06:20PM -0700, Peter Wemm wrote: > > > > > The other option is to find the kernel.debug for this crash, > > > > > and do this: > > > > > kgdb kernel.debug > > > > > gdb> l *0xffffffff8033953c > > > > > This will tell us the file and line number that the crash > > > > > happened in. There is no need to reboot for this unless you > > > > > no longer have a crashing kernel. > > > > > > > > I've played with this a little while, and after turning > > > > INVARIANTS on, it paniced in lapic_ipi_raw() on the > > > > KASSERT(lapic != NULL, ("%s called too early", __func__)); > > > > > > > > so I assume, that this function was called before lapic_init(), > > > > where lapic is initialized, which is wrong. > > > > > > > > It was clean current kernel with no other patches, now I don't > > > > have local access to that machine so I can test it in few days. > > > > > > > > btw. how can one get trace in text form, I mean syslog stop > > > > after panic and all I got logged is that it paniced. Anything I > > > > type in db> is lost. I know that this can be done by remote > > > > gdb, but unfortunatelly this isn't possible. > > > > > > If you trigger a dump (call doadump) then some amount of the DDB > > > session will usually be saved with the dump and displayed by > > > kgdb. > > > > Yes, I forgot about that. I have zfs swap partition and I can't > > configure my dumpdev. Have anyone succesfully acomplish this? > > Please abandon the original patch and try this one: Whoa!!!! I may have crossed threads here. No, do NOT abandon Jeff's patch. I was talking about: http://rulez.sk/~mv/cpu.patch - revert that one and try the one just below. Just to be clear. :) > http://people.freebsd.org/~peter/topology.diff > > This should fix it once and for all. I have tested it on amd64. I > have compile tested on i386 (an old laptop), but not booted it on an > i386 smp box - I dont have one. > > As such, I'd very much appreciate any confirmation from i386 users > that it works. Both from HTT and non-HTT users. Please check that > sysctl kern.sched.topology is right. On an Athlon64 X2 or dual-core > opteron, it should be "0". A HTT p4 or xeon should be non-zero. It > should be the same in both i386 and amd64 mode. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5