Re: Followup: MCHK exception in -current with MMU off

[Matt Thomas <matt%3am-software.com@localhost>]

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
> exception.
> 
> 
>>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[9] 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
trapframe.
-- 
Matt Thomas                     email: matt%3am-software.com@localhost
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this message.