Serial ports (uart) don't work after upgrading from 5.2.22 to 6.0.0 and 6.0.2 -> fixed in SVN/next maintenance

[Vonkaz]

Serial ports (uart) don't work after upgrading from 5.2.22 to 6.0.0 and 6.0.2.

Host: Win10 Pro x64 1809 17763.253, COM1 native on motherboard COM2 and COM3 - using FTDI adapter.

Guest: Win10 Pro x86 1809 17763.253

Virtual Box 5.2.22 works correctly.

Virtual Box 6.0.0 does not work correctly. Opening a connection to serial ports from guest works very very slowy. After a few seconds, "VirtualBox interface" crashes with memmory violation and system automatic closes the "VirtualBox interface" background process.

Serial ports doesn't work at all on VB 6.0.2.

[Koala]

Almost the same issue here, Host windows 7 Guest Windows XP using "Host" mode on serial COM1 Works fine in 5.2.24 doesn't work or crash VirtualBoxVM.exe on host "Memory address can't be written" in version 6.0.0 or 6.0.2.

[aeichner]

Can you please upload the VBox.log of the crashing VM?

[draxie]

I have the corresponding issue for both Linux and MacOS. I've been using --uartmode1 /dev/tty on both platforms for years. On 6.0.x, this gives the following error:

Error: failed to start machine. Error message: Failed to open host device '/dev/tty' (VERR_INVALID_PARAMETER)

Minimally redacted VBox.log is attached (this one comes from a Linux host, but I experience the same problem on MacOS as well).

If you decide to fix this, I've been hoping for the same functionality on Windows as well (i.e. --uartmode1 CON:), but that never worked for me.

[hykwok]

I also have this issue for Linux Guest with Windows 7 host. The VM image works well in the VirtualBox 5.x version.

[aeichner]

Replying to draxie:

I have the corresponding issue for both Linux and MacOS. I've been using --uartmode1 /dev/tty on both platforms for years. On 6.0.x, this gives the following error:

Error: failed to start machine. Error message: Failed to open host device '/dev/tty' (VERR_INVALID_PARAMETER)

Minimally redacted VBox.log is attached (this one comes from a Linux host, but I experience the same problem on MacOS as well).

If you decide to fix this, I've been hoping for the same functionality on Windows as well (i.e. --uartmode1 CON:), but that never worked for me.

Your issue is not related to the crash on Windows but something different. This will be fixed in the next maintenance release.

[aeichner]

I can't reproduce the crash on Windows hosts with my test setup, upload a VBox.log and crash dump if available.

[draxie]

Replying to aeichner:

Your issue is not related to the crash on Windows but something different. This will be fixed in the next maintenance release.

That is entirely correct. My issue is on Linux, and the VM doesn't even start, but I experience a similar high-level effect: the serial port used to work, but doesn't work anymore.

I'm glad this will be fixed soon!

BTW, will you also support --uartmode1 CON: on Windows?

[hykwok]

New version (6.0.4) did not solve the problem in my case. The log file is attached for reference.

[aeichner]

Still not reproducible for me. Can anyone who experiences the crash reliably provide some additional information what the exact setup on the host is (used sierl port hardware, involved serial devices or if loopback setup, port settings used for communication, etc.)?

[hykwok]

log for the testing case

[hykwok]

I wish the following procedure can help you to find the cause of the problem:

1. Setup Host environment:
   

In my case, the host system is Windows 7 64 bits.

1.1 Download Virtual COM Port Driver (Standard Demo version) from here: ​https://www.eltima.com/products/vspdxp/
1.2 Install Virtual COM Port Driver and create a pair of Virtual COM Port (In my case, they are COM2 and COM4)
1.3 Downlaod Putty (Windows version) from here: ​https://putty.org/

2. Create Ubuntu 18.04 with Virtual Box 5.2.26
   

2.1 Install VirtualBox 5.2.26
2.2 Create a virtual machine that uses Ubuntu 18.04.
2.3 Enable serial port 1 for this virtual machine and set the "port mode" to "Host Device" and the "path/Address" to one of the above virtual COM port (in my case it is COM2)
2.3 Install putty package:

