Num lock toggling causing mate-settings-daemon, xorg cpu runaway, LED astable

Bug #1364111 reported by Christopher A. Chavez on 2014-09-01
This bug affects 1 person
Affects Status Importance Assigned to Milestone
mate-settings-daemon (Debian)
Fix Released
mate-settings-daemon (Ubuntu)

Bug Description

If the Num lock key is toggled rapidly, there's a chance that mate-settings-daemon will go into runaway CPU usage (causing Xorg to also appear to be in runaway CPU usage), and the Num lock LED will flash/blink erratically (randomly--this is not the steady 2Hz blinking when a kernel panic occurs). By killing mate-settings-daemon, the system can recover; mate-settings-daemon respawns, Xorg goes back to normal CPU usage, and the Num lock LED is stable.
This seems to apply only to hardware Num lock toggling, as rapid toggling in onboard does not seem to cause the issue. The same does not appear to happen to the caps lock key. The state of num lock is indeed indeterminate when this occurs (e.g. numeric 4 will vary between typing '4' and left-arrow).
This appears to be directly related to prior CPU availability, as it is more of a problem on older hardware (e.g. with 2001 Pentium M) where it can be triggered on an idle system, and more difficult to duplicate on later hardware (e.g. with a dual-core processor) unless the CPUs are busy (e.g. other runaway processes).
Tested on both 32-bit and 64-bit. This behavior is present at least since Ubuntu MATE 14.10 (beta 1).
ApportVersion: 2.14.7-0ubuntu1
Architecture: i386
DistroRelease: Ubuntu 14.10
InstallationDate: Installed on 2014-08-31 (1 days ago)
InstallationMedia: Ubuntu MATE 14.10 "Utopic Unicorn" - beta1 i386 (20140828)
Package: mate-settings-daemon 1.8.1-2
PackageArchitecture: all
ProcVersionSignature: Ubuntu 3.16.0-11.16-generic 3.16.1
Tags: utopic
Uname: Linux 3.16.0-11-generic i686
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True

Possibly related to, if not duplicate of, bug 969359 (for gnome-settings-daemon)?

description: updated

apport information

tags: added: apport-collected utopic
description: updated

apport information

Changed in ubuntu-mate:
importance: Undecided → Medium
Martin Wimpress (flexiondotorg) wrote :

This bug seems very similar to there following bug that was reported upstream:


The following patch to `gnome-settings-daemon` is useful reference, although sadly m-s-d and g-s-d are quite different in this area of code.


I've referenced this bug in the upstream issue tracker.

Changed in ubuntu-mate:
status: New → Confirmed
Changed in ubuntu-mate:
importance: Medium → Low
gravy45 (gravy45) wrote :

I tried it with Mate 14.04.1, a 64-bit platform, and can't duplicate it

gravy45 (gravy45) wrote :

I tried it with Mate 15.04 Beta 1, a 64-bit platform, in Virtualbox 4.3.22, and can't duplicate it

I have duplicated the behavior in VirtualBox 4.3.22 using the 64-bit 15.04 beta 1 livecd, but only when all CPU cores are completely busy (e.g. setting 1 core for the VM and running "dd < /dev/zero > /dev/null").

description: updated

Also, it looks like a patch has been submitted on github for this issue (based on the patch for gnome-settings-daemon), and should be incorporated by MATE 1.10. (At this point I'm assuming it's the same issue based on the comments there, although the initial description said "any key on the keypad".)

The upstream discussion is only on how the issue occurs due to some form of desktop sharing (e.g. vnc, x2go, synergy, etc.). I am not using any of those--and I have yet to tell if the patch submitted solves this, so maybe this is not necessarily a duplicate of the upstream issue. The trigger I have identified here is CPU unavailability.

Changed in mate-settings-daemon (Debian):
status: Unknown → New
Changed in mate-settings-daemon (Debian):
status: New → Fix Released
Changed in mate-settings-daemon (Ubuntu):
status: New → Fix Released
Changed in ubuntu-mate:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.