On 3/7/2017 4:22 AM, Mark Knecht wrote:
> I don't consider myself an OS guru, but were my machine having
lockup problems, I would want to know how much free RAM is available,
what programs are in memory, what programs are running, and which
programs are hogging the CPU and other resources to the extent that
nothing else gets to share them.
>
> Utility programs that yield this kind of information may be helpful
in identifying culprit programs and their offending processes during
operational pauses such as you described.
>
>
> Ken
>
I was using top in the console and then the 1 & z options. The machine
has 24GB with only about 10GB used. It did not appear that it had ever
swapped. The machine wasn't 'slow' - I could switch back and forth
from KDE to the console normally. Just no mouse operation in KDE -
sort of like KDE was under glass with the cursor above. As I say, the
VM continued to operate normally and responded to the VBoxManage
command issued from the console.
Most likely this was a 1-time event but this conversation is helpful
if it shows up a second time.
Cheers,
Mark
top can be useful, but htop may be preferable in some situations.
Additionally, if the mouse is wireless, battery replacement may be
needed, and if the mouse is older, mouse cleaning may be appropriate.
Advanced gaming mice and keyboards, such as those provided by Corsair,
may require some attention at the driver-kernel interface, especially to
achieve total functionality of additional customizable buttons on mice
or macro key extensions of keyboards for either gaming or other uses.
Information from kernel logs may be indicative of interesting
interactions. Unplugging then hot-plugging mice may cause Windows
Plug-n-Play responses without customization, but Linux may require
editing to allow that as a user-level activity. Research and testing
likely is required, especially with virtual machine considerations.
Ken
