Bug 149015 - temporary mouse freeze in el4
Summary: temporary mouse freeze in el4
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
(Show other bugs)
Version: 4.0
Hardware: i386 Linux
Target Milestone: ---
: ---
Assignee: Dave Jones
QA Contact: Brian Brock
: 153942 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2005-02-17 22:31 UTC by EE CAP Admin
Modified: 2015-01-04 22:17 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-04 16:53:59 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description EE CAP Admin 2005-02-17 22:31:47 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041215 Firefox/1.0 Red Hat/1.0-12.EL4

Description of problem:
After using EL4 for a few hours with a Dell Dimension 8300 or 8400 with a usb mouse, the mouse freezes.

We saw this in the beta once, but thought nothing of it.  Now we have rolled out EL4 it is a problem.

I have marked this bug as severe as, whilst it may not be a security problem, having an unreliable mouse is completely unacceptable.

At the time of the mouse locking up, there is a message in /var/log.messages which says:

Feb 16 16:48:40 glenesk gpm[3559]: *** info [mice.c(1766)]:
Feb 16 16:48:40 glenesk gpm[3559]: imps2: Auto-detected intellimouse PS/

Switching off gpm does not solve this problem.

Also, the solution of adding "psmouse.proto=bare" from other bugzilla entries about KVM switches does not fix the issue.


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

How reproducible:

Steps to Reproduce:
1. run EL4
2. wait

Actual Results:  mouse freezes

Expected Results:  mouse does not freeze

Additional info:

you can unfreeze the mouse by unplugging it or switching to another virtual console and back to X11.

Comment 2 Geoff Dolman 2005-02-21 12:06:57 UTC
I have a similar problem with Dell Precision 330 and 340. This is that if you
press control-alt-F1 you get a complte X, keyboard and mouse hang. I have not
tried magic sysrq key combinations to break this yet but everything else
(control-alt-backspace, etc) do nothing.
The only resolution is logging in from another machine and killing X or a reset.
I've treid this with usb keyboard + usb mouse. Ps/2 keyboard + usb mouse. Ps/2
keyboard + ps/2 mouse. All are the same.
However with a Dell precision 530 with smp kernel I do not get this problem...

Comment 3 EE CAP Admin 2005-02-21 12:58:58 UTC
Geoff - I now wonder if my problems are two fold.....

I stopped gpm and the problem did no go away - but I think that was a vmware
4.5.2 problem.  Now I'm running vmware 5rc2 the bad hangs have gone away.

But the mouse still freezes and switching to a console and back to X (for me)
solves the problem.  But I now wonder if stopping gpm will fix it properly....
will test.

Perhaps you might want to try running without gpm.

Redhat - This problem is on the box I am using full time so I am willing to test
things if it means we can get it fixed ASAP.


Comment 4 Geoff Dolman 2005-02-21 13:18:01 UTC
I stopped gpm and tried pressing control-alt-F1 and got the same behaviour as
before. Possibly this is two different things and I should log a separate bug

Comment 5 EE CAP Admin 2005-02-21 13:28:23 UTC
OK - I am going to run with gpm turned off for a couple of days and see it the
problem goes away.

Will report back.  If that is the case then I guess the bug report needs
changing to be part of gpm, not kernel.

Geoff - if you have an nvidia graphics card - try the nvidia binary driver?



Comment 6 Geoff Dolman 2005-02-21 14:03:47 UTC
No I haven't - but I have nailed what the cause of the issue is (for me at least).
It's having a dual-head with spanning desktop on an ATI radeon 7000.
This worked fine under RHEL 3 but with an upgrade or new install I get a
complete X freeze when pressing ctrl-alt-F1 -- but not if one of the heads is
dropped from the setup. The screens are two Dell 1702fps with digital inputs.

Should I log this as a bug under a different package? xorg?

Comment 7 Suzanne Hillman 2005-02-21 16:27:24 UTC
Geoff - please do log your problem as a different bug. The xorg package should
be fine.

Paul - I would agree that if turning off gpm stops the problem, that this needs
to be moved to that package.

Comment 8 EE CAP Admin 2005-02-22 23:14:35 UTC
Dear Redhat,

OK, running with gpm turned off, myself and a collegue are both seeing the mouse
freeze problem.  

