guest serial port hangs after 2 hours of operation

[jelloshot]

Problem - The problem is that the serial communication stops anywhere between 2 to 6 hours of operation. I am using Virtualbox 7.0.12r159484 with a Windows 11 host and Windows XP 32bit professional as the guest. The software on the guest is Cimplicity version 6.0. The Cimplicity software uses the serial port (com1) to communicate to a RS232 to RS485 converter that then talks to a single GE power meter. Cimplicity software continuously collects operating data (24 hrs a day, 7 days a week). The Cimplicity software also uses ethernet communications (Bridge Adapter) and an USB-to-Modbus Plus adapter (TSX C USB MBP) to communicate with Allen Bradley and Modicon PLC's with no issues. The update rate on the ethernet and ModBus Plus communications is once per second. The update rate on the serial communications is once per 2 seconds. The problem is that the serial communication stops anywhere between 2 to 6 hours of operation. I have checked all of the port settings, (19200, 8 data bits, no parity, 1 stop, no flow control). Com port 2 in the host is mapped (host device) to Com port 1 in the guest. The only way to restart the communications is to turn off the virtual machine and restart it (I do not have to shutoff the host machine). I have tried an USB to serial port converter and a PCI express serial card. Same result. While the communications is working, I can unplug the cable and plug it back in and the communications restarts with no problems. If the communications has stopped, unplugging the cable and plugging it back in does not restart it. I have turned off all of the power saving settings that I can in the Windows 11 machine. One difference between the USB serial adapter and the PCI serial port is that when the communications hangs with the USB adapter the values go to "no data" and Cimplicity gets no values. When it hangs with the PCI serial port the last value received stays active and Cimplicity records the last value. The screen saver actions on the guest machine does not affect the serial port issue. The screen saver has been disabled on the host machine. I have tried reducing the size of and disabling the FIFO stacks for the com ports. No affect. I have noticed that if we move the mouse or interact with the guest machine in anyway, the operation time without failure of the communications is extended.

[scottgus1]

A spot of formatting (paragraphs) might make that easier to read. However, I plowed through:

I'm not certain where the connection is stopping. This is curious:

if we move the mouse or interact with the guest machine in anyway, the operation time without failure of the communications is extended.

Does this mean that the connection does not fail while the mouse is being moved inside the VM? If so, can you install a mouse mover "keep-awake" app inside the VM and see if that maintains the connection?

The screen saver actions on the guest machine does not affect the serial port issue.

Disable the screen saver inside the XP VM. It doesn't need to run, even though it is apparently not influencing the connection. Who knows, maybe it is?

I have tried an USB to serial port converter