sudo aptitude install putty
sudo aptitude install putty-tools

3. Start the first testing
   

The COM setting is 9600-8-N-1, no flow control

3.1 Start putty windows version and connect to another virtual COM port (in my case it is COM4).
3.2 Start putty linux versio: sudo putty
3.3 After both putty applications are started, send a byte from Linux to Windows host to make sure the virtual COM connection works.
3.4 If the connection is OK, then try to send data from Linux to Windows host repeatedly. In my case, the VirtualBox does not crash after 600 bytes are sent from Linux to Windows host.
3.5 Close both putty applications and shutdown the Virtualbox

4. Update VirtualBox from 5.2.26 to 6.0.4
   

4.1 Install VirtualBox 6.0.4
4.2 reboot the host system

5. Start the second testing
   

The COM setting is 9600-8-N-1, no flow control

5.1 Start the above virtual machine
5.2 Start putty windows version and connect to another virtual COM port (in my case is COM4).
5.3 repeat steps 3.2, 3.3 and 3.4
5.4 In my case, the virtualbox will be crashed after 200 bytes are sent from Linux to Windows host.

If you reinstall the VirtualBox from 6.0.4 to 5.2.26, you will find that the problem is not found.

[Couryrr]

Have this issue on a Windows 10 Host using Vagrant to provision. I did not see the error but the machine never boots the load time is incredibly long. Vagrant times out waiting and I have not waited long enough to see it finish via the GUI 45 min max.

Running in VirtualBox 6.0.4r128413 With Vagrant 2.2.3 (not really a factor just convenience)

In the Vagrantfile I have vb.customize [ "modifyvm", :id, "--uartmode1", "disconnected" ]

The Ubuntu images here: ​https://app.vagrantup.com/ubuntu/boxes/bionic64 ​https://app.vagrantup.com/ubuntu/boxes/xenial64

Removing the line vb.customize [ "modifyvm", :id, "--uartmode1", "disconnected" ] from the Vagrantfile allows the machine to boot successfully and in a reasonable amount of time.

Dropping back down to VirtualBox 5.2.26 successfully let both images boot with the line vb.customize [ "modifyvm", :id, "--uartmode1", "disconnected" ].

Admittedly I am not a server admin so I do not have a detailed log at the moment but whatever information is needed I will assist in gathering.

[aeichner]

I was able to reproduce the crash and hopefully fixed it for the next maintenance release. There is a 6.0 test build available on the Testbuilds page. Would be great if a few people could try it and report back, thanks!

[Couryrr]

Can you confirm the version from the test build page? I tried both the https://www.virtualbox.org/download/testcase/VirtualBox-6.0.5-128870-Win.exe https://www.virtualbox.org/download/testcase/VirtualBox-6.0.97-128834-Win.exe

and experienced the same outcome when I have the below line the machine does not boot vb.customize [ "modifyvm", :id, "--uartmode1", "disconnected" ]

When I do not have that line the machine boots fine.

Replying to aeichner:

I was able to reproduce the crash and hopefully fixed it for the next maintenance release. There is a 6.0 test build available on the Testbuilds page. Would be great if a few people could try it and report back, thanks!

[aeichner]

Well, as you didn't report any crash but a slow down/hang I wouldn't assume that the builds fixed your issue. Can you upload a VBox.log of the affected VM to this ticket?

[Couryrr]

I created a gist of my latest error log here: ​https://gist.github.com/couryrr/01847017253f9f4500a1e5642d47e495

Replying to aeichner:

Well, as you didn't report any crash but a slow down/hang I wouldn't assume that the builds fixed your issue. Can you upload a VBox.log of the affected VM to this ticket?

[hykwok]

1. Configuration:

VirtualBox uses COM2 while Putty (Windows version) uses COM4

2. My Testing Procedures:

2.1 Started virtual COM Port application
2.2 Started Putty (Windows Version)

3. VirtualBox 5.2.26

