Red Hat Bugzilla – Bug 134618
mouse tap and buttons not responding after time
Last modified: 2007-11-30 17:10:50 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Description of problem:
After configuring X with s-c-display --reconfig, then allowing
computer to run for awhile and do various tasks and also being away
from the computer long enough for the screensavers to cycle. I then
tried to control different processes with the touchpad. The tapping
did not cause any actions to complete. I then tried the actions with
the mechanical mousepad controls. There were no responses from either
method (touch, mechanical). The mouse was able to move to wherever the
finger moving over the touchpad directed the mouse pointer.
Also, I noticed synaptics messages related to loading and unloading
the synaptics driver witthin a loop. Eventually, I regained the mouse
taps and click functionality.
Attached will be my xorg.0.log generated during the episode. I'll
attach the s-c-display xorg.conf file and messages.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. configure system to use synaptics driver.
2. run configured system for normal use
3. notice a seeming locked up GUI, mouse did not react properly
4. discover messages on terminal X was launched from, relating to the
Actual Results: needed to edit s-c-display to allow configuration,
simple step, explained clearly.
system would not respond to normal tapping or clicking of mechanical
noticed kepad input was able to perform certain functions. A delay was
noticed when trying the keys. The response was slow, but completed
Saw all sorts of messages in terminal that X was launched.
Expected Results: I expected the same or better functionality than
loading psmouse.proto=imps within the boot loader kernel options.
my boot loader is below when the problem surfaced. acpi=on is a must
for this machine to function.
title Fedora Core (2.6.8-1.541)
kernel /vmlinuz-2.6.8-1.541 ro root=LABEL=/ acpi=on
lspci will be attached also
Created attachment 104763 [details]
this is output from lspci -vvv
Created attachment 104764 [details]
This is the log while still having mouse problem
Created attachment 104765 [details]
this is current messages.
I reverted to the proto argument and the original xorg.conf for submitting the
bug. The test was performed normally, but the most recent entries will be proto
and no synaptics.
This is my current boot information
title Fedora Core proto added (2.6.8-1.541)
kernel /vmlinuz-2.6.8-1.541 ro root=LABEL=/ acpi=on psmouse.proto=imps
Created attachment 104766 [details]
this is the s-c-display generated xorg.conf file
Created attachment 104767 [details]
this is my xorg.conf used before trials and currently using
Created attachment 104768 [details]
currently running xorg.conf log
Are you suspending/resuming your laptop during this period? If so are
you using apm or acpi?
running apm dispays - No APM support in kernel
the below modules are loaded, partial listing.
dm_mod 46677 0
button 4817 0
battery 6981 0
asus_acpi 9169 0
ac 3397 0
Sorry, I forgot to state that computer was idle and I did not setup
anything for suspend. I right clicked on the battery icon just now and
see the choice. I did not intentionally select this when experiencing
I don't recall for sure if the mouse was responsive after allowing the
screensavers to kick in and then exiting. It seems that I opened apps
and performed tasks before the seeming freeze.
Can you disable gpm and see if you can reproduce the hang.
After disabling gpm, I could not simulate errors w/ no proto in kernel
and s-c-display generated xorg.conf file for synaptics. I started
runlevel 3 and ran 'service gpm stop' before logging into X.
Later, I restarted gpm and was doing some work within a terminal,
after service gpm start.
I then launched mc from a terminal and it took awhile for mc to come
up. There was the text based twirling /-\ indicator and mc finally loaded.
After changing back to the GUI running in screen 7, I was presented
with bug-buddy and a notification that gnome-panel crashed.
I have not completed the dump for this error yet. bug-buddy sends out
the report via localhost and would bounce on rh servers. I'll post the
link to the bug later in the report from gnome.
Summary, I am not sure if this gpm off and on service isolated the
problem or not. There are side-effects, but not an exact replication
of losing tap and mechanical button control.
Created attachment 105032 [details]
synaptics off - on in xorg.0.log
checking xorg.0.log, I noticed an instance where synaptics loaded off and on.
This is at the tail end of the log.
I have not checked the mail yet for the gnome sumitted failure yet.
Does passing psmouse.resetafter=3 help at all, with gpm running on FC3.
I just added the psmouse.resetafter=3 parameter to the grub.conf file.
I will test this out later on during booting.
Additionally, this problem with synaptics has not caused my X server
to lose mouse functionality very often. It seems to be triggered
within the time that the computer pretty much idle and when the laptop
screensaver is broken out of when wanting to continue using the laptop.
Also, I launched two X versions recently. One as a normal user using
startx and another on screen 8 using a different user and different
desktop. (startx -- :8) - With the additional desktop running on
screen 8 and the normal screen 7 X server running, there seemed to be
a lot of synaptics on - synaptics off messages on the vterm used to
launch X. The responsiveness for the second X server seemed to be as
the one instance of X gets after some inactive idling fo the laptop.
Would running two instances of X add to getting this rarely locking up
synaptics mouse driver misbehaving? This would be with
psmouse.resetafter=3 added to the grub.conf file.
Created attachment 107512 [details]
Second server w/ synaptic - on / off called
Adding the additional parameter to grub did not influence the error in either
direction. The test was completed with running two servers, which seem to cause
the same problem as experienced after waiting causes with one server running.
This server is running KDE as another user.
Created attachment 107513 [details]
first instance of server
This server which is running GNOME would cause the loss of the mouse normally,
after time idling. This is the server state at present. This is for comparison
for feats performed by server when it is active.
Created attachment 109209 [details]
Newer install -frequent lockups
This problem seems to becoming more frequent with the synaptics on/off lockup.
The attached log shows the most recent lockup. I have another instance fron dec
22 that will be submitted next.
Created attachment 109210 [details]
previous crash w/ fresh install
I will add the proto option to the kernel after submitting this log. Currently,
I have no additional parameters added to the new install grub.conf file.
I've not been able to reproduce here yet, Kristian do you see what could be
happening here or have any suggestions to glean further info?
It looks a bit like 132471, which we closed as it seemed to be fixed in newer
kernels. I'd suggest trying a more recent kernel.
I added psmouse.resetafter=3 to the grub.conf file and am running the latest
The kernel that I am running now is 2.6.10-1.1063_FC4 and it appears that the
lockup is more influenced by changing to a virtual terminal and then back again.
For the synaptics loading and unloading unpredictably, I had to kill X from a
terminal. I also lost my mouse even when I rebooted. To get my mouse again, I
had to choose some mouse, save the output, then run s-c-mouse again and set the
mouse back to synaptics. The mouse seems to work fine after completeing this
I guess this bug can be closed since it is untracable on all but an hp ze4315us
or similar computer with acpi.
I'll check bug 132471 to see how close the problem comes to this rare
load/unloading problem of the synaptics driver.
bug 132471 does not seem to come close to the problem that I experienced. The
error seems to only be triggered by loading and unloading the synaptics driver
and some apm reference.
This is a mass-update to all currently open Fedora Core 3 kernel bugs.
Fedora Core 3 support has transitioned to the Fedora Legacy project.
Due to the limited resources of this project, typically only
updates for new security issues are released.
As this bug isn't security related, it has been migrated to a
Fedora Core 4 bug. Please upgrade to this newer release, and
test if this bug is still present there.
This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.
Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.
Running FC5T1 with no problems. This was a long forgotten bug. Closing this is fine