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. Thanks. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. run EL4 2. wait 3. 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.
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.... 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. Paul
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 (redhat?)...
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? Cheers, Paul
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 be fine. Paul - I would agree that if turning off gpm stops the problem, that this needs to be moved to that package.
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? Paul
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? Cheers, Paul
OK, it still hangs with the usb hub unplugged.... Going to try a different usb mouse.... will report back. Paul
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 winXP. So does this look like a problem with the usb mouse driver in the current EL4 kernel? Does anyone at redhat have one of these Dell USB mice to test and see if they can replecate the problem? Paul
forgot to say that the intellimouse optical I am now using is usb. Paul
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 problem. How to proceed? Paul
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. Paul
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 problem.
Suzanne, 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. Paul
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.
Hi Suzanne, I have done as you suggest and I'll report back with the news. Many thanks, Paul
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 confusion. 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.
Suzanne, 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. Paul
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. Thanks, Paul
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. Paul
Paul - Not trying to leave you hanging with your question; still working on determining who can answer you.
Paul, 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.)
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, Paul
Chris, 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, Paul
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 device)
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. Paul
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
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. ***