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: *** info [mice.c(1766)]:
Feb 16 16:48:40 glenesk gpm: 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):
Steps to Reproduce:
1. run EL4
Actual Results: mouse freezes
Expected Results: mouse does not freeze
you can unfreeze the mouse by unplugging it or switching to another virtual console and back to X11.
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...
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....
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.
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
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?
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?
Geoff - please do log your problem as a different bug. The xorg package should
Paul - I would agree that if turning off gpm stops the problem, that this needs
to be moved to that package.
OK, running with gpm turned off, myself and a collegue are both seeing the mouse
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?
Do you have only a single mouse plugged in? Do you have any other USB stuff in use?
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?
OK, it still hangs with the usb hub unplugged....
Going to try a different usb mouse.... will report back.
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?
forgot to say that the intellimouse optical I am now using is usb.
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?
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.
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.
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
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.
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.
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.
I have done as you suggest and I'll report back with the news.
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.
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.
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.
This bios change seems to have fixed things on our Dimension 8300s with
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.
Not trying to leave you hanging with your question; still working on determining
who can answer you.
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.)
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,
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,
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
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.
Yeah; bios usb->ps2 emu is a major source of problems, and always will be. Best
to just disable it entirely.
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,
Paul - I've entered a request for a release note about this, and I'm closing
this bug as per comment #33.
*** Bug 153942 has been marked as a duplicate of this bug. ***