Opened 9 years ago
Last modified 4 years ago
#15271 new defect
USB mouse "dies" - pointer still moving but no function
| Reported by: | Torsten Römer | Owned by: | |
|---|---|---|---|
| Component: | other | Version: | VirtualBox 5.0.16 |
| Keywords: | linux guest usb mouse dies | Cc: | |
| Guest type: | Linux | Host type: | Windows |
Description
I am using a kubuntu 15.10 64 bit guest on Windows 7 Enterprise SP 1 with Version 5.0.16 r105871.
About every day, the USB mouse kinda dies in the guest - it still works normal on the Windows host and the pointer still moves in the kubuntu guest, but focus follows mouse and clicks don't do anything any more. Keyboard and everything else still works fine.
Logging off from KDE and on again fixes the problem.
In the attached dmesg, there is an issue with IRQ 22 and a stack trace which I am quite sure are related. The relevant VBox.log is also attached.
Attachments (3)
Change History (9)
by , 9 years ago
comment:1 by , 9 years ago
The IRQ 22 message is definitely related. Though this is the guest USB driver and therefore not directly related to VirtualBox. Could you provide the output of
cat /proc/interrupts
from your guests?
comment:3 by , 9 years ago
I have a similar issue running Win 10 host with Fedora 23 guest using VB 5.0.17 r106359. The minor difference is that the cursor inside the guest is missing visually, but focus follows where it should be. For instance, I can only tell where it is by what 'lights up' from a hover.
comment:4 by , 9 years ago
I have to correct my observations described here.
The problem now occurred pretty often, sometimes just a few minutes after logging out and in again. But dmesg never said anything about the IRQ 22 issue again and there was never any call stack, so that must have been something else.
I have the impression that the issue occurs when doing heavy scrolling like in Firefox or the Eclipse console.
The trick switching to a tty with CTRL+F1 and back to X with CTRL+F7 that sometimes helps with similar issues does not help here.
At the moment I have the impression that a GTK2 32 bit application puts the system in a state where the issue occurs. If I don't use this application, it seems the issue never occurs. If I use it, the issue may occur shortly after.
I'm going to use that application on another machine where the same OS is running natively to see if that rules out VirtualBox.
comment:5 by , 9 years ago
I'm sure now it was that 32 bit application (Camunda Modeler) that killed the mouse. It does not happen with the 64 bit version, no more mouse issues for weeks now.
dmesg with IRQ 22 issue and call stack