Hi,
this is for anyone having the same trouble after upgrading to 17.5.0; I did the standard in place upgrade, and - as allways- installed the enhanced keyboard driver.
After that I started up my vm and did some work in IDEA. Shortly after I edited some code at once a whole line got erased instead of just 1 click on the remove key. You could literally see the line beeing draged leftwards and dissapear letter by letter.... At first I was ok... well.. wtf... after 2 mins the same again. I rebooted my laptop and restarted my work. Suddenly after 4 mins the whole system removes line by line and this time it even didnt let me use my own keyboard anymore... didnt stop... and tried to delete further even after the code file was already empy (thanks git... no worries here 😄 ). Also the whole system hung without beeing able to press any key - only way out was a complete hard reset of the hardware.
I tried to fix this for some time but only after I did a complete uninstall and reinstall with reboots and lefting out the "enhanced keyboard driver" the problem seems gone.
So, if you have any problems with your computer typing or deleting on its own: get rid of the "enhanced keyboard driver"!
For Vmware in case you're interested:
Betriebsystemname Microsoft Windows 10 Pro for Workstations
Version 10.0.19045 Build 19045
Systemhersteller Dell Inc.
Systemmodell Precision 7760
Prozessor Intel(R) Xeon(R) W-11855M CPU @ 3.20GHz, 3187 MHz, 6 Kern(e), 12 logische(r) Prozessor(en)
BIOS-Version/-Datum Dell Inc. 1.23.0, 07.06.2023
Installierter physischer Speicher (RAM) 64,0 GB
Thanks for the suggestion. I added the following lines to my .vmx config file on 2023-11-15 and haven't seen the issue since.
keyboard.allowBothIRQs = "FALSE"
keyboard.vusb.enable = "TRUE"
I don't know which of the two resolved it for me.
CASE REPORT
We recently encountered this problem while trying to deal with another issue-- ZFS data corruption under Ubuntu 22 when, and only when, running under VMWare 17.0. In hopes of a fix, we upgraded to 17.5.0.
IMMEDIATELY, all guest VMs began experiencing lag of up to several seconds per keystroke, even when completely idle. System Monitor, top, and iotop indicate no unusual loads.
INITIAL CONDITIONS
HOST
The host system is an Intel Core i7-8700K (0x6:0xE//0x6:0x9E:10) with 32 GB of RAM and 16GB of SSD-backed swap (which is not normally used). The graphics hardware is an NVidia Geforce RTX2060 with 12GB of VRAM. Storage is provided by a combination of WD Black NVMe SSD primary, and Samsung Pro SATA SSD secondary, storage, with a large rotary HDD as tertiary backup storage.
The host system runs Rocky Linux 9. It uses X11, not Wayland. It uses the nvidia driver, presently UMD Version NVIDIA 535.104.05. The display resolution is 4K, and the display device is a 60Hz LG monitor connected via DisplayPort.
The host system has been THOROUGHLY forced through benchmark and stress tests, which it passes. Thermal monitoring is conducted via OSPower (Konkor), Vitals, and the NVidia control panel. All conditions appear nominal. Deliberately throttling CPU core count and/or speed does not seem to affect either issue.
GUESTS
The guest VMs are running Ubuntu 22. Only one is run at a time. The resources allocated are:
CPU topology: 2 packages of three cores each.
VT-d, IOMMU, and CPU performance counter passthroughs are all DISABLED.
Memory: 12-16GB.
Video: 512 MB VRAM
Windowing system: X11
Resolution: Variable; 4K nominal
Storage: 250 GB multi-file dynamically sized.
Host storage backing: SSD or NVMe; ZFS or ext4 filesystem.
Scope of duties: Very large software and firmware image builds (OpenWRT, Yocto, Buildroot, rebuilds of GCC compiler suite).
Notes:
VMs are running primarily from SSD storage, though we have moved them to NVMe storage while investigating the Ubuntu 22 ZFS data corruption issue and observed no change in either that issue, or this keyboard delay issue.
EXPERIMENTAL FINDINGS
1. Adding:
keyboard.allowBothIRQs = FALSEkeyboard.vusb.enable = TRUE
produced no apparent change.
2. Disabling 3D acceleration in the guest WITHOUT the keyboard option changes SIGNIFICANTLY IMPROVED keyboard latency from 1000-3500 ms to perhaps 30-70 ms.
3. With 3D acceleration disabled, additionally applying the option:
keyboard.allowBothIRQs = FALSE
FURTHER IMPROVED keyboard latency from perhaps 30-70 to ms to 20-30 ms.
4. With both of the above improvements, additionally applying the option:
keyboard.vusb.enable = TRUE
FURTHER IMPROVED keyboard latency from 20-30 ms to effectively imperceptible.
OTHER FINDINGS OF INTEREST
1. Even when keyboard latency was at its worst, using the mouse wheel in Firefox produced instant response when rolled one click. This is significant, as comparing these latencies this is generally a very good test for determining overall X11 input latency.
2. Our ZFS data corruption issues, while still not fully resolved (we are falling back to ext4), were SIGNIFICANTLY EXACERBATED when the guests were using 3D acceleration. Additionally, we experienced frequent hangs and crashes when using both Ubuntu and Rocky Linux 9 guests for Yocto builds while 3D acceleration was on. We have tried multiple versions, and multiple packagings (official; distro; community; etc.) of the NVidia drivers, and observed no effect on the guests. Graphics, even accelerated graphics, on the HOST are very stable, to the point where a 3D game was installed via Steam and played successfully at punishing graphics settings, while a compile was running in the background, so we believe the host graphics to be stable and sound.
OUR CONCLUSIONS
1. VMWare's current testing and Quality Assurance (QA) processes for Workstation are clearly and demonstrably inadequate. This thread alone provides strong evidence of serious deficiencies that were immediately obvious as soon as the guests were powered on, on common hosting solutions.
2. The evidence strongly suggests that VMWare is considering testing results from ESXi or other products as adequate stand-ins for equally comprehensive testing results from VMWare Workstation, which they CLEARLY are not. This is, frankly, starkly obvious. The configurations people are reporting problems on are very basic, very common configurations for Workstation, but ones which would not be common for other products. The only reasonable explanation for issues this severe sailing through testing of VMWare Workstation is that at least some changes ARE NOT being adequately tested on Workstation. I find it unlikely that VMWare would completely blow off testing, so the reasonable middle-ground is that, during what is absolutely an economically challenging time in the market, VMWare has reduced co-testing of at least some critical changes across its product base. WHILE UNDERSTANDABLE GIVEN THE EVENTS OF RECENT YEARS, THIS STRATEGY IS *CLEARLY* NOT WORKING, AND NEEDS TO BE RECTIFIED. UNRESOLVED, THIS PRACTICE *WILL* PROVE TO BE MORTALLY DANGEROUS TO WORKSTATION AS A PRODUCT.
IN CLOSING
We rely on VMWare Workstation to provide permanently reproducible sterile build environments for embedded systems customers. Our ability to do this efficiently and reliably this directly affects both the security of these products, and the environments into which they placed. We take our clients' security and quality extremely seriously, and will push back hard when our vendors compromise our ability to protect their interests. Likewise, our reputation is extremely important to us, and we insist that products which act as an interface between us and our clients hit high standards.
We already know your people are of exceptional quality. But going forward, we must respectfully demand that we see that more clearly reflected in the products you ship.
Sincerely,
Matt Heck
Principal Firmware Engineer
USA Firmware LLC
/
President
Hard Problems Group, LLC
/
US INFRAGARD Southern Nevada
@usafw-mheck I sympathize with your problem, There are a litany of issues with VMware's hosted products that they seemingly have ignored by their silence and inaction - witness the debacle of over 2 years of complaints about poor performance on 12th Gen and newer Intel Core CPUs with ZERO, ZILCH, NONE response or apparent action by VMware. I'll also agree with you that the slavish devotion to ESXi has caused the hosted products to become second class citizens. They don't pay attention enough to the differing needs of the hosted platforms because they want to cut corners and use as much ESXi tech when possible whether it's good for the hosted products or not.
You're lucky if VMware sees anything here and takes action on it.
My only suggestions are:
@banackm This seems to have also helped with the freezing issue when using VMWare WS Pro 17.5. Prior the VM would lock up after 10-20 minutes of usage. Just used it for an hour with no freezes.
The
keyboard.allowBothIRQs = FALSE
in config.ini seems to have fixed this for me.
But it sure was frustrating having to downgrade from 17.5 to 17.0.2 after every reboot. Never could get to to stop auto upgrading.
To add the keyboard woes others have seen, here is a new one:
As soon as I actually click in the guest window (but not immediately after startup of the either VMware Player or the guest OS), the functionality of the Control key disappears completely from the host OS. The situation remains that way until after a logout/login sequence on the host.
Hardware: Dell Optiplex 9010 with 8 x Intel i7-3770, AMD Turks video card.
Host OS: OpenSUSE Leap 15.5, KDE Plasma 5.27, SSDM Desktop Manager with X11 (not Wayland).
VMware® Workstation 17 Player, version 17.5.0 build-22583795
Guest OS: both Windows XP and Windows 7 show the same behaviour. The same VM machines (off the same files) do not show this problem under VMware Player 6.1.
It appears that VMware is affecting how X11 interprets a Ctrl-key press.
@msohnius You might be having issues with your X11 ModifierMap. We have to muck with that when grabbed to correctly set LEDs and hook things like VT switches.
You can set the config option:
mks.x.resetModMap=FALSE
and we will avoid messing with the modifier map, at the expense of correct LEDs while grabbed and being unable to hook some key combinations while grabbed.
If you can post a vmware.log (without the configs) we can take a look and see if there's something we can fix on our end.
Thanks, @banackm, that was very helpful! Creating a ~/.vmware/config file with that one line in it solved the problem, presumably with the shortcomings you mention.
Which log file would you like to see? There are lots both in /var/log/vmware and in /tmp/vmware-<username>.
Before following your suggestion, I investigated a bit further: what actually happened is that as soon as focus went on the virtual-machine window (I think that's what you called "grabbed"), the X11 key modifier map is changed, and then not changed back properly. Here is the situation before the "grab" by the virtual machine,
$ xmodmap -pm
xmodmap: up to 4 keys per modifier, (keycodes in parentheses):
shift Shift_L (0x32), Shift_R (0x3e)
lock Shift_L (0x32)
control Control_L (0x25), Control_R (0x69)
mod1 Alt_L (0x40), Meta_L (0xcd)
mod2 Num_Lock (0x4d)
mod3
mod4 Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf)
mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb)
$
and here it is after:
$ xmodmap -pm
xmodmap: up to 0 keys per modifier, (keycodes in parentheses):
shift
lock
control
mod1
mod2
mod3
mod4
mod5
$
Interestingly, it really only disabled the Ctrl key, all the others still appeared to be working.
The map can be restored with the command "setxkbmap", but this had to be done every time focus went back to Linux. I believe the issue to be specific to OpenSUSE 15.5 as the host, but unlike the other issues mentioned in this thread it does not appear to be specific to Workstation 7.5 - I also tried 16.2 and 17.0.2, and the problem showed up there, too. 16.1 will not run on 15.5, but it does run on OpenSUSE 15.4, and there it does not show the problem. Up you guys to investigate what may have happened!
Thanks for the solution, though/
We need the vmware.log from the VM folder.
If you can temporarily set the config option "loglevel.mksAll=5", and then do a quick session where you PowerOn the VM, grab, briefly type/click the mouse, and then ungrab and PowerOff the VM, that would be the most helpful.
Ah sorry, it should literally be "vmware.log" in the folder with the VM file. So something like: /home/username/vms/MyWin10VM/vmware.log .
Here you go. It's the log file for the same session I sent yesterday. There was a later session, hence the -0 in the name.
It happens with or without the enhanced keyboard driver. What happens to me is I'll be editing a file, whether in vi, an IDE or Ubunutu Text Editor, what have you. Then all of a sudden, the last key I pressed, whatever it happened to be just starts repeating ad infinitum, locking the whole VM. All I can do is sit there, jaw-dropped, while I watch the file I was editing getting completely destroyed by the repeating character. The only course of action is to power off the VM and lose your unsaved work.
VM Ware I am telling you this is a serious issue and it has to stop.
So it does too for me. Thanks
It is solved yet? It seems in the post people downgrade the VMware? I think I still encounter this problem.
This worked for me - fixed everything... thanks!
I saw these issues when upgrading from vmware 16.1 to 17.5.
Since then I have rolled back to VMware 17.02.
This weekend (13th\14th Jan) I have downloaded and "upgraded" to 17.5 I had only one reoccurrence but that was after running out of memory. Which only effected one VM.This was on Windows 11 23H2, had a throtterling problem but that was fixed by disabling throttling see search for article Solved: VMWare Worksation 17.5 Pro preformance issue on Wi... - VMware Technology Network VMTN
I also had problems on Windows 10 22H2 this time completely uninstalled vmware 16 and installed 17.5 reimported a number of VMs and its stable.
The likely cause is the upgrade, maybe I should have upgraded to 17.0 or 17.0.2 first?
There is a rumour that 17.5 has had a "silent update" due to the on going merger actions with broadcom, this I cannot verify. I have no proof whatsoever and is only a rumour but all the hashes from the installers I've had all match but the build version of the install is 2.XXXXXXXXX hash matches what the web page says.
Has any one got a installer from the date released? Is the hash different? If you can post it I can check it. It will be checked in a secure way
if some could either use dropbox or google share from there GDrive I would like to test the hash.
if yo what to test the hash the current value is on the download page.
If you want to test your self a hash compare file can be found here :GitHub - rich98/hash_compare
The last point is that both hosts are fully up to date with system patches, can't rule out that the issue was being caused by windows itself.
Using the both options actually resolve the frequent freezing issue on my side.