5.x regression? SetCommTimeouts ignored

[ucrasher]

Hi,
I use USB devices with ComPort emulations a lot (CDC-ACM).
Since VB5 it looks like the SetCommTimeout is not working anymore. Strange is that sometimes it seems to work.
Though I cannot imagine how VB could disturb the timeouts.

It is not directly a guest OS driver issue:
Win10 uses usbser.sys (comes with OS)
Win7 uses a customer driver since that usbser.sys was buggy in these older OS versions.
Both VMs expose thew same behavior: Read returns even before the timeout expired, so sometimes it does not catch the received byte if it comes a little later.

Host is Ubuntu 14.04.

SetCommTimeout:
https://msdn.microsoft.com/en-us/librar ... s.85).aspx

These timeout setting worked since about 1998 if I recall correct (at least from Win2000 on).
ReadIntervalTimeout=500;
ReadTotalTimeoutMultiplier=10;
ReadTotalTimeoutConstant=500;

Any Hints are very welcome.

[Perryg]

These kinds of problems that are reproducible should be reported to bugtracker.
It would also help if you can post the ticket number here so other can see the progress, add information, or see the final results.

[mpack]

Since VB5 it looks like the SetCommTimeout is not working anymore.

Dubious. Comm timeouts are not a hardware feature (the NS8250/NS16550 UARTs do not include a programmable timer), so this is a feature of the guest OS. Therefore I find it hard to see how any bug of VirtualBox could stop this feature working. If timers in general had stopped working in the guest then that would have very serious - and very noticeable - consequences for all users.

[ucrasher]

I agree 100%
The timeouts for Com-Ports are a Windows feature.
My plan is to write a demo app that can be used to duplicate. But you need a device connected. If the devs needs such a device I will be happy to provide one (I live close to Endersbach if they are still there).

I also located a PC with the older VB 4.3 for a regression test.

There is also something not correct with the emulated RTS/CTS lines. With the analyzer I can proof the device sends the correct reports and on a native machine they come out correctly from the API. This needs more research to be sure it is not one of these finger pointing games.

[mpack]

A discussion of RTS/CTS etc would be a different kettle of fish because that is hardware. Note however that details of the host would be needed, i.e. it would be important to know if these ports were real or themselves emulated in some way, e.g. by USB adapters.

[ucrasher]

Hi,
this is emulated RTS/CTS. A USB CDC-ACM device sends reports via an (USB) interrupt endpoint (SendSerialState) and the driver translates that into changes of the "modem" status.
But I agree this might be a different root cause.
The device sends this reports correct, but somehow the VM looses it. I plan on checking with the VB USB tracer.

[mpack]

And are you accessing these USB adapters as USB devices, or as host serial ports?

Assuming the former, this is sounding more and more like you have a buggy USB driver in the guest. Possibly the unexpected additional latencies of a VM causes it.

[ucrasher]

USB devices passthrough.
At least the timeout issue was seen with two different drivers (one was a clean Win10 system).

[mpack]

Well, I assume it is obvious to you that if VirtualBox is interfacing with the device at the USB network level then it can't be responsible for any problems you have at the higher RS232 guest OS application level.