[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ULE status, invalid load, buildkernel times.
- To: freebsd-current_(_at_)_freebsd_(_dot_)_org
- Subject: Re: ULE status, invalid load, buildkernel times.
- From: Peter Wemm <peter_(_at_)_wemm_(_dot_)_org>
- Date: Sun, 29 Jul 2007 15:57:00 -0700
- Cc: Milos Vyletel <mv_(_at_)_rulez_(_dot_)_sk>, current_(_at_)_freebsd_(_dot_)_org, Kris Kennaway <kris_(_at_)_obsecurity_(_dot_)_org>
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. :)
> 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_(_at_)_wemm_(_dot_)_org; peter_(_at_)_FreeBSD_(_dot_)_org; peter_(_at_)_yahoo-inc_(_dot_)_com
"All of this is for nothing if we don't go to the stars" - JMS/B5
freebsd-current_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe_(_at_)_freebsd_(_dot_)_org"