Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 20 May 2017 00:24:50 -0500
From:      Justin Hibbits <jhibbits@freebsd.org>
To:        Mark Millard <markmi@dsl-only.net>
Cc:        FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Subject:   Re: FYI: powerpc EXC_LAST==0x2f00 vs. EXC_DEBUG ==0x2f10 and such?
Message-ID:  <CAHSQbTDfL89Xu1VVSxxUo=B-ubJWOsHyFMvFbsf46%2BBheMDq_Q@mail.gmail.com>
In-Reply-To: <0BC58DBC-AC9B-46F8-8F3A-1AEB90622BC4@dsl-only.net>
References:  <0BC58DBC-AC9B-46F8-8F3A-1AEB90622BC4@dsl-only.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, May 16, 2017, Mark Millard <markmi@dsl-only.net> wrote:

> [Context:
>
> I'm having problems with production-style kernel builds
> for TARGET_ARCH=powerpc (used an old PowerMac G5 so-called
> "Quad Core") getting occasional panics that involve
> oddities like:
>
> frame->exc == 0x903a64e
>
> in the fatal kernel trap information on the console
> display.
>
> I'm not claiming the below is related but while looking
> around to figure out how to investigate I ran into
> what I report below. (The first 2 are from a block of
> 4xx / 85xx EXC_<?>'s).
> ]
>
>
> From /usr/src/sys/powerpc/include/trap.h :
>
> #define EXC_DEBUG       0x2f10          /* Debug trap */
> #define EXC_VECAST_E    0x2f20          /* Altivec Assist (Book-E) */
>
> #define EXC_LAST        0x2f00          /* Last possible exception vector
> */
>
> #define EXC_AST         0x3000          /* Fake AST vector */
>
> /* Trap was in user mode */
> #define EXC_USER        0x10000
>
> And also:
>
> /usr/src/sys/powerpc/ofw/ofw_machdep.c:char
>  save_trap_init[0x2f00];          /* EXC_LAST */
> /usr/src/sys/powerpc/ofw/ofw_machdep.c:char
>  save_trap_of[0x2f00];            /* EXC_LAST */
>
> /usr/src/sys/powerpc/include/profile.h:#define  __PROFILE_VECTOR_TOP
> (EXC_LAST + 0x100)
>
> These makes it look like EXC_LAST and some literal
> 0x2f00's might be insufficient for some contexts.
>

Nope EXC_LAST is correct as-is.  It's the last possible exception vector
for AIM, as that uses physical pages at those addresses for the exception
vectors.  Anything above EXC_LAST is an artificial exception.  Now, it does
look odd, so I should move the EXC_DEBUG and EXC_VECAST_E down below the
EXC_LAST for sorting purposes.

- Justin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHSQbTDfL89Xu1VVSxxUo=B-ubJWOsHyFMvFbsf46%2BBheMDq_Q>