16.04.1-Ubuntu crashes on serial USB communication (vmmDevHeartBeatFlatline)

[vincenttchan]

Hey everyone,

For the past few days, I've been struggling to pinpoint the error in my virtual machine guest. I'm trying to set up a build server which would test USB serial boards through python. However, when running scripts, it would freeze halfway through the test randomly (there is no "one point" it freezes at). All the scripts are done through python, which has no problem being run on a machine that is not in a VM environment. I was wondering if anyone could look at this log and help me find out why it seems to hang.

Thanks in advance.

[mpack]

I've looked, and I'm afraid I don't see any obvious errors. It would be great if we could prove where the lockup occurs. Presumably somewhere in the guests xHCI stack. Does the lockup also happen with EHCI (USB2) also? I assume that a serial port doesn't need USB3 speeds.

[vincenttchan]

When I turn it on EHCI, the serial port will time out.

Is there a way to examine the xHCI stack trace of the guest? Or is that something to look at with ubuntu's side?

[mpack]

xHCI is hardware, so there is no stack visible to the guest - and I'm not an expert on debugging Linux drivers, so I can't comment on what you might be able to do in the guest.

Can you say precisely what the devices are? Perhaps others can reproduce what you see.

[vincenttchan]

I'm using a nRF52 Development Kit

That is fine. I will find a work-around if there is no immediate fix. Are there any log files I should pay attention to? The kernel logs dont seem to show anything out of the ordinary. The only thing that might tip something off is that my test's logs during the crash seem to write Null bytes(\00) to the end (before it crashes) of the log, which would point to a kernel error... I think?

Anyways, thanks for your help.

[mpack]

Hmm. Perhaps I should expand an earlier comment I made. When I say that I'm not an expert on debugging Linux drivers I mean that I wouldn't know a Linux driver if I tripped over it, so I'm really not equipped to have a sensible conversion about what they can or can't tell you.

If it was me I would try to verify that I get the same problem with an entirely different type of VM, say a Windows VM. If I get lockups with that then I'd be reasonably satisfied that VirtualBox could be the common factor - especially if the device driver in each case is by a different author. If you only get the problem with this one guest OS and driver then I would suspect the guest driver.