Bug 109855 - hwbrowser, kudzu freeze usb mouse
Summary: hwbrowser, kudzu freeze usb mouse
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: XFree86
Version: 1
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Eido Inoue
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-11-12 14:28 UTC by Tom Laudeman
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-11-13 19:18:44 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Tom Laudeman 2003-11-12 14:28:27 UTC
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 14:40:47 UTC
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 15:00:37 UTC
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 20:52:27 UTC
kudzu does not open usb mice devices.

Comment 4 Eido Inoue 2003-11-12 20:58:18 UTC
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 16:54:45 UTC
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 16:58:20 UTC
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 19:18:44 UTC
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.