Subject: Re: Followup: MCHK exception in -current with MMU off
To: Tim Kelly <email@example.com>
From: Matt Thomas <firstname.lastname@example.org>
Date: 04/11/2005 04:08:43
Tim Kelly wrote:
> At 12:28 AM -0400 4/11/05, Nathan J. Williams wrote:
>>I don't belive this is correct. As I mentioned, I added a simple
>>printf() to vzeropage() that printed out both the pa it's trying to
>>zero and the address of the pa variable - essentially, the location of
>>the stack at that point. Here's some output:
> Did you run any tests with Altivec not defined? We did, and found an additional
>>Your analysis is flawed because the set of registers you see in DDB
>>after a panic() reflects their state when panic() is called, not when
>>the fatal trap happens. Stick a printf of frame->fixreg before
>>the panic("trap") in trap.c to see what I mean.
> Calls into panic mucks registers, such that ddb can't restore them? That's
> real useful for debugging. This needs to be filed as a PR. Gees, even
> MacsBug from eight years ago wasn't this poor.
> Beyond the few registers that are used for panic's output strings, why
> would r9 get mucked before it could be recorded? That's really poor.
You have to fetch the registers from the trapframe which the address of
which ddb prints for you
0xd521a900: kernel MCHK trap by vzeropage+0x88: srr1=0x2041020
r1=0xd521a9c0 cr=0x40424088 xer=0 ctr=0x2927dc
In the above case, register 0-31 are at 0xd521a908 starting with
register 0. Look at <powerpc/frame.h> to see the layout of a
Matt Thomas email: email@example.com
3am Software Foundry www: http://3am-software.com/bio/matt/
Cupertino, CA disclaimer: I avow all knowledge of this message.