[OLPC New Zealand] [Testing] Testing Summary: 3 December 2011 - Auckland, New Zealand

Tom Parker tom at carrott.org
Mon Dec 5 04:22:32 EST 2011


On Mon, 2011-12-05 at 13:57 +1100, James Cameron wrote:

> > Speak - starts but no speaking and no lips moving. There is a high
> > pitched whine (Tom estimates 10KHz) on clicky keys C1 and then it
> > locked up and stopped updating the display. The other C1 also had no
> > speaking and no lips moving and then locked in the same way. Both are
> > successfully killed using the force quit option if you stop from the
> > frame.
> 
> The estimated 10kHz tone is likely to be aliasing.  See #11334 for
> technical background.  The lockup is unfamiliar, but if automatic power
> management was enabled we know it happens.

Really, automatic power management can lock up just one application? It
appeared like the thread that responds to X events had stopped -- areas
damaged from the frame was not redrawn. Having said that, I'm not sure
it was totally locked -- it might have just been very very very slow.

My experience so far diagnosing locks and poor performance with python
has been poor. With a significant amount of effort, bandwidth,
reconfiguration, and most importantly, time I have been able to do back
traces with gdb. Since yum is barely functional I haven't tried on the
1.75. I'm used to java where you can send a signal and get a thread dump
(at work we even built a profile viewer which takes a series of thread
dumps for offline profiling in production). Is there anything like this
available in python?



More information about the OLPC-NZ mailing list