I gather this means the USB serial adapter is run by the host OS, and the serial port is passed through to the VM. What if you pass the whole USB adapter into the VM and have the serial port directly in the VM? (Disable the serial passthrough in the VM's settings, and use USB basics and troubleshooting to pass the USB adapter into the VM.)

[jelloshot]

Scottgus1 - Thanks for responding to my post.

"does this mean that the connection does not fail..." answer - if we interact with the VM, the serial communications does not fail. I restarted it about 6 hours ago and it has not failed.

"Does this mean that the connection does not fail while the mouse is being moved..." answer - I will investigate getting a "mouse mover "keep-awake" app".

"Disable the screen saver inside the XP VM" answer: I disabled the screen saver today.

"I gather this means the USB serial adapter is run by the host OS" - the USB serial adapter does not have drivers that work with the 32 bit operating system. I tried your suggestion first.

[jelloshot]

update: With the screen saver disabled on the virtual machine and all other power saving features disabled, the serial communications ran for almost 7 days before failing (started on 01/16 at 11:00, failed 01/23 at 7:53 AM). Shut down and restarted VM machine to initiate serial comms today (01/29) at 16:47. It ran fine for about 40 minutes and shut down at 17:28.

The virtual box log does not report any issues. According to the windows Device Manager in the host and guest system, the serial port is working correctly.

Note: The original computer that the XP guest machine was imaged from is from about 2001 and had a 9-pin serial port built into the motherboard. The serial communications ran without issues continuously for over 23 years. If I unplug the communications from the new host/guest computer and plug it into the old computer, the communications works flawlessly.

An interesting observation: When I was using the USB to serial converter, when the serial communications stopped, the Cimplicity software in the guest machine did not receive any values from the virtual comm port. When I switched to the PCI express serial board in the host machine and mapped it to the same comm port in the guest (comm port 1), Cimplicity continues to get data from the comm port, but the data is frozen.

The FIFO buffers are presently set to the highest levels on the guest machine. (they match the original setup on the original XP machine.) This FIFO on the host machine is EX550.

Any recommendations on how to detect what is causing the serial communications to stop?

[scottgus1]

I don't know about troubleshooting the serial failures, myself. Perhaps a forum guru might come along who does. I haven't used serial passthrough much, though I didn't have trouble with it when I did, yet I didn't use it for days in a row either.

Meanwhile, it was good to hear that the VM ran for 7 days, and then the next failure 40 minutes later is a bummer.... So disabling power & screen controls wasn't it. No results on the mouse mover app?

It is entirely possible that there is a unique incompatibility between the USB serial adapter & PCIe adapter, with Virtualbox's serial passthrough. For example, sometimes folks on Wi-Fi cannot use Bridged, and one recommended workaround was to get a USB Wi-Fi adapter and pass it into the VM directly. Most folks had success, but one particular company's Wi-Fi adapter wouldn't work. That both of your devices fail tends to look like it's another cause, and it may very well might be, it is within the realm of possibility that the serial devices are incompatible.

On the other hand, Virtualbox may have a bug in the serial passthrough. You could try earlier versions of Virtualbox, 5.2 or 6.0, as a test, to see if the serial passthrough is more stable.

It is also extremely odd to me that the manufacturer of the serial adapter doesn't provide 32-bit drivers. Anything that comes out in the 64-bit era isn't going to use serial. And anything that uses serial would have been quite used to 32-bit OS's. I'd recommend finding out what chip is inside the USB serial adapter and look for generic drivers for that chip. Or look for a different USB serial adapter that does have 32-bit drivers. Note that if your result of not finding 32-bit drivers was because XP's New Hardware wizard couldn't find them, that's probably because XP can't get on the modern internet anymore, rather than there's really no 32-bit drivers for the adapter. I have greater hope for your getting good serial through the USB adapter passed into the XP VM directly through USB filters.

One last thing:

The FIFO buffers are presently set to the highest levels on the guest machine. (they match the original setup on the original XP machine.)

I'd try setting these back to default settings. It's also possible this is an incompatibility with Virtualbox.

[fth0]

I don't know about troubleshooting the serial failures

I don't know much about it either (except for having used real serial ports in the distant past), but I can provide a few different hints:

To run the VM with some additional logging, open a Windows Command Prompt with normal user privileges and enter the following commands:

Code: Select all

cd "C:\Program Files\Oracle\VirtualBox"
set VBOX_RELEASE_LOG_FLAGS="thread flag group"
set VBOX_RELEASE_LOG="+DEV_SERIAL.e.l.f+DRV_HOST_SERIAL.e.l.f+MAIN_SERIALPORT.e.l.f"
VirtualBoxVM --startvm "VM name"

Please reproduce the issue and provide a (zipped) VBox.log file from the VM run with these settings.

According to the VirtualBox User Manual, by default VirtualBox provides a virtual 16550A UART to the VM. 16540 and 16570 are available as alternatives. I don't know how different FIFO sizes on the host and in the guest interact with each other.

If you're using more than one virtual serial port, note that COM1 and COM3 share an IRQ, just like on a real PC of the time.

[jorgensen]

The problem is that the serial communication stops anywhere between 2 to 6 hours of operation.

If you request an extremely stable RS-232 connection for the VirtualBox XP client, I have two suggestions.
1: Update the XP client to use USB 3, and install the USB driver for an USB to RS-232 converter at the guest system.
2: Use a RS-232 to Ethernet converter and install the required RS-232 driver at the XP guest - link
The later is somewhat expensive and take some time to configurate - but then it is extremely reliable.

[AndyCot]

Sounds like the USB to RS232 may be using a buggy chipset. I have found that FTDI chipsets work very well, but other chipsets I have seen exactly the problem you are describing where the RX/TX stop and all you have to do is unplug the adapter and plug it back in.

The driver versions can also cause the crash to occur more often with non FTDI chip sets.

I last used a USB to RS232/RS422 was about 6 years ago.

Are you using an FTDI based USB t RS232 adapter or not? If not try an FTDI based one.

[ScannerDev]

Different hardware setup, same issue:

I run both Win7 Pro (32 bit) and XP Pro/SP3 VMs which host a radio scanner control program. The host system is Mint 21.3; VB version is 7.0.14. Motherboard has two physical serial ports, and each of these has a radio scanner attached.

I'd begun to notice com dropouts several weeks ago. The program in use continually polls the scanners and they return status, or it commands them to perform operations via strings of data. A bit of history: Somewhere around the 6.1.4x version, there was a DEVIOCTL problem fixed with serial devices whereas they wouldn't operate for more than a few seconds without throwing an error. Once this was addressed, the connected scanners and programs ran without error for months.

I'd upgraded the hosts to VB 7.0.10 last fall with similar results. Just kept working. 7.0.14 seemingly broke it. Failure time is now as little as 12 hours, regardless of which physical port is used to control the scanners - or which Windows guest is running.

Will be happy to generate and collect logs as required.