x11-driver-input-synaptics-1.3.0-4mdv2011.0 lib64xtst6-1.2.0-1mdv2011.0 x11-server-xorg-1.9.2.901-1mdv2011.0 Running synaptics -R reliably causes following effect: screen becomes blank I can still login via network I see syndaemon consuming 100% CPU and looping: Process 3462 attached - interrupt to quit select(5, [4], NULL, NULL, NULL) = 1 (in [4]) select(5, [4], NULL, NULL, NULL) = 1 (in [4]) select(5, [4], NULL, NULL, NULL) = 1 (in [4]) It is not as much CPU hog that is annoying as blanked screen; the only way out is to reboot. I can attach with gdb and poke around if required; but I suspect it is actually Xserver/library and not syndaemon issue.
hmm, unless you have a lot of activity on the input devices, the select call should just block. not sure why you're getting data on that connection. is this a new problem that just appeared recently?
In the past syndaemon in Mandriva was built without RECORD support, so it is hard to tell. I rebuilt it with RECORD and immediately hit this issue.
Hello, I'm currently using Mandriva Cooker (32 bits) with Kde 4.6 RC1 x11-driver-input-synaptics-1.3.0-5mdv2011.0 libxtst6-1.2.0-1mdv2011.0 x11-server-xorg-1.9.3-3mdv2011.0 I've opened this bug on Kde bug tracking : https://bugs.kde.org/show_bug.cgi?id=261875 Because In Kde systemsetting, I've checked the option to disable the touchpad while typing and it makes my system became sluggish with Cpu nears 100% It's the process "syndaemon"which is the cause, I think it's the same problem as you reported What's news about this ?
please try the git repo and run the syndaemon from there? do you still see the issue then? I wonder if there's some magic flags mandriva uses that causes this issue, because I can't see it here.
(In reply to comment #4) > please try the git repo and run the syndaemon from there? do you still see the > issue then? I wonder if there's some magic flags mandriva uses that causes this > issue, because I can't see it here. I tested syndaemon from current GIT master and it enters the same tight loop with 100% CPU after some time. It happened after (I do not necessary imply "because") resume from suspend to RAM, about 20 minutes later. I started it yesterday and was using system for a couple of hours before suspend.
(In reply to comment #5) > (In reply to comment #4) > I tested syndaemon from current GIT master and it enters the same tight loop > with 100% CPU after some time. It happened after (I do not necessary imply > "because") resume from suspend to RAM, about 20 minutes later. I started it > yesterday and was using system for a couple of hours before suspend. And today resuming from suspend Xorg crashed (no stack) and syndaemon looped with 100%. I did not have X crash for several months so looks like suspend/resume does play some role here.
Yes, now I am almost sure it is caused by suspend/resume cycle (it may take several of them, so far I got this effect after second cycle). I do not think it is syndaemon at all; rather X server probably gets confused by udev events during suspend/resume and starts spamming syndaemon with bogus information. Also with current version of X server I have it dies very soon when this has started. I am ready to provide any additional information I can collect.
Created attachment 45237 [details] xorg log Same problem in gentoo xf86-input-synaptics-1.4.0 x11-base/xorg-server-1.10.0.901 , 1.10.0 libXtst-1.2.0 Steps to reproduce: run syndaemon -R connect A4Tech mouse to the notebook Result: syndaemon consuming 100% CPU and looping in "while(1) { ... }" gdb prints: ret = 1 fd = 4 cbres.key_event = 0 cbres.non_modifier_event = 0
We are hitting this in Ubuntu as well: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/754470
Created attachment 45683 [details] [review] Workaround for syndaemon There's a bug in X or Xlib that causes an event to be enqueued to the XRecord connection. The XRecord connection hasn't subscribed to any events, so this is in error. This patch papers over the issue by draining any events from the connection, but it does not address the real issue.
workaround pushed to synaptics repo, though a fix for the real bug would be appreciated. commit bdc9c7cf9767bda77c690cb4211f6f6cb4567748 Author: Chase Douglas <chase.douglas@canonical.com> Date: Fri Apr 15 15:29:57 2011 -0400 Drain XRecord connection of any events after handling replies
(In reply to comment #11) > workaround pushed to synaptics repo, though a fix for the real bug would be > appreciated. > > commit bdc9c7cf9767bda77c690cb4211f6f6cb4567748 > Author: Chase Douglas <chase.douglas@canonical.com> > Date: Fri Apr 15 15:29:57 2011 -0400 > > Drain XRecord connection of any events after handling replies Thanks! It works well for me.
This is a mass change of bugs. Bugs assigned to me that haven't been updated in the last 3 years are closed as WONTFIX, because, well, let's at least be honest about it. Please do not re-open unless you have a really good reason to do so (e.g. you're fixing it yourself). If it hasn't been fixed in the last 3 years, it probably won't be fixed anytime soon either. Sorry.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.