3.1 Started the testing virtual machine (Ubuntu 18.04.02)
3.2 Started Putty (Linux version): sudo putty
3.3 Tried to send 10 bytes from Linux to Windows
-> Windows side received 10 bytes
3.4 Tried to send 10 bytes from Windows to Linux
-> Linux side received 10 bytes
3.5 Tried to send 10 bytes from Linux to Windows
-> Windows side received 10 bytes
3.6 Tried to send 10 bytes from Windows to Linux
-> Linux side received 10 bytes

3.7 Closed Putty (Linux version) and shutdown the virtual machine

4. Virtual 6.0.5 r128870

4.1 Started the testing virtual machine (Ubuntu 18.04.02)
-> 46 bytes was sent from VirtualBox to Windows during booting
-> VB 5.0.26 did not have this action
4.2 Started Putty (Linux version): sudo putty
4.3 Tried to send 10 bytes from Linux to Windows
-> No data was sent to Window side
4.4 Tried to send 10 bytes from Windows to Linux
-> Windows side received the data suddenly from Linux
-> Linux side received data
4.5 Tried to send 10 bytes from Linux to Windows
-> Windows side received 10 bytes
4.6 Tried to send 10 bytes from Windows to Linux
-> Linux side received 10 bytes

In conclusion, the crash problem is likely fixed but the serial port simulation is NOT work properly.

1. Some unexpected data is sent from the virtual machine (Linux) during booting (5.2.26 does not have this problem)
2. The virtual machine will not send any data to another side (MS Windows) until it receives some data from another side. (5.2.26 does not have this problem)

[aeichner]

Please try the latest build from here. That should at least fix the garbage output, I wasn't able to reproduce the second issue but it could very well be fixed too now.

[hykwok]

I have tested the VirtualBox 6.0.5 r128999 and the communication problem is fixed in my case.
On the other hand, please add the "Serial Ports" settings to the "Details" page if possible.

[Socratis]

The "Serial ports" options *are* in the Details page. Maybe you don't have them showing? Right-click on a free-space somewhere in the free space in the Details view; you have several options on what's showing or not. Make sure that the "Serial ports" is enabled...

[hykwok]

Thanks for your hint
Actually, I did not know VirtualBox has this option panel because I could not find any document for this feature.....

[Socratis]

You're right, I don't think it's documented anywhere. It's one of those... accidental discoveries that I made. ;)

[Vonkaz]

Replying to aeichner:

I was able to reproduce the crash and hopefully fixed it for the next maintenance release. There is a 6.0 test build available on the Testbuilds page. Would be great if a few people could try it and report back, thanks!

I have checked the 6.0.5 revision 128999 test build and in my environment serial ports work properly again :o) great job. Testing cost me a lot of patience because my guest machine works very slowly.

This problem with guest machine performance appeared with 6.0.x versions. The log file is full of "TM: Giving up catch-up attempt at a "x" ns lag; new total: "y" ns" I created a new bug ticket #18460.

[adynes]

Just wanted to chime in and say the 128999 test build also fixed my issue. I had a Windows XP 32-bit SP3 guest running both a old 16-bit DOS program and a 16-bit Windows program that both used the serial port. Neither worked on 6.0.* but the new test build fixed the issue and I can communicate through the serial port form the guest to the host without issues now. Thanks!

[hykwok]

I found another bug for VB 6.0.5 r129304.....

1. Configuration:

VirtualBox uses COM2 while Putty (Windows version) uses COM4

2. My Testing Procedures:

2.1 Start virtual COM Port application
2.2 Start Putty (Windows Version) in the host system
2.3 Start virtual machine (Ubuntu 18.04)
2.4 In the Putty (Windows Version), send 40 bytes from the host (Windows) to the guest (Linux)
2.5 Start Putty (Linux version) in the guest system

Then when you send the data from host's Putty (Windows) to the guest's Putty (Linux), the guest's Putty (Linux) does not show what you just inputted. However, it will show the "cached" old data.

If you use VB 5.2.26, you will not get this bug.