We no longer get the gpm messages in /var/log/messages of course - but does that
help diagnose the problem?  The kernel is randomly detecting a PS/2 mouse?

How do we proceed?


Comment 9 Suzanne Hillman 2005-02-23 15:42:17 UTC
Do you have only a single mouse plugged in? Do you have any other USB stuff in use?

Comment 10 EE CAP Admin 2005-02-23 17:22:50 UTC
No other mouse - just the Dell (logitech) usb mouse.  There are no other usb
things plugged in.  (oh actually, there is a usb hub on my monitor which itself
has nothiung plugged into it.  Do you want me to disconnect that hub?)

I guess I could also try a different usb mouse if I can find one?



Comment 11 EE CAP Admin 2005-02-23 20:36:57 UTC
OK, it still hangs with the usb hub unplugged....

Going to try a different usb mouse.... will report back.


Comment 12 EE CAP Admin 2005-02-25 00:50:42 UTC
OK, I have been using a MS intellimouse optical today and not had any lockups.

I should also tell you that unplugging the other mouse when it freezes and
replugging it also solves the problem (as well as switching to a virtual console)

I hope a college of mine who has been having the same problems will try a
different mouse tomorrow so we can be a bit more certain that it is that
specific model of mouse.  Unfortunately in my research group we have about 50 of
those Dell/Logitech mice - but they worked fine with EL3 and they work fine with

So does this look like a problem with the usb mouse driver in the current EL4

Does anyone at redhat have one of these Dell USB mice to test and see if they
can replecate the problem?


Comment 13 EE CAP Admin 2005-02-25 00:52:48 UTC
forgot to say that the intellimouse optical I am now using is usb.


Comment 14 EE CAP Admin 2005-02-25 15:33:57 UTC
more news....

I have not seen a mouse freeze on EL4 with my intellimouse optical, but the
collegeue who also swapped from a Dell mouse to an MS mouse has still got the

How to proceed?


Comment 15 Suzanne Hillman 2005-02-25 19:45:39 UTC
This is going to have to turn into a feature request. 

Otherwise, I suggest using the mouse that you have found works, or continuing
with the workarounds you mentioned at the very beginning.

Internal RFE bug #149728 entered; will be considered for future releases.

Comment 16 EE CAP Admin 2005-02-25 20:20:39 UTC
Excuse me?  making a mouse work reliably is a feature request?  That is the most
rediculous thing I have ever heard.

The Dell logitech mouse is unreliable.  My MS intellimouse USB works fine.  My
collegeue's slightly later model of MS intellimouse usb does the same thing as
the Dell one.


Comment 17 Suzanne Hillman 2005-02-25 20:43:56 UTC
Well, I note that the initial reason that I suggested freature request is
because no Dell Dimensions have been certified by Dell on RHEL. 

That said, I am continuing to investigate who would be best to point at this

Comment 18 EE CAP Admin 2005-02-25 20:47:29 UTC

OK, thanks for that information and please accept my apologies for my last email.

You can imagine how annoyed we are at having an expensive site license for an
operating system where version 4 is less reliable than version 3 - but we need
EL4 for the nfs 4 capability.

Your help is appreciated.


Comment 19 Suzanne Hillman 2005-02-25 20:56:49 UTC
Incidentally - and not at all trying to suggest changing methods at this point -
 it is generally a better idea to go through our support channels
