Serial device data not transmitted to Win XP guest => fixed in SVN/next maintenance

[ruga]

VirtualBox V5.1.14 Host: Win 7 Ultimate Guest: Win XP Pro

We attach a power supply unit (PSU) to serial port COM1 of the physical machine running Win 7. The PSU sends status data to COM1 permanently.

In the guest (WinXP) the virtual serial port COM1 is mapped to the real serial port COM1. This is the serial port configuration in the guest:

"Enable Serial Port": Checked

"Port Number": COM1 IRQ: 4 I/O Port: 0x3F8

"Port Mode": Host Device

"Connect to existing pipe/socket": Checked

"Path/Address": COM1

In the guest an application should monitor the state of the PSU.

Now the Problem: When we start the VM the application doesn't receive the status data initially. :( Only if we send any character from the VM to COM1, the status data is received by the monitor application as expected. Further we can see, if we don't send a character to COM1, close the VM and start it again, the PSU status data is received at once. This succeeds as long as we don't reboot the host. After rebooting the host the next time and starting the VM receiving the PSU status data fails again.

It seems, that VirtualBox requires sending some data to the serial port first, before it is able to receive data from the serial port.

By the way, running the monitoring application in the host works perfectly.

We have deeper analyzed the problem by watching the IOCTL traffic. The results are described in detail in the forum thread ​https://forums.virtualbox.org/viewtopic.php?f=2&t=84667&sid=a6eb50e33e626459cd4dbf1a3748cc5f&p=402188#p402188

There you will also find screenshots showing the critical IOCTL sequences.

Many thanks !

[ruga]

VM Logging

[ruga]

VM Settings

[ruga]

Source with log statements

[ruga]

Log file

[ruga]

Now, we could strip down the erroneous scenario a little bit more by adding logging statements to the VirtualBox source and building the VirtualBox binaries.

In VirtualBox function drvHostSerialConstruct (module DrvHostSerial.cpp) the COM port is opened and the send / receive threads are created.

Directly afterwards, the COM port status returned by Windows API function GetCommModemStatus shows an unusual status code, if the power supply unit (PSU) is firing data permanently (it’s our use case). The status code is sometimes 2, sometimes 6. Both are undocumented code values. But they represent a COM port status, in which no data is received by the application (here VirtualBox) having opened the COM port !

In contrast, if we add Windows API function calls of GetCommState and SetCommState (with unchanged DCB structure, i.e. unchanged COM port settings) behind the GetCommModemStatus call (or directly behind the CreateFile call), the COM port status is a correct one. A subsequent GetCommModemStatus call successfully returns showing no COM port status error. All data sent by the PSU are received by VirtualBox.

Attached file DrvHostSerial.cpp shows the modified VirtualBox source module, attached file VBox.2.zip is the log written by using the call sequence described above.

If we close the COM port afterwards and open it once more, the scenario is erroneous again: calling GetCommModemStatus will show a COM port status error.

I.e. after opening the COM port by CreateFile, a GetCommState call and a subsequent SetCommState are necessary to make the COM port status an operable one. Of course, alternatively VirtualBox function drvHostSerialSetParameters can be called, initializing the COM port parameters in an appropriate manner by calling SetCommState.

Therefore, could you please initialize the COM port status (by a drvHostSerialSetParameters call) directly after having opened the COM port by CreateFile ?

[aeichner]

Please try the latest development snapshot from here (revision r119645 or higher, upload is still in progress). I did a quite different fix which should hopefully still work for your case. We now sync the communication parameters everytime the serial device emulation is reset to prevent that the serial device emulation and the underlying hardware have different settings active..

[ruga]

We’ve tried the development snapshot 120150 and … The snapshot is great !

Now, in the VM the permanently sent PSU status data is received also when the VM is started for the first time after a preceeding reboot of the host (Win7).

We’re very happy ! Thanks a lot !

Do you already know, which release version will include this bugfix ? By the way, test build 120181 doesn’t seem to include the bugfix. It still behaves buggy.

[aeichner]

The fix will be included in the next 5.2.x and 5.1.x maintenance release. Unfortunately your feedback came a day to late and we were already in the process of preparing 5.2.6 so the fix couldn't be backported anymore. I created new testbuild from the 5.2 and 5.1 branch which includes the fix. You can download the packages here.

[ruga]

Many thanks for the info and your assistance !