Bug 466634 - A fedora 9, new install, running firefox, tsclient, term windows, usb mouse, freezes/hangs/stops working [NEEDINFO]
A fedora 9, new install, running firefox, tsclient, term windows, usb mouse, ...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gnome-desktop (Show other bugs)
9
x86_64 Linux
medium Severity urgent
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-11 18:12 EDT by bruce
Modified: 2009-07-14 10:37 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 10:37:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
duffy: needinfo? (bedouglas)


Attachments (Terms of Use)

  None (edit)
Description bruce 2008-10-11 18:12:42 EDT
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)

Description of problem:
Situation. I did a fresh install of an amd dual core (toshiba satellite laptop) to fedora-9. I have the latest updates, and now have an issue where it appears that the system hangs/freezes/dies based on the movement of the usb mouse.

It appears that if I move the mouse, with a few instances of firefox/tsclient running, I can sometimes get the mouse to freeze, with the mouse pointer in the "cross" display. This locks up/freezes the keyboard/mouse system. I'm not sure if the actual system is dead, as it appears that the drive light on the system is still in action.


Version-Release number of selected component (if applicable):
I have the latest version of the f9 x86_64 kernel, with firefox3. The kernel is 2.6.26.5-45.fc9.x86_64.


How reproducible:
For me, I can fire up a few instances of Firefox3, as well as a VNC/Terminal Server" client. I can then try to move the mouse around, dragging the different windows, and somehow, if I drag the mouce into the upper panel at the top of the display, the mouse doesn't return to the normal "arrow pointer". Instead the mouse is stuck in the cross pointer, and the system freezes/hangs/dies.

Steps to Reproduce:
1.
2.
3.
  
Actual results:
System Freezes/Hangs/No longer works. The mouse stops functioning, the keyboard stops responding.

Expected results:
Mouse and keyboard should work as usual.


Additional info:
Let me know what else I can provide. If you give me instructions on what you need, I can get you whatever might help.


Reproducible: Sometimes

Steps to Reproduce:
1. Not sure. For me, I can fire up the system, run a few instances of Firefox3, Tsclient, VNC, and then drag the mouse around. At random times, the mouse seems to go into the upper panel, and a window of one of the apps where it then dies, causing the mouse/keyboard to stop functioning.

2.
3.
Actual Results:  
see above...

Expected Results:  
mouse/keyboard should continue to work as normal.

I have a fresh install from the basic repos (fedora/livna/updates).

I run a few instances of Firefox3, VNC, Terminal Server Client(tsclient)

I'm running on a dual core, Toshiba Satellite laptop, 4G mem, basic f9 kernel 2.6.26.5-45, with usb wifi, and usb mouse.

I've seen a previous bug/posting that seemed to be simialr, but it appeared to have been closed. The issue is real, it is occuring!!
Comment 1 Máirín Duffy 2008-10-11 21:55:49 EDT
when this happens, if you press ctrl-alt-f2 (to go to a text console) and then login and type:

pkill -f tsclient

then press ctrl-alt-f7 (to go back to the previously hung graphical session) does it recover and work again (with the exception of tsclient which you just killed).

The issue you described sounds a lot like a stuck "pointer grab", which is an operation that a client can do to prevent the rest of the desktop for getting events from the mouse and keyboard.

Do you know where the cross pointer is initiated from?  Is it from tsclient?
Comment 2 Paul Paukstelis 2009-05-05 23:11:18 EDT
I think I might be seeing something similar to this in Fedora 10. It seems that when I switch active windows, I will occasionally get a stall that will prevent mouse or keyboard input on any window. If I use a hotkey to open a terminal I can kill the the last process related to the window I was in when the stall occurred,and this frees everything back up. This just started recently when I switched to using metacity from compiz-fusion (because I couldn't get compiz to work correctly with two monitors). Very frustrating.
Comment 3 Bug Zapper 2009-06-09 22:56:22 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 4 Bug Zapper 2009-07-14 10:37:49 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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