(In reply to comment #0)
> ACTUAL OUTCOME:
> 100% of the time is in state C0 at 600MHz

According to Igor's summit lightning talk that WILL fry the CPU.  Bumping
severity.

> REPRODUCIBILITY:
> So far once, over the last couple of days.

Do you remember what else the device was doing at the time, particularly
anything audio-related?

I haven't experienced this myself, but I'm running with touchscreen and
keyboard input sounds off (maemo-xinput-sounds still runs though).

Comment 2 Tim Samoff 2009-11-28 06:27:54 UTC

Wish I could add helpful info, but I can't. What I can say is that I'm pretty
sure this has happened to my (pre-production) unit at least 4 times since
having received it. It has _not_ happened (for me) since v41-10, though.

(In reply to comment #1)
> According to Igor's summit lightning talk that WILL fry the CPU.

Actually I think I'm misquoting here.  IIRC the talk said that *forcing* the
CPU to 600MHz (via cpufreq) will fry it, but presumably there is some thermal
management in place and if the system is allowed to it will lower the frequency
when needed.

(In reply to comment #1)


> > 100% of the time is in state C0 at 600MHz
> According to Igor's summit lightning talk that WILL fry the CPU.  Bumping
> severity.

I only ran powertop a few times, so we're talking about a couple of minutes'
worth of samples. I have no idea what the clock speed was during the rest of
the day.


> Do you remember what else the device was doing at the time, particularly
> anything audio-related?

The "time" is a couple of days, so I can't recall a specific incident. I
normally use mediaplayer when I'm working, quite a bit of chat and I also
tested x11vnc (but that was well after I noticed the battery issue).


> I haven't experienced this myself, but I'm running with touchscreen and
> keyboard input sounds off (maemo-xinput-sounds still runs though).

I disabled the vibration but not the sounds.

Comment 5 Andre Klapper 2009-12-01 17:17:56 UTC

The internal ticket for this is currently closed as WORKSFORME and people think
that this has been fixed after the release of 1.2009.42-11.
Any further updates here are highly welcome, especially after a newer version
has been released by Nokia.

Comment 6 Juha Koivisto 2009-12-01 18:27:19 UTC

Correction - I think no fix has been identified, just nobody has figured out if
and how this can be reproduced. If anyone here has any ideas for that, I'm sure
they would be appreciated (with any software version).

Problem still exists with the last release. I'm not playing audio or video
files, just a standard system sound scheme is active, reading mail, receiving
phone calls. Occasionally this process goes to 100% CPU usage until explicitly
killed from console. This process restarts itself and all is fine.

Comment 8 Andre Klapper 2009-12-17 14:45:38 UTC

(In reply to comment #7)
> Problem still exists with the last release.

Sure. As written before, this has been fixed after the release of 1.2009.42-11.

Comment 9 Andre Klapper 2010-01-11 11:06:09 UTC

qole, can you please reattach your testcase here? Seems like we've sorted out
Bugzilla problems, finally. :-/

Comment 10 Alan Bruce 2010-01-11 21:04:01 UTC

SOFTWARE VERSION:
2.2009.51-1

EXACT STEPS LEADING TO PROBLEM: 
1. Open terminal
2. Enter "xkbcomp qole.xkb :0" (using test case attached)
3. Run "top"

ACTUAL OUTCOME:
maemo-xinput-sounds is using 95% or more of the CPU

REPRODUCIBILITY:
100% of the time

WORKAROUND:
killall maemo-xinput-sounds

The test case "qole.xkb" can be found attached to this post:
http://talk.maemo.org/showthread.php?p=392698#post392698

Will also attach it to this bug.

Comment 11 Alan Bruce 2010-01-11 21:07:26 UTC

Created an attachment (id=1963) [details]
Testcase file to trigger the bug

Comment 12 Andre Klapper 2010-01-11 21:08:28 UTC

Thanks again!

Comment 13 Andre Klapper 2010-01-12 17:21:27 UTC

Kudos to qole, patch on the way:
"That test case was really useful in investigating the bug. Old implementation
used async context call, and g_io_watch to detect events when they arrived.
Certain events in X server caused g_io_watch to go berserk and using much CPU.
Listening to X events is now implemented using separate server connections (one
for context listening and another for controlling, as suggested in XRecord
documentation) and a thread for listening context events using blocking call."

Comment 14 Eero Tamminen 2010-01-13 11:41:40 UTC

> Occasionally this process goes to 100% CPU usage until explicitly killed from console

-> 100% CPU usage is also performance issue (and affects also touchscreen &
keyboard sound response times I guess), so adding keyword.

Comment 15 Andre Klapper 2010-01-14 12:32:54 UTC

Today Nokia released the Maemo5 update version 2.2009.51-1 for public (also
called "PR1.1" sometimes).
If you have some time we kindly ask you to test again if the problem reported
here still happens in this new version - just leave a comment (and feel free to
update the "Version" field to the new version if it's still a problem).

The bug is still present on version 2.2009.51-1 (PR1.1) on my german Nokia
N900. I must kill it per X- Terminal with "kill -9 `pidof
maemo-xinoput-sounds`"

I've added 'Temporary Remap' section to
http://wiki.maemo.org/Remapping_keyboard

Running the script presented there will trigger this bug, with 2.2009.51-1

Comment 18 Alan Bruce 2010-01-19 20:41:00 UTC

Andre: Did you not notice my firmware version (51-1) in my comment?

Comment 19 Andre Klapper 2010-01-19 20:51:23 UTC

Sure. :)

Comment 20 Andre Klapper 2010-01-20 13:58:02 UTC

*** Bug 8303 has been marked as a duplicate of this bug. ***

Comment 21 Andre Klapper 2010-01-28 14:49:07 UTC

Fix has been integrated internally, now testing...

Comment 22 Andre Klapper 2010-02-03 13:05:58 UTC

Fixed in the internal version 2010.04-11.

Comment 23 Andre Klapper 2010-03-15 20:55:33 UTC

Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).