maemo.org Bugzilla – Full Text Bug Listing
|Summary:||maemo-xinput-sounds uses all available CPU|
|Product:||[Maemo Official Platform] Multimedia||Reporter:||AB <andrea>|
|Component:||Multimedia framework||Assignee:||unassigned <nobody>|
|Status:||RESOLVED FIXED||QA Contact:||multimedia-framework-bugs|
|Priority:||Low||CC:||andrea, andre_klapper, benjamin, bogomips, eero.tamminen, herroux, juha.koivisto, maemo, mr_abruce, silviumc, tim, too|
|Attachments:||Testcase file to trigger the bug|
SOFTWARE VERSION: 1.2009.42-11 EXACT STEPS LEADING TO PROBLEM: 1. Notice abnormally short battery life (less than 1/2 day) and warm unit 2. Run powertop EXPECTED OUTCOME: Most of the cpu time is spent in deep(er) sleep states. ACTUAL OUTCOME: 100% of the time is in state C0 at 600MHz REPRODUCIBILITY: So far once, over the last couple of days. Rebooting the unit seems to cure it. EXTRA SOFTWARE INSTALLED: OTHER COMMENTS: The process consuming all available cpu time is maemo-xinput-sounds. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:184.108.40.206) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
(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).
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.
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.
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.
(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.
qole, can you please reattach your testcase here? Seems like we've sorted out Bugzilla problems, finally. :-/
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.
Created an attachment (id=1963) [details] Testcase file to trigger the bug
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."
> 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.
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
Andre: Did you not notice my firmware version (51-1) in my comment?
*** Bug 8303 has been marked as a duplicate of this bug. ***
Fix has been integrated internally, now testing...
Fixed in the internal version 2010.04-11.
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).