Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 Oct 2000 09:51:44 +0100 (BST)
From:      Doug Rabson <dfr@nlsystems.com>
To:        Andrew Gallatin <gallatin@cs.duke.edu>
Cc:        Kenjiro Cho <kjc@csl.sony.co.jp>, freebsd-alpha@FreeBSD.ORG, core@kame.net
Subject:   Re: size problems with INVARIANTS/DIAGNOSTIC -current kernels
Message-ID:  <Pine.BSF.4.21.0010060950060.94692-100000@salmon.nlsystems.com>
In-Reply-To: <14812.37571.725840.45245@grasshopper.cs.duke.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 5 Oct 2000, Andrew Gallatin wrote:

> 
> Doug Rabson writes:
>  > On Wed, 4 Oct 2000, Andrew Gallatin wrote:
>  > 
>  > >  > possibly something is wrong in the loader?
>  > >  > 
>  > > 
>  > > 
>  > > If so, the breakage has not happened recently.  I'm seeing this with a
>  > > 'loader' from late august, a netboot from late august & a netboot
>  > > that's over 1 year old.
>  > > 
>  > > Bear in mind that we seem to run just fine until the first time we
>  > > attempt to call a function from a stack created for us by the
>  > > palcode.    However, that same function is callable when not running
>  > > in an interrupt/trap/etc palcode-created context.
>  > > 
>  > > I've "proved" this to myself by making sure that trap() is actually
>  > > callable from the mainline kernel code (eg, not running out XentMM).
>  > > I put a call to trap() in kern_malloc() & I put a call to printtrap()
>  > > at the top of trap.  I see trap being called from kern_malloc, but
>  > > when its called by XentMM, random stuff happens.
>  > 
>  > Bizarre. We are running on our own stack before mi_startup is
>  > called() which should be before anything substantial is printed. I wonder
>  > if somehow the ksp value in the context has been corrupted.
> 
> Any ideas on how to debug this further?  I'm at my wits end here..
> 
> In case its of any use, here's what the registers look like after one
> of these wacky crashes:

Clearly something bad is happening and we are taking a trap, then fielding
it badly. You could try inserting 'call_pal halt' instructions in XentMM
so that we can see what the state looks like on the first fault.

-- 
Doug Rabson				Mail:  dfr@nlsystems.com
					Phone: +44 20 8348 6160




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0010060950060.94692-100000>