Hey dear lists,
We at OLE Nepal have some trouble with squeak images coming out of XO suspend.
Basically when coming out of suspend, the Squeak process takes up lots of cpu power and can be unresponsive for about a minute on build 703 (other builds not yet tested).
Also we loose sound. Which sometimes comes back after a while. Either on it's own or perhaps because another application is opened. This could be a coincidence though.
Especially the unresponsiveness is a problem, because it messes up the classes. Typically a teacher will explain a concept after which the students will do an activity for a short while. After which they will close the XO again to go on with the rest of the course. The XO's can't stay open because they are to distractive and because they eat battery power, and perhaps take up to much space (the benches these children work at are tiny). Having to either wait for the activity, or restart the image (or XO, whatever the child feels comfortable with) kills the flow, and the children get very impatient.
Any pointers to the cause and/or solutions would be greatly appreciated. I'll add appropriate tickets to trac shortly.
/Ties
On Fri, May 16, 2008 at 1:50 PM, Ties Stuij cjstuij@gmail.com wrote:
Basically when coming out of suspend, the Squeak process takes up lots of cpu power and can be unresponsive for about a minute on build 703 (other builds not yet tested).
What about:
- launch etoys - check its pid - attach to it with strace -p PID and log the output to a file - suspend - resume - check what etoys is doing in that file
Good luck,
Tomeu
Tomeu and all,
At Fri, 16 May 2008 13:53:16 +0200, Tomeu Vizoso wrote:
On Fri, May 16, 2008 at 1:50 PM, Ties Stuij cjstuij@gmail.com wrote:
Basically when coming out of suspend, the Squeak process takes up lots of cpu power and can be unresponsive for about a minute on build 703 (other builds not yet tested).
What about:
- launch etoys
- check its pid
- attach to it with strace -p PID and log the output to a file
- suspend
- resume
- check what etoys is doing in that file
Good luck,
I'm now looking into this, but this may not be an issue with Etoys. I did strace but don't really see any anomaly. (Saw some interesting things, but.)
Suppose I start Pippy and run the "Lines" example, and press the power button to suspend. The laptop suspends and the power LED blinks. But, here is an interesting happens; if I rub the touch pad quickly, or put my four fingers together on the keyboard (at shift, ctrl, tab and `) and slide them over the keyboard to cause a lot of key input (while the laptop is suspended), the the pattern of power LED blinking changes. The LED stays on for a while and turns to off, and come back to on, etc. If I press the power button while the abnormal LED pattern is going, the button press is often ignored. Or, it wakes up one second or such but goes back to sleep. If these things happen, waking up the unit takes time. Etoys doesn't have to be running.
When Etoys is running, but you don't touch the laptop while it is suspended, it doesn't happen (that often).
This is on a G1G1 machine, update.1-708 with the firmware that comes with it. I created a track ticket (#7196).
-- Yoshiki
I forgot to mention one thing. So, Ties, you might be already doing this, but one workaround for the problem is to instruct kids not to touch the keys or touchpad when the unit is suspended...
-- Yoshiki
Suppose I start Pippy and run the "Lines" example, and press the power button to suspend. The laptop suspends and the power LED blinks. But, here is an interesting happens; if I rub the touch pad quickly, or put my four fingers together on the keyboard (at shift, ctrl, tab and `) and slide them over the keyboard to cause a lot of key input (while the laptop is suspended), the the pattern of power LED blinking changes. The LED stays on for a while and turns to off, and come back to on, etc. If I press the power button while the abnormal LED pattern is going, the button press is often ignored. Or, it wakes up one second or such but goes back to sleep. If these things happen, waking up the unit takes time. Etoys doesn't have to be running.
Yes, I've noticed this behavior to. However, we're experiencing other problems I believe. In our case the XO comes out of suspend:The etoys screen comes up, we can get to other activities... however a glance at top reveals that Squeak consumes almost all processing power on the XO.
/Ties
Suppose I start Pippy and run the "Lines" example, and press the power button to suspend. The laptop suspends and the power LED blinks. But, here is an interesting happens; if I rub the touch pad quickly, or put my four fingers together on the keyboard (at shift, ctrl, tab and `) and slide them over the keyboard to cause a lot of key input (while the laptop is suspended), the the pattern of power LED blinking changes. The LED stays on for a while and turns to off, and come back to on, etc. If I press the power button while the abnormal LED pattern is going, the button press is often ignored. Or, it wakes up one second or such but goes back to sleep. If these things happen, waking up the unit takes time. Etoys doesn't have to be running.
Yes, I've noticed this behavior to. However, we're experiencing other problems I believe. In our case the XO comes out of suspend:The etoys screen comes up, we can get to other activities... however a glance at top reveals that Squeak consumes almost all processing power on the XO.
/Ties
Basically when coming out of suspend, the Squeak process takes up lots of cpu power and can be unresponsive for about a minute on build 703 (other builds not yet tested).
Hmm. Interestingly, windows VM has similar problem. If you suspend Windows with Squeak running, resuming takes long time, and you have to "send" a lot of user events by moving mouse a lot.
Also we loose sound. Which sometimes comes back after a while. Either on it's own or perhaps because another application is opened. This could be a coincidence though.
This is bad, too. I wonder a button that calls:
SoundPlayer shutDown. SoundPlayer startUp.
and press it when the symptom occurs resets it or not.
Especially the unresponsiveness is a problem, because it messes up the classes. Typically a teacher will explain a concept after which the students will do an activity for a short while. After which they will close the XO again to go on with the rest of the course. The XO's can't stay open because they are to distractive and because they eat battery power, and perhaps take up to much space (the benches these children work at are tiny). Having to either wait for the activity, or restart the image (or XO, whatever the child feels comfortable with) kills the flow, and the children get very impatient.
This should be fixed, yes. We should try strace'ing Tomeu suggested, and possibly we even should investigated the situation on Windows.
Thank you for reporting.
-- Yoshiki
squeak-dev@lists.squeakfoundation.org
-
Ties Stuij -
Tomeu Vizoso -
Yoshiki Ohshima