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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
