Bug 109855 - hwbrowser, kudzu freeze usb mouse
hwbrowser, kudzu freeze usb mouse
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: XFree86 (Show other bugs)
1
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Eido Inoue
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-12 09:28 EST by Tom Laudeman
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-11-13 14:18:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tom Laudeman 2003-11-12 09:28:27 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007

Description of problem:
Microsoft blue optical USB always freezes if hwbrowser is run.


Identical motherboard (second computer) same version of Fedora, 
GE Optical USB mini mouse freezes halfway through boot (probably
kudzu),  USB mouse now freezes 100% of the time, but during initial
install of Fedora, it was intermittant.

GE workaround: The same mouse used as serial is ok (reconfigured of
course).



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


How reproducible:
Always

Steps to Reproduce:
1. Gnome, run hardware browser from menu
2. Mouse freezes.
3.
    

Actual Results:  Cursor would not move. Had to kill X with
ctrl-alt-backspace.

Expected Results:  Mouse/cursor should not have frozen.

Additional info:

Biostar MB, USB 2.0 native.
Comment 1 Mike A. Harris 2003-11-12 09:40:47 EST
This sounds like kudzu or something else is slamming the mouse
hardware WHILE X is using it.  If so, not an XFree86 bug, but
a "don't do that" bug.
Comment 2 Tom Laudeman 2003-11-12 10:00:37 EST
re: Not an X bug
True. 

hwbrowser works fine while X is running with a similar USB optical
mouse on my RH8 machine so the problem may be with something common to
hwbrowser and kudzu.
Comment 3 Bill Nottingham 2003-11-12 15:52:27 EST
kudzu does not open usb mice devices.
Comment 4 Eido Inoue 2003-11-12 15:58:18 EST
Does it not freeze if gpm is not running? If so, then it's not a GPM
bug. Could also be a BIOS bug that is triggered by the battery applet
using APM or ACPI to query the battery level.
Comment 5 Tom Laudeman 2003-11-13 11:54:45 EST
apm, acpi and gpm seem to make no difference. 
Both computers have identical Biostar motherboards with Via chipset.

Machine #1 (USB MS blue optical wheel mouse) apm,acpi and gpm off:
cursor froze the second time hwbrowser was run. Reboot, cursor froze
the first time hwbrowser was run (FWIW, the keyboard seemed to stop
responding when the cursor froze, although ctrl-alt-bksp did kill X.
Also, when hwbrowser freezes the cursor, there is a 3 to 6 second hang
before the hwbrowser window draws its contents.). Switch mouse to
PS/2, reconfig with redhat-config-mouse, reboot. Everything is fine.
Ran hwbrowser several times, no problem.

Machine #2 (USB General Electric mini optical wheel mouse) apm and
acpi have always been off. Disable gpm via ntsysv, reboot. First boot,
mouse freezes during boot. Second boot ok. Third and Fourth boot mouse
freezes during boot. The mouse appears to freeze when as soon as the
machine goes to runlevel 5. 

Using redhat-config-mouse I've tried several different drivers for
each mouse. This helped #1 with the MS blue mouse. It didn't help #2
with GE mini mouse. Both mice currently work great connected with the
PS/2 adapter.
Comment 6 Eido Inoue 2003-11-13 11:58:20 EST
If it happens when gpm isn't running, then it's doubtful that it's a
gpm bug. Changing component,
Comment 7 Mike A. Harris 2003-11-13 14:18:44 EST
I never said it was a gpm bug at all.  I do not consider this an
XFree86 bug unless someone can prove to me that it is in fact
an X server bug.  I consider software that mucks with the hardware
while X is using it and then crashes the hardware to very much
be getting what it has coming to it.

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