Bug 134618

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)
	root (hd0,1)
	kernel /vmlinuz-2.6.8-1.541 ro root=LABEL=/  acpi=on psmouse.proto=imps

	initrd /initrd-2.6.8-1.541.img

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
the problem.
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
kernels.
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
reconfiguration.
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.

Thanks!

Jim

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.

Thank you.

Running FC5T1 with no problems. This was a long forgotten bug. Closing this is fine