8572E - machine check pin (MCP0)

[Morrison, Tom]

I wrote:
<snip some things>
>> I have an external watchdog timer that is going off - and pulsing
into
>> the MCP0 of the 8572E. I get the printk indicating that the MCP0 went
>> off - the problem is - how do I clear the condition that caused this
>> because my hardware engineer swears that the pulse is ONLY 250ms -
and
>> after resetting several status registers (mcpsumr & rst
>> (because my hardware engineer swears that the pulse is ONLY 250ms
long
>> (and I have a delay after my printk of 250ms)) - so I am pretty sure
>>
>> I am resetting the conditions mcpsumr (also, extra: the rstsr),
>> but after writing mcpsumr - and reading back - it still has
>> the mcp0 bit set?


<snip more>


Trent wrote:


>SRESET# also sets MCP0 and MCP1, maybe that is on?
>I'd also check the EMCP bit in SPRN_HID0 (on core 0 for MCP0).

I think SRESET is a separate signal - and even if it was ON
(which it shouldn't be) - it should show up in the MCPSUMR 
Register (and I am clearing that condition)...

I am getting the first machine check (with an indication that 
the MCP0 is pulled) - I don't think you can get a Machine check without 
SPRN_HID0's EMCP being set? 

The only thing that I am thinking is that I have two edges, and
after returning from the machine check (first time) the ME bit is
NOT enabled, so when the falling edge of that pulse occurs, it 
causes another machine check - which because ME bit is NOT set
it causes a checkstop - and it goes away...

That explains why it hangs for the second machine check - although
it still 'starts' into the machine check handler before dying 
very early in its execution (before it does a full dump of registers)...

very strange stuff here...

Tom