Bug 155517 - Mouse locks after KVM switch
Summary: Mouse locks after KVM switch
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-04-20 23:56 UTC by Dan Christian
Modified: 2015-01-04 22:19 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-10-03 00:06:16 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Dan Christian 2005-04-20 23:56:55 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5

Description of problem:
The mouse works fine on console or X until I switch the KVM to another system and return.

After I switch back, the mouse won't move.



Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Boot
2.Switch KVM to another system
3.Switch back
  

Additional info:

Restarting gpm doesn't help.

Changing virtual terminals doesn't help.

The mouse works fine under XP on the same system.

Logitech mouseman optical dual sensor (PS/2).

The KVM is generic.  But FC2 and FC3 (all Athlon) work fine with it.

Comment 1 Dan Christian 2005-05-05 01:35:47 UTC
So I upgraded my main FC2 box to FC3+updates.  Now this happens on systems that
used to be fine.

It's not a FC4 bug, but a linux-2.6.11 bug.

-Dan


Comment 2 Allen Kistler 2005-05-28 03:58:19 UTC
There have been similar bugs logged in Bugzilla before.  When this happened to
me a few kernels ago (like probably during fc3-test), the fix was to put
psmouse.proto=bare in grub.conf.  That worked for me up through 2.6.11-1.14_FC3.
 However, it stopped working for me with 2.6.11-1.27_FC3, so I had to go back to
2.6.11-1.14_FC3.

Just in case it helps, here's a little bit of an oddity: the mouse would only
lock on my Pentium 4 machine (running the 686 kernel).  I also have a Pentium
(running the 586 kernel) and a Pentium 3 (running the 686 kernel) machine on the
same switch.  The mouse was fine on the Pentium and Pentium 3 with the
2.6.11-1.27_FC3 kernel, but I had to back out the kernel on both the Pentium and
Pentium 4 to be able to switch among all boxes without ill effects.

PS to DAC:
Only you can change the component from gpm to kernel.  It needs to be kernel.

Comment 3 Allen Kistler 2005-05-30 22:41:06 UTC
Perhaps I spoke too soon in my last comment.  The mouse now locks on my P4 box
with the older kernel.  I've tried kernel 2.6.10-1.770, too.  I begin to suspect
my recent difficulty is with hardware.  The onset just happened to coincide with
a new kernel.  My other boxes are fine with the KVM with psmouse.proto=bare in
grub.conf.

Comment 4 Dan Christian 2005-05-31 04:40:30 UTC
In my case, it seemed like having the older kernels in the rotation seemed to
help things.  It's almost like the problem affects the next guy in the rotation,
but the older kernels were resetting something.

I couldn't pin this down to something exact.  It just takes too long to try
different kernel combinations.

The problem went away when I switched to a nicer KVM (USB based).  One on hand,
its clearly a hardware related problem.  On the other hand, it used to work and
now it doesn't.



Comment 5 Dave Jones 2005-07-15 19:27:07 UTC
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.

Comment 6 Dave Jones 2005-10-03 00:06:16 UTC
This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.

There are a large number of inactive bugs in the database, and this is the only
way to purge them.

Thank you.


Note You need to log in before you can comment on or make changes to this bug.