(http://www.redhat.com/support or call 800-REDHAT1) if there is any sort of
urgency on a request.

Bugzilla is simply a bug tracking tool, and not actually a support channel.

Comment 20 Suzanne Hillman 2005-02-25 21:11:10 UTC
Try going into your BIOS, under the "Integrated Devices (LegacySelect Options)"
menu, and setting "USB Emulation" to off.

This is apparently USB legacy support, and may be causing your problem.

Comment 21 EE CAP Admin 2005-02-25 21:19:39 UTC
Hi Suzanne,

I have done as you suggest and I'll report back with the news.

Many thanks,


Comment 22 Suzanne Hillman 2005-02-25 21:53:25 UTC
I also note that I am, in fact, getting rid of the feature request I cloned, as
me being entirely too exhausted to be looking at bugs today. Apologies for that

A pointer to (FC) bug #132471 was given to me by the person who gave the above
suggestion, and appears to be the same thing.

Comment 23 EE CAP Admin 2005-02-25 22:11:11 UTC

Thanks I looked at that bug - what a long series of comments!

It's not clear to me from that report if this ever got resolved or is still
pending?  Looks like it was never properly resolved in Fedora?  Is that right or
did I miss something?  It has been closed as notabug.

We are happy to run with usb legacy turned off but would prefer that if there is
an issue with the mouse driver that it gets proprly fixed, of course.

Cheers - thanks for your help with this.


Comment 24 EE CAP Admin 2005-02-27 17:11:58 UTC
OK - this seems to have done the trick for me.  I have asked my colleague to do
the same thing and we will see if this foxes things for him.



Comment 25 EE CAP Admin 2005-03-02 16:42:31 UTC
Dear All,

This bios change seems to have fixed things on our Dimension 8300s with
Dell/Logitech mice.

Many thanks for the suggestion.

Is this a regression in the usb/mouse driver?  Does it need attention?  Having
to make bios changes from one version of EL to another makes me nervous.


Comment 26 Suzanne Hillman 2005-03-03 18:36:46 UTC
Paul -

Not trying to leave you hanging with your question; still working on determining
who can answer you.

Comment 27 Chris Lee 2005-03-03 19:20:51 UTC

Just for reference, as I'm sure you're aware, one of the larger changes in RHEL4
vs RHEL3 was the move to the 2.6 kernel.

The 2.6 kernel features a completely rewritten input layer, and as with any
major rewrite, regressions happen in certain corner cases (such as certain
revisions of USB mice with USB Legacy Support on certain BIOS revisions.)

(Not that this will fix the issue for you, but I thought I might offer some
small bit of explanation as to why you might see something like this.)

Comment 28 EE CAP Admin 2005-03-03 19:27:55 UTC
Hi Chris,

Sure - I appreciate that - and we are glad in the main to be running 2.6 - it's
much snappier on the desktop than 2.4 was.

So should I report this to higher up the chain (i.e. straight to the kernel
developers) or is this something that redhat will look at and push back up the tree?

Thanks very much,


Comment 29 EE CAP Admin 2005-03-03 19:36:57 UTC

Please note that although this is a specific case (as you point out, a certain
machine, a certain mouse, a certain bios setting and perhaps a certain bios
revision) the Dell Dimension 8300 is a pretty common desktop - and more than
likely will be used with the Dell supplied Dell/logitech USB mouse.  The bios
settings we were using were the defaults.

So yes - it might be a specific case - but perhaps a pretty common specific
case.  (Certainly common within my research group where we have about 80 Dell
Dimension 8300s and 8400s)

Thanks for looking at this,


Comment 30 Arjan van de Ven 2005-03-03 20:31:31 UTC
The issue with bios emulation of usb->ps2 is that most bioses do a rather poor
job of emulating the hardware. The way linux drives the mouse changed with 2.6
kernels (we have more advanced support now for more mice) such that some of the
bios brokenness now becomes untolerable...

(in this case the bios fakes a PS/2 device by translating USB to a virtual ps2

Comment 31 EE CAP Admin 2005-03-03 20:38:31 UTC
Aran - so from what you are suggesting - it is actually better if we make those
bios changes anyway... is that right?  I was wondering why gpm was logging
finding a ps2 mouse when we had usb mice plugged in.


Comment 32 Arjan van de Ven 2005-03-03 20:42:07 UTC
Yeah; bios usb->ps2 emu is a major source of problems, and always will be. Best
to just disable it entirely.

Comment 33 EE CAP Admin 2005-03-03 21:02:50 UTC
Arjan - thanks.  In that case I am happy to close this report with the solution
as  turning off USB legacy support.

Perhaps this sort of thing could go in the release notes?  It should go
somewhere I guess if this is a common problem....  (actually I was previously
unaware that this option meant USB->PS2 mouse emulation (and I guess for
keyboards too).  I thought it was compatability for 1st generation usb
devices.... the bios name is not exactly the most descriptive.)

Cheers to all for your help,


Comment 34 Suzanne Hillman 2005-03-04 16:53:59 UTC
Paul - I've entered a request for a release note about this, and I'm closing
this bug as per comment #33.

Comment 35 David Houlder 2005-06-01 00:10:14 UTC
*** Bug 153942 has been marked as a duplicate of this bug. ***

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