Bug 115763 - Mouse locks-up when installing new rpm
Summary: Mouse locks-up when installing new rpm
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 3.0
Hardware: athlon
OS: Linux
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-02-15 21:23 UTC by Jean-Pascal Houde
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-19 19:30:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dmesg output (15.07 KB, text/plain)
2004-02-17 22:03 UTC, Jean-Pascal Houde
no flags Details

Description Jean-Pascal Houde 2004-02-15 21:23:14 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030922

Description of problem:
When installing a new RPM package from Konqueror, the mouse locks up
until I do "/sbin/rmmod usb-uhci; /sbin/insmod usb-uhci", which correct
the problem. All the rest of the system continues to work (including
the RPM installation), only the mouse stops.
I am using a Microsoft IntelliMouse Optical Mouse (USB)

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

How reproducible:

Steps to Reproduce:
1. Open konqueror and point to a folder containing a new rpm package
(not already installed)
2. Double-click on the package
3. Enter root password
4. The mouse locks up. 
5. The install lags a little bit, but continues as if everything was

Actual Results:  Mouse doesn't respond to movement or clicks.
Keyboard and OS still work.
I also noticed that several lock files stay in /var/lib/rpm (__db.001
trough __db.003)

Expected Results:  The mouse should continue to work.

Additional info:

I've already expenrienced this problem with Redhat 9, but I didn't
file a bug at that moment.

Comment 1 Jeremy Katz 2004-02-17 04:24:30 UTC
What package were you installing?  Any of them?  Are there any
messages in dmesg about the mouse or usb controller?

Comment 2 Jean-Pascal Houde 2004-02-17 22:02:45 UTC
I've tried with two different packages, xmms-mp3 (from gurulabs) and
ami from RH 3 ES.
Now it is even more strange. I cancelled the rpm installation, did
rmmod and insmod, the mouse went OK, but it stopped working afters ~10
secs. Even if I do rmmod + insmod again, it only lasts something like
10 seconds!
I don't know exactly why... I tried to complete the installation and
it nothing changed.
I will attach the result of dmesg, because I don't know how to select
text without my mouse ;)

Comment 3 Jean-Pascal Houde 2004-02-17 22:03:30 UTC
Created attachment 97770 [details]
dmesg output

Comment 4 Jean-Pascal Houde 2004-02-17 22:24:44 UTC
I made a few tests more, and I conclude that :
-the problem doesn't appear if I start redhat-install-packages from
the console or from Nautilus
-there's a 5-10 seconds lag before redhat-install-packages appears
when I start it from konqueror.

Comment 5 Justin 2004-03-03 22:59:31 UTC
i have this same problem with my ms intelli mouse but in when in
nautilus. and it only happens occasionaly. this bug has been biting me
since RHL 8.0 its not very reproduceable in gnome maybe every 10 rpms
or fewer.  it never happens when using something like up2date or synaptic.
this bug seems to be related to bug # 77192 who also has an MS intelli
mouse. is it possible there is something wrong with the driver for
this mouse? oh i have an i686 not an athlon

Comment 8 Pete Zaitcev 2004-03-30 23:44:00 UTC
Looks pretty hopeless, but I'll look into it.

The -110 is a timeout; the device just goes belly up and that's it.

Comment 10 Pete Zaitcev 2005-05-14 01:18:41 UTC
I'm still thinking about this bug periodically. It is not common
and has something to do with particular mice (Intellimouse mostly).

The problem may be caused by a process which attempts to discover
the USB configuration. It may be a part of KDE desktop, I'm not well
versed in workings of that. If someone was able to identify what
process hits devfs, we might be able to reconfigure it not to do that.

Is there a possiblity of an upgrade to RHEL 4? It is based on kernel 2.6
which has so-called "control transfer queueing".

Comment 11 RHEL Product and Program Management 2007-10-19 19:30:03 UTC
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

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