The first time I was troubleshooting this problem, I did see a fault
on the 1V supply with roach_monitor.py. I didn't check
roach_monitor.py on the second roach because the problem was so fresh
in our mind we just jumped to the finish line and checked the mosfet
with a meter, then replaced it.
For reference, the part in question is Q13 (FD6675BZ).
Thanks,
Jason
At 09:33 AM 6/19/2012, Jason Manley wrote:
Good sleuthing!
FWIW, roach_monitor.py is supposed to be able to pull the log out of
the Actel Fusion, which should have logged a fault on the 1V rail
before shutting-down the board. This should work independent of PPC
or dmesg states. I'm afraid I have little faith in the Fusion/Xport
combo to reliably catch these issues, but it has helped me a few times.
If it works, it only retrieves the reason for the last shutdown, so
you'll have to plug a laptop into the Xport to query it directly
after it self-shutdown.
Jason
On 19 Jun 2012, at 15:23, John Ford wrote:
> Hi all. We've had a couple of ROACH failures with identical causes.
> Maybe some of you have seen this, but it's worth keeping in mind in case
> you have a problem.
>
> The symptom is that the ROACH would sort of power on, but then turn off
> spontaneously. On one, as soon as the bof was loaded the roach would turn
> off. The other one would come on for a brief few seconds and then turn
> or, or it would cycle on and off. The monitor readout in dmesg gave
> non-sense readings.
>
> In any event, the cause was traced to the +1 volt supply MOSFET switch.
> Replacing that mosfet fixed both roaches. Kudos to Jason Ray for finding
> the problem originally.
>
> John
>
>
>
