mboekhold's Posts

@GMi_ wrote: One trick to fix this: launch the VM after a cold start of my computer. I've noticed this as well. The issue only seems to appear after I suspend/resume my laptop. Immediately after a fresh reboot the VM runs fine for the rest of the day.

Nope, froze after only 23 minutes with the dreaded: 2022-12-16T06:25:45.119Z In(05) vmx GuestRpcSendTimedOut: message to toolbox timed out. 2022-12-16T06:25:45.119Z In(05) vmx Tools: [AppStatus] Last heartbeat value 1360 (last received 1s ago) 2022-12-16T06:25:45.119Z In(05) vmx TOOLS: appName=toolbox, oldStatus=1, status=2, guestInitiated=0.   This time I was able to suspend/resume the VM. "sudo dmesg -T" shows lots of soft lockup errors (warnings?), like before:   [Fri Dec 16 11:27:06 2022] watchdog: BUG: soft lockup - CPU#1 stuck for 3408s! [vmtoolsd:1032]   So unfortunately, this issue still has not been fixed, and I'm still stuck with an expensive product that I can't even use as a paperweight   Edition Windows 10 Enterprise Version 22H2 Installed on ‎2021-‎09-‎15 OS build 19045.2251 Experience Windows Feature Experience Pack 120.2212.4180.0   Hyper-V is enabled, but I can't run the commands to show you because I can't run Powershell in Admin mode

Unfortunately, I celebrated too early (again). Last night everything was running OK when I suspended my laptop (without first suspending the VM). This morning I resumed, the VM seemed to run OK but then became really sluggish until at completely froze again. The 'old trick' of suspending and resuming the VM to get it to work again does not work this time: VMWare Workstation fails to resume the VM. I'm hoping this is just because I suspended my laptop, so I've just relaunched the VM and will keep it running all day today. FYI, I don't see any (obvious) error messages from: less /var/log/dmesg.0 journalctl -o short-precise -k -b -1 VMWare log file contains the following at the time the VM becomes completely unresponsive: 2022-12-16T05:57:48.671Z In(05) svga MKS Win32: Turned off high resolution system timer. 2022-12-16T05:59:10.247Z In(05) vmx GuestRpcSendTimedOut: message to toolbox timed out. 2022-12-16T05:59:10.247Z In(05) vmx Tools: [AppStatus] Last heartbeat value 32511 (last received 4s ago) 2022-12-16T05:59:10.247Z In(05) vmx TOOLS: appName=toolbox, oldStatus=1, status=2, guestInitiated=0.

Updated to 16.2.5 this morning, and my main Ubuntu MATE 22.04 VM has been running stable for 3 hours now. Since this issue started, I've never been able to keep it running for more than 20 minutes, so it seems the issue is solved. Strangely, the Release Notes do not mention this issue at all...

Updated to 16.2.5 this morning, and my main Ubuntu MATE 22.04 VM has been running stable for 3 hours now. Since this issue started, I've never been able to keep it running for more than 20 minutes, so it seems the issue is solved. Strangely, the Release Notes do not mention this issue at all...

Myself and others have been experiencing the same issue for well over a month now. Seems to be the same as the issue reported in https://communities.vmware.com/t5/VMware-Workstation-Pro/VMWare-Workstation-16-Pro-Ubuntu-22-04-1-VM-unresponsive-with/td-p/2930676/page/3.  

Struggling with this issue as well. If anybody from VMWare is interested, I can post an extract from the kernel messages with the CPU soft lockups. There is lots of information being dumped... Note that I cannot disable Hyper-V. Corporate laptop, Hyper-V required for many things...

Unfortunately, I celebrated too early. This morning I resumed my laptop from sleep, started VMWare Workstation again and launched my VM. It hang again after a short while. I'll just monitor upcoming updates to Workstation and retest periodically. As it is, VMWare Workstation is useless to me.

Hi @wila, thanks for the suggestion. I tried this, and unfortunately it does not help. My VM froze again after 15 minutes... I checked my Windows host update history, and it is possible that this issue started with the installation of the 21H2 update (coming from 21H1). More guest details, in case this can help: boekhold@boekhold /etc $ uname -a Linux boekhold 5.15.0-48-generic #54-Ubuntu SMP Fri Aug 26 13:26:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux boekhold@boekhold /etc $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=22.04 DISTRIB_CODENAME=jammy DISTRIB_DESCRIPTION="Ubuntu 22.04.1 LTS" boekhold@boekhold /etc $ cat /etc/os-release PRETTY_NAME="Ubuntu 22.04.1 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04.1 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" UBUNTU_CODENAME=jammy  

Following up on myself, here are 2 screenshots taken from the Clock window inside my frozen VM, taken 10 minutes apart: As you can see, the clock has jumped. But it is not regularly updating, it only happens in big jumps. And I still cannot interact with the VM. When the VM hangs, I can see vmware-vmx.exe suddenly taking 25% CPU, on an 8-core/16-thread system:  

I've been having the same issue where my Ubuntu MATE 22.04 guest VM constantly freezes. This is on a Windows 21H2 (OS Build 19044.2006) host, with VM Workstation 16.2.4 build-20089737. This happens regardless of the activity of the Guest VM, e.g. it even freezes when left idle after boot. This started a few weeks back after I had a few Windows updates forced onto me (corporate laptop...). I let the guest sit idle except for a Clock running, to try to identify when the VM started to hang. And after about 20 minutes, I was not able to interact with the VM anymore. The VMWare log file contains around the time of the hang: 2022-10-10T06:49:57.489Z In(05) vmx Tools_SetGuestResolution: Sending rpcMsg = Resolution_Set 2479 1363 2022-10-10T06:51:05.220Z In(05) vmx VNET: MACVNetLinkStateEventHandler: event, up:0, adapter:1 2022-10-10T06:51:05.220Z In(05) vmx VNET: MACVNetLinkStateEventHandler: 'ethernet0' state from 5 to 7. 2022-10-10T06:51:05.220Z In(05) vmx VNET: MACVNetLinkStateEventHandler: event, up:1, adapter:0 2022-10-10T06:51:05.220Z In(05) vmx VNET: MACVNetLinkStateEventHandler: 'ethernet0' state from 7 to 2. 2022-10-10T06:51:10.230Z In(05) vmx VNET: MACVNetLinkStateTimerHandler: 'ethernet0' state from 2 to 6. 2022-10-10T06:51:10.331Z In(05) vmx VNET: MACVNetLinkStateTimerHandler: 'ethernet0' state from 6 to 1. 2022-10-10T06:51:15.364Z In(05) vmx VNET: MACVNetLinkStateTimerHandler: 'ethernet0' state from 1 to 5. 2022-10-10T07:07:25.411Z In(05) vmx GuestRpcSendTimedOut: message to toolbox timed out. 2022-10-10T07:07:25.411Z In(05) vmx Tools: [AppStatus] Last heartbeat value 1095 (last received 14s ago) 2022-10-10T07:07:25.411Z In(05) vmx TOOLS: appName=toolbox, oldStatus=1, status=2, guestInitiated=0. 2022-10-10T07:07:29.775Z In(05) vmx GuestRpcSendTimedOut: message to toolbox-dnd timed out. 2022-10-10T07:07:29.775Z In(05) vmx TOOLS: appName=toolbox-dnd, oldStatus=1, status=2, guestInitiated=0. 2022-10-10T07:07:45.413Z In(05) vmx GuestRpcSendTimedOut: message to toolbox timed out. 2022-10-10T07:07:45.413Z In(05) vmx GuestRpc: app toolbox's second ping timeout; assuming app is down 2022-10-10T07:07:45.413Z In(05) vmx Tools: [AppStatus] Last heartbeat value 1098 (last received 13s ago) 2022-10-10T07:07:45.413Z In(05) vmx TOOLS: appName=toolbox, oldStatus=2, status=0, guestInitiated=0. 2022-10-10T07:07:45.420Z In(05) vmx GuestRpc: Reinitializing Channel 2(toolbox) Something more weird is that there does seem to be some activity inside the guest VM. I have seen it update the time in the Clock application that I have open at least once. But I can't interact with the VM at all. Unfortunately, I only have a NAT network interface configured on the VM, so I can't check if it responds to network traffic. I doubt it though... FYI the openvm-tools are running inside the VM... 

Hi all, VMWare Workstation 7.1.5 VMWare Tools 8.4.8-491717 Guest Linux kernel 2.6.39, 3.0 Compile error, spin lock (including a bunch of information to make this thread easier to find with google) I am suffering from the same issue. Basically I cannot reasonably use a paid-for product anymore. If you look at the following comment on weltall's blog: http://weltall.heliohost.org/wordpress/2011/06/26/vmware-7-3-4-guest-modules-fixes-for-linux-2-6-39-and-3-0/#comment-229, you will see that somebody managed to massage the original patch from weltall to make the VMWare Tools from Workstation 7.1.5 compile with a 2.6.39/3.0 kernel. Unfortunately he did not post his "patch for the patch" as a file, but used copy/paste, which messed up the patch-file-format to such an extend that it doesn't apply anymore to weltall's patch. I have attempted to manually apply this "patch for the patch", but unfortunately failed. Perhaps somebody with a better understanding of the patch file format could have a look at this? I think that if an update to Weltall's patch specifically for VMWare Tools 8.4.8-491717 can be created, a lot of users would be very happy. I've also tried to find a way to contact the "bercin" who created this "patch for the patch" to ask for further help, but have not been successful in that either. Edit: Now, would you imagine. After writing this comment, I decided to read the wikipedia page on the unified diff format, and I've managed to manually apply that "patch for the patch", and compile the VMWare Tools 8.4.8-491717 for Linux kernel 3.0.0-1-686-pae (this is Linux Mint Debian Edition). If you want to repeat this yourself, first go to Weltall's blog (link above) to download the original vmware2.6.39guest.tar file (which is actually compressed with bzip2).  Extract that, and then replace the vmwareguest2.6.39.patch file with the version attached. Finally run (as root) the patch-modules_2.6.39.sh script, which will automatically patch the modules and build them for you. Note that if your VMWareTools are not installed in /usr, you will need to edit the shell script (2 places) to correct some hardcoded paths. Maarten Message was edited by: mboekhold