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
>trapframe.

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.

How many traps have panics as a final result? Or more precisely, how many
panics are caused as a result of trap?

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.

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.

Yeah, I get the point.

tim