Guru Meditation -2403 (VERR_TRPM_DONT_PANIC) => fixed in svn

[embrosyn]

Running latest i386 Lubuntu or Xubuntu 18.04 live disc image results in VirtualBox crashing with a Guru Meditation error specified in title. Same happens when using a disk image from ​here. Running an older Linux distribution such as x86 Sabayon Linux 14.01 with XFCE works fine though.

Tested a wide array of VirtualBox versions on Ubuntu (5.1.38 and 5.2.18 from Oracle repositories as well as test builds 5.2.19-125117 and 5.2.97-125151) and Windows (4.3.40, 5.0.40, 5.1.38, 5.2.18), but no luck.

Below are my machine's specs.

Manufacturer: Fujitsu
Model: Lifebook AH531
CPU: Intel Pentium B950 (so no VT-x or VT-d)
OS: Ubuntu 18.04 and Windows 7 SP1, both 64-bit

I've attached a log of a VirtualBox 5.2.18 run with i386 Lubuntu 18.04 guest on a AMD64 Ubuntu 18.04 host.

[Socratis]

Replying to embrosyn:

CPU: Intel Pentium B950 (so no VT-x or VT-d)

So there's no *buntu 18.04 or anything close to that for you I'm afraid. These OSes require the presence of VT-x on the host, no questions asked.

Your CPU is under-powered. Your best bet would be to try something from the 4.3.x series, or the 5.0.x series, or the 5.1.x series. The higher the VirtualBox version, the more dependent it is on the existence of VT-x. And that would only work with older guests, like Ubuntu 8/10/12, or guests from that era.

BTW, it's usually better and faster, if issues get first addressed in the ​VirtualBox forums, a lot more eyes there. More than 95% of the issues are resolved over there, which keeps the developers focusing on the bug fixes and enhancements, and there is no need for another ticket to keep track of. For example, yours is not a bug and someone from the developers has to deal with it and close it as "Invalid".

[embrosyn]

Thank you for responding socratis!

So there's no *buntu 18.04 or anything close to that for you I'm afraid. These OSes require the presence of VT-x on the host, no questions asked.

I've successfully run AMD64 Lubuntu 18.04 in QEMU using TCG. TCG is, without doubt, an impressive piece of work, but it ran somewhat slowly for comfortable usage. While it very likely uses a completely different way of translating instructions, it managed to run Lubuntu on my laptop with minimal problems, apart from performance. Taking a look at the VirtualBox log, it seems like the lack of VT-x is just an inconvenience, but not something that caused the virtual machine to stop running as the execution resumes, i.e. messages keep coming, for a while after showing that message. Having that said, could you please link to a reputable source mentioning the VT-x requirement? I'm aware of Ubuntu discontinuing i386 live disc images since 17.10 (​1, ​2), but not this one.

Your CPU is under-powered. Your best bet would be to try something from the 4.3.x series, or the 5.0.x series, or the 5.1.x series. The higher the VirtualBox version, the more dependent it is on the existence of VT-x. And that would only work with older guests, like Ubuntu 8/10/12, or guests from that era.

As mentioned in the ticket description, I've tried the latest versions of all of the mentioned series and some more, but it made no difference. An old distribution like Sabayon 14.01 works perfectly, while new Ubuntus crash VirtualBox outright.

BTW, it's usually better and faster, if issues get first addressed in the ​VirtualBox forums, a lot more eyes there. More than 95% of the issues are resolved over there, which keeps the developers focusing on the bug fixes and enhancements, and there is no need for another ticket to keep track of. For example, yours is not a bug and someone from the developers has to deal with it and close it as "Invalid".

Saw this suggestion on other tickets after I created this one. Will have that in mind before opening some potential ticket in the future.

However, even if truly isn't a bug, but a known incompatibility of some sort, there certainly is some room for improvement. Such errors could be handled more gracefully instead of bluntly crashing, as currently it looks like VirtualBox halts execution due to an unknown compatibility problem, such as an unsupported instruction or an inadequately handled call to known incompatible instruction on the VirtualBox side.

[Socratis]

Replying to embrosyn:

I've successfully run AMD64 Lubuntu 18.04 in QEMU using TCG.

Different program, I assume different requirements and capabilities. Can't comment any further, because I haven't actually used it.

could you please link to a reputable source mentioning the VT-x requirement?

Hmm... Good question. I'm not reputable enough for you? :)

I don't have anything like the manual or the release notes to go with. I do know from several developer comments that anything > Win7 for example does require VT-x on the host. And hundreds (if not thousands) of cases in the forums where if the user enabled VT-x in the BIOS (disabled for some reason), things would work.

I've recently experimented with an Ubuntu 18.04 on an environment where there was no VT-x available; it didn't work. As soon as I enabled VT-x on the host, it did.

[embrosyn]

Replying to socratis:

Hmm... Good question. I'm not reputable enough for you? :)

On the Internet, nobody can be sure whether you're just a ​computer-savvy dog or, say, Oracle CEO himself, so I had no idea whether the provided information is reliable. Support services of widely used products such as VirtualBox tend to dismiss users' complaints with often unhelpful responses or just put the blame on users and/or users' hardware without taking a proper look at the issue. I've seen a few posts and tickets mentioning Guru Meditation problems, but on all these places I've seen copies of your response largely unchanged, with no particular justification such as one provided here. Without it, the responses seemed unconvincing, which actually resulted in this ticket, so thank you for taking time to elaborate your answer here.

Seems like it's time to use USB sticks again for testing Linux.

[bird]

Raw-mode hypervisor guru is due to some real old code shadow TSS synchronization code making too many assumption about how the interpreter works. We replaced the interpreter a while back, so this is an oversight on my part. I've corrected the code and it should show up in a test build / release before long.