VM crash after KVMS switch

[Harry M]

See ​https://forums.virtualbox.org/viewtopic.php?f=7&t=104891&sid=51cd5f0216603e8bec8562fd1da4b3bc for more information.

Environment:

I have multiple PCs connected by a keyboard-video-mouse-switch (KVMS, to clearly distinguish from kvm, the kernel virtualization subsystem). The KVMS is a FJGear USB2.0 HDMI KVM model FJ-401HUA. I will refer to these PCs as A, B, and C. All 3 boxes are hosting Devuan Beowulf, and all VMs running on all boxes are running Devuan Beowulf Ascii, Beowulf, or Chimaera under virtualbox 6.1.30. All hosts are running the latest virtualbox extensions, and guests are running the latest virtualbox guest additions.

Description of the Problem:

The problem is that switching between two of these boxes causes a VM running USB 3 to crash. After an initial switch from A to B and back to A, one VM running USB 3 on A had crashed. In one instance, switching a second time after this from A to B and back to A, all but one VM running USB 3 had crashed and even a VM running USB 2 had also crashed.

Detail:

I run virtualbox on PCs A and B. I use PC A for most of my regular activities; B and C are "test" boxes. However, despite B being a testbox, I do have the VMs on B networked together with some of the VMs on A. The 3 PCs are networked through an electronic ethernet switch.

The KVMS does work, although there is a bit of a wait for the video to re-sync after a switch. The KVMS is capable up to 1920x1080, which matches my monitor's resolution. Normally, I don't notice any peculiar behavior related to using the manual buttons on the face of the unit. There are some messages logged after each switch, but they have never caused an issue until I changed the VM (the one that crashed) to USB 3.

I have attached the log for the crashed VM (see above link). These logs were created by saving them from the log dialog box in the virtualbox GUI. I have not modified them other than to obfuscate private information. The logs are cut short for some reason, but it is NOT related to the obfuscation script. I can save the logs again, from the GUI again, and the same results occur. The line counts of the log files match before and after obfuscation.

[Harry M]

VM crash after kvms switch

[galitsyn]

Hi HarryM,

Do you still see this issue with VirtualBox 6.1.42 or 7.0.6? If so, could you please attach fresh VBox.log and check if there is anything in host system logs (dmesg, journalctl)?

[systemdlete]

Just happened again. Log attached.

I note that the date on the log file is from 4 days ago. When I reboot the crashed VM, I look at the dates of some directories and files I created that day, so that does square--I really thought I'd been on that box since then, but I guess not. It is a test box with a couple of test VMs only. I don't really use it for much except, well, testing stuff, and a little development. I don't ordinarily even backup the host or VMs on that machine.

Looking at the VM's Logs subdir, I see that the dates on the most recent log file are from 4 days ago also. So, I assume that after my last visit to that machine (using my KVMS), the VM had crashed then.

[systemdlete]

I'm looking back at the history, and a couple of things. I have changed Oracle IDs. Also, I am now running vbox 6.1.42 (and the GAs for that version inside the VM). And I have a totally different KVMS now. It's a no-name but I can give you the specs if you think they would be helpful.

The bug might not have anything to do with using a KVMS. Perhaps it is something peculiar about the mainboard, because my other PC does not experience this problem. I am thinking that maybe the USB was faulty. I have some spare boards here and I could probably stand to upgrade the CPU as well. Just for complete disclosure, I run some older hardware here. The test box in question has a Thuban (Athlon) X6 with 32GB memory. I have checked and the system does have ample disk space on the host as well as the guest.

What is also interesting is that if I leave the VM in windowed mode, it doesn't seem to have the crashing problem. Normally, I run that VM in full screen mode. The only other VM running there is always windowed mode, and it never crashes. It is inconsistent, though. It only crashes sometimes when in full screen mode.

Another thing to note. I recently rebuilt the VM from scratch. In essence, the VM is brand new, with fresh virtual disks, etc. Yet, the crashing problem persists.

Thank you for your help with this.

[systemdlete]

The video card on the test box is not built-in. It's an add-on card. lspci shows

01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS780L [Radeon 3000]

Since the problem only occurs (but not always) when in full-screen mode, I am thinking that this could be related to the video card.

I am running the VM with VMSVGA, 128MB. I have tried it with both 3D enabled and without 3D disabled.

[galitsyn]

Hi systemdlete,

Do you have a coredump or a backtrace?

[systemdlete]

/usr/lib/virtualbox/VirtualBoxVM is setuid root, so (according to web search re core) no core file will be produced.

This IS a test box, so I could fudge with the thing a bit. If I remove the setuid, though, vbox probably will have fits and problems running. And running vbox as root might produce different results than for the regular user normally running it (my test user).

I am willing, but please advise on how to proceed. Thanks for your ongoing support.

[Klaus Espenlaub]

I have to ask... how sure are you that it's really USB? Yes, there are quite a few subtle and not so subtle differences between the operation of USB2 and USB3 which can result in behavior differences in the emulation including triggering some unknown bugs.

However, since your KVM switch is HDMI I have a different suspicion (simply because there have been multiple issues in this area): could it be audio? Have you tried running with audio fully disabled?

[galitsyn]

Hi systemdlete,

Please refer to https://www.virtualbox.org/wiki/Core_dump. There is a hint on how to get coredump for setuid process.

[systemdlete]

I have run into a new problem with the test VM crashing: It no longer crashes.

I had rebooted the test box host to see if (maybe) logging in directly at the command prompt and setting ulimit -c there might get me around the core dump problem (that was BEFORE you suggested the "hint"; thanks for that, and I WILL try that if the opportunity comes up again).

As far as the audio. It's kind of odd, but I did fiddle with audio on the test box host. I had unplugged the audio in on the speaker running from the test box. So that sounds possible, but... is that audio issue limited to USB by any chance? I tried plugging and unplugging the same connector a few times, switching back and forth between PCs, but I could no duplicate the problem anymore this way either. I have a rather old speaker system (1990s vintage, which still works perfectly) that uses the old RCA(?) connectors directly from the PC computer out port to one of the audio in ports on the right speaker (it has INPUT 1 and INPUT 2). I did not change the in port to the speaker to the other in port during my testing.

So now I can not reproduce the problem... I've encountered this in the past, btw. It is strange that the problem will manifest itself--consistently!--until... something happens, which I cannot ascertain (sorry; I am watching my own movements closely now, I promise).

[Harry M]

It's baaaaaaack! But this time on a different physical host.

I am noticing that there seems to be some problem with the auto-resizing function--it does not always work right, and that's about the same time I experience the crashing.

Out of sheer frustration, I rebooted the host (after shutting down the VMs properly, of course) and the problem disappeared.

Not sure that this post provides much more help, and I didn't have a chance to take the core dump as you requested. I was trying to troubleshoot just the auto-resizing first and come back to the abort problem afterward.

I will get a core dump, per your instructions, above, if this re-arises.