Bug 109855
| Summary: | hwbrowser, kudzu freeze usb mouse | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tom Laudeman <twl8n> |
| Component: | XFree86 | Assignee: | Eido Inoue <havill> |
| Status: | CLOSED NOTABUG | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-11-13 19:18:44 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. 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. kudzu does not open usb mice devices. 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. 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. If it happens when gpm isn't running, then it's doubtful that it's a gpm bug. Changing component, 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. |
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.