Bug 110496 - No USB mouse after glibc-2.2.5-44 update
No USB mouse after glibc-2.2.5-44 update
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-20 04:35 EST by Dr. Henrik Seidel
Modified: 2007-04-18 12:59 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-25 17:04:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Dr. Henrik Seidel 2003-11-20 04:35:48 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.4) Gecko/20030703

Description of problem:
After the latest (2003-11-13) security update of glibc (2.2.5-44) my
USB mouse does no longer work. The pointer in X11 is frozen. Reverting
to 2.2.5-43 (rpm -Uvh --force glibc-*43.*rpm) made the mouse work again.

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

How reproducible:
Always

Steps to Reproduce:
1. Install all updates for Redhat Linux 7.3, including glibc-2.2.5-44
2. Restart the computer
3. Try to use the USB mouse in X11 - mouse not responding
4. Revert to glibc-2.2.5-43 (no changes to other packages), and the
mouse works again.
    

Actual Results:  The mouse pointer is simply frozen.

Expected Results:  The mouse should have worked as it did before
upgrading to glibc-2.2.5-44


Additional info:

Here are some kernel messages I got after upgrading to 2.2.5-44:

Nov 20 09:35:58 bea379 kernel: hub.c: already running port 1 disabled
by hub (EMI?), re-enabling...
Nov 20 09:35:58 bea379 kernel: usb.c: USB disconnect on device
00:1f.2-1 address 2
Nov 20 09:35:59 bea379 kernel: hub.c: new USB device 00:1f.2-1,
assigned address 4
Nov 20 09:35:59 bea379 kernel: input0: USB HID v1.10 Mouse [Logitech
USB Receiver] on usb1:4.0
Nov 20 09:36:01 bea379 kernel: usb-uhci.c: interrupt, status 3, frame# 324
Nov 20 09:36:02 bea379 /etc/hotplug/usb.agent: Setup hid for USB
product 46d/c501/910
Nov 20 09:36:06 bea379 kernel: usb-uhci.c: interrupt, status 3, frame#
1276
Nov 20 09:36:11 bea379 kernel: usb-uhci.c: interrupt, status 3, frame# 148
Nov 20 09:36:16 bea379 kernel: usb-uhci.c: interrupt, status 3, frame#
1060
Nov 20 09:36:19 bea379 kernel: hub.c: already running port 1 disabled
by hub (EMI?), re-enabling...
Nov 20 09:36:19 bea379 kernel: usb.c: USB disconnect on device
00:1f.2-1 address 4
Nov 20 09:36:19 bea379 kernel: hub.c: new USB device 00:1f.2-1,
assigned address 5
Nov 20 09:36:20 bea379 kernel: input0: USB HID v1.10 Mouse [Logitech
USB Receiver] on usb1:5.0
Nov 20 09:36:20 bea379 kernel: hub.c: already running port 1 disabled
by hub (EMI?), re-enabling...
Nov 20 09:36:20 bea379 kernel: usb.c: USB disconnect on device
00:1f.2-1 address 5
Nov 20 09:36:21 bea379 kernel: hub.c: new USB device 00:1f.2-1,
assigned address 6
Nov 20 09:36:21 bea379 kernel: input0: USB HID v1.10 Mouse [Logitech
USB Receiver] on usb1:6.0
Nov 20 09:36:21 bea379 kernel: usb-uhci.c: interrupt, status 3, frame# 308
Nov 20 09:36:23 bea379 /etc/hotplug/usb.agent: ... no modules for USB
product 46d/c501/910
Nov 20 09:36:24 bea379 kernel: hub.c: already running port 1 disabled
by hub (EMI?), re-enabling...
Nov 20 09:36:24 bea379 kernel: usb.c: USB disconnect on device
00:1f.2-1 address 6
Nov 20 09:36:24 bea379 /etc/hotplug/usb.agent: ... no modules for USB
product 46d/c501/910
Nov 20 09:36:25 bea379 kernel: hub.c: new USB device 00:1f.2-1,
assigned address 7
Nov 20 09:36:25 bea379 kernel: usb.c: USB device not accepting new
address=7 (error=-110)
Nov 20 09:36:25 bea379 kernel: hub.c: new USB device 00:1f.2-1,
assigned address 8
Nov 20 09:36:25 bea379 kernel: input0: USB HID v1.10 Mouse [Logitech
USB Receiver] on usb1:8.0
Nov 20 09:36:26 bea379 kernel: usb-uhci.c: interrupt, status 3, frame#
1252
Nov 20 09:36:28 bea379 /etc/hotplug/usb.agent: Setup hid for USB
product 46d/c501/910
Nov 20 09:36:28 bea379 /etc/hotplug/usb.agent: Setup mousedev for USB
product 46d/c501/910
Nov 20 09:36:31 bea379 kernel: hub.c: already running port 1 disabled
by hub (EMI?), re-enabling...
Nov 20 09:36:31 bea379 kernel: usb.c: USB disconnect on device
00:1f.2-1 address 8
Nov 20 09:36:31 bea379 kernel: hub.c: new USB device 00:1f.2-1,
assigned address 9
Nov 20 09:36:31 bea379 kernel: input0: USB HID v1.10 Mouse [Logitech
USB Receiver] on usb1:9.0
Nov 20 09:36:31 bea379 kernel: usb-uhci.c: interrupt, status 3, frame# 300
Nov 20 09:36:34 bea379 /etc/hotplug/usb.agent: Setup hid for USB
product 46d/c501/910
Nov 20 09:36:34 bea379 /etc/hotplug/usb.agent: Setup mousedev for USB
product 46d/c501/910
Nov 20 09:36:36 bea379 kernel: usb-uhci.c: interrupt, status 3, frame#
1252
Comment 1 Ulrich Drepper 2003-11-20 12:04:57 EST
Try using the mouse outside of X11.  Have gpm activated and try to use
the mouse on the console.
Comment 2 Dr. Henrik Seidel 2003-11-21 05:25:39 EST
I did already do so (and should have reported that in the first
place). No mouse response with gpm either (with glibc-2.2.5-43). With
glibc-2.2.5-43 I get a cursor which follows the mouse position as soon
as I move the mouse, I can copy and paste. Nothing like this with
glibc-2.2.5-44.
Comment 3 Ulrich Drepper 2004-08-26 00:40:14 EDT
There is not much which can be done since we cannot reproduce any such
problem.  Beside, this is horribly old code.

What you can do is to run gpm under strace and ltrace, with the new
and the old glibc.  Then compare the output and determine the
differences.  That output might ring a bell but without anything like
this I'll have to close the bug.
Comment 4 Ulrich Drepper 2004-09-25 17:04:05 EDT
No response received.  Closing.

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