Subject: Re: Followup: MCHK exception in -current with MMU off
To: Tim Kelly <firstname.lastname@example.org>
From: Matt Thomas <email@example.com>
Date: 04/11/2005 09:45:04
Tim Kelly wrote:
> At 4:08 AM -0700 4/11/05, Matt Thomas wrote:
>>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
> And what is the instruction in ddb to switch to this stack frame? Just to
> be clear - panics within traps leave the debugger one (?) stack frame off?
> I'm basing this on the address you list being eight bytes off the address
> listed by ddb.
Sigh. The reason it's 8 bytes off is that there is the standard space
reserved at the start of the frame for the next frame's need to save
the SP (R1) and LR (return address). The trapframe follows immediately
after those 8 bytes.
ddb doesn't the notion of up/down like gdb. All you get is 'x'.
> How many traps have panics as a final result? Or more precisely, how many
> panics are caused as a result of trap?
Literally, *everything* happens due to a trap/execption. The kernel
exists to do userland's bidding. The userland indicates it wants
something to happen via exceptions like system call (SC), data fault
(DSI), instruction fault (ISI), program fault (PGM), etc.
Eventually all panic are indirectly or directly due to exceptions.
The machine check (MCHK) is one of those panic directly due to an
> When I posted my original analysis and stated that it seemed odd to me that
> r9 was in the middle of kernel physical memory, and I asked if anyone had
> any additional information to help isolate this, I was referring to the
> kind of information above. Otherwise I could have seen that r9 was in fact
> not a valid physical address and that the conditions for a MCHK exception
> were being met.
And how is a reader to know that you didn't know that? Until your
reply to Nathan Williams indicated a errant assumption, I assumed
you knew it.
> Gee, this whole scenario sounds so familiar. I do the groundwork for
> resolving the problem, I miss a detail that someone with more knowledge
> than I have checking behind me could have found, except apparently my
> efforts aren't actually reviewed.
This is an volunteer project. No one is obligated to help. Until
you demonstrate a lack of prowess and/or someone has inclination
to help, assume you are your own. It's not a nice assumption but
it's an accurate one.
Matt Thomas email: firstname.lastname@example.org
3am Software Foundry www: http://3am-software.com/bio/matt/
Cupertino, CA disclaimer: I avow all knowledge of this message.