Date: Thu, 5 Oct 2000 11:44:09 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Doug Rabson <dfr@nlsystems.com> 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: <14812.37571.725840.45245@grasshopper.cs.duke.edu> In-Reply-To: <Pine.BSF.4.21.0010042320180.94692-100000@salmon.nlsystems.com> References: <14811.11704.600307.685105@grasshopper.cs.duke.edu> <Pine.BSF.4.21.0010042320180.94692-100000@salmon.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>>e pc PC psr: 0 ( PC) FFFFFC00006962A8 >>>e -n 32 r0 gpr: 0 ( R0) 000000000000001C gpr: 1 ( R1) FFFFFC00006B17D8 gpr: 2 ( R2) FFFFFC000068C7E3 gpr: 3 ( R3) 000000000000001C gpr: 4 ( R4) 0000000000000001 gpr: 5 ( R5) FFFFFC0007F15FE8 gpr: 6 ( R6) FFFFFC00006B5258 gpr: 7 ( R7) FFFFFC00006E72A8 gpr: 8 ( R8) FFFFFC00007AA000 gpr: 9 ( R9) FFFFFC00007A9CA0 gpr: A ( R10) 00000000DEADBEEF gpr: B ( R11) 0000000000000001 gpr: C ( R12) 0000000000000000 gpr: D ( R13) 00000000DEADBEEF gpr: E ( R14) 00000000DEADBEEF gpr: F ( R15) 00000000DEADBEEF gpr: 10 ( R16) 00000000DEADBFE7 gpr: 11 ( R17) 0000000000000001 gpr: 12 ( R18) 0000000000000000 gpr: 13 ( R19) 0000000000000002 gpr: 14 ( R20) FFFFFC00007A9B40 gpr: 15 ( R21) 0000000000000008 gpr: 16 ( R22) 000000000000001E gpr: 17 ( R23) FFFFFC0000417584 gpr: 18 ( R24) 000000000000000D gpr: 19 ( R25) 0000000000000010 gpr: 1A ( R26) FFFFFC00005E1FAC gpr: 1B ( R27) FFFFFC00006962A8 gpr: 1C ( R28) FFFFFC00007A9C60 gpr: 1D ( R29) FFFFFC00006D9068 gpr: 1E ( R30) FFFFFC00007A9B40 gpr: 1F ( R31) 0000000000000000 the PC (FFFFFC00006962A8) is in the data segment. The RA is what I would expect: (gdb) l *0xFFFFFC00005E1FAC 0xfffffc00005e1fac is in XentMM (../../alpha/alpha/exception.s:94). 89 PALVECT(XentMM) /* setup frame, save registers */ 90 91 /* a0, a1, & a2 already set up */ 92 ldiq a3, ALPHA_KENTRY_MM 93 mov sp, a4 ; .loc 1 __LINE__ 94 CALL(trap) 95 96 jmp zero, exception_return 97 END(XentMM) 98 The kernel stack pointer seems reasonable (I guess): >>>e sp gpr: 1E ( R30) FFFFFC00007A9B40 <..> fffffc00007190d0 B tc_3000_500_intr fffffc0000719160 A _end fffffffe00000000 A PTmap <..> proc0paddr points to 0xFFFFFC00007A6000 according the the SRM console. Thanks, Drew 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?14812.37571.725840.45245>