Opened 10 years ago
Closed 8 years ago
#12926 closed defect (obsolete)
Guru meditation happens when starting Win7 client (VINF_EM_TRIPLE_FAULT)
| Reported by: | Rafcio | Owned by: | |
|---|---|---|---|
| Component: | VM control | Version: | VirtualBox 4.3.10 |
| Keywords: | Cc: | ||
| Guest type: | Windows | Host type: | Linux |
Description
I keep getting guru meditation when booting Windows 7 x86 client. This happens seconds after starting VM and happened a second time in four attempts to start the VM (50% chance of crashing?). It seems that every other boot attempt (or perhaps the first time after booting the host machine?) the VM crashes with guru meditation. This maybe a regression in 4.3.10 as I did not experience that with 4.3.8.
Attachments (5)
Change History (12)
by , 10 years ago
| Attachment: | vbox.tar.gz added |
|---|
comment:1 by , 10 years ago
| Summary: | Guru meditation happens when starting Win7 client → Guru meditation happens when starting Win7 client (VINF_EM_TRIPLE_FAULT) |
|---|
comment:2 by , 10 years ago
I get the same error however not when I start up, after I've been running for a while, I think it has something to do with screen saving and power settings.
HP EliteBook 8470p Window 7 64-bit 8GB Mem, Intel I5 Quad Core Guest OS: Solaris 10 update 11 VirtualBox: 4.3.12 r93733 Error MSG: A critical error has occurred while running the virtual machine and the machine execution has been stopped.
This appears to happen when the host OS, Windows 7 turns off the display. I may be wrong about this, but I seem to have the issue when I return to my computer after the screen has been blanked, not all the time though. This is a company PC so it's locked down by IT and I don't have complete control over it. I would like to disable the screen blanking and turn on hardware virtualization in the Bios, but I can't at the moment...
This problem occurs about 2 - 3 times a week.
comment:4 by , 9 years ago
I've checked and I have virtualization enabled in the BIOS. This is not the issue. I'm pretty sure that the problem has something to do with I/O starvation. Here is why.
The guru meditation happens only when there is another VM already running. Since this VM is always started as a second one, this one has a problem with starting. It looks like when starting, it generates a lot of I/O and the disk can't keep up. If the other VM also generates I/O when this VM is started, then the guru meditation happens. If on a rare occasion this VM is stated as the sole running VM, there has never been a guru meditation. It happens only if there is another VM running and the disk I/O is heavy (the disk light is pretty much solid).
There is one more recent development that confirms the I/O starvation suspicion. It happened before, however rarely, but with the 4.3.20 version the problem became serious. When this VM is running and is generating a high disk I/O, the other VM crashes. There is no guru meditation or anything like that. The other VM simply disappears and this became very serious with 4.3.20. I'd say 50% of time the other VM will crash now, whereas before it was maybe 10% of time. The logs that I will attach today will be from the OTHER VM that crashes when there is a heavy I/O happening at the same time from both VMs. This may be a unique problem with Linux being the host. It seems that Linux has a problem with interrupt handling, which manifests itself by the fact that, when there is a heavy disk I/O (even from a single VM running) the mouse stops moving. This is a common thing on this host - when the disk light is solid, the mouse cursor stops moving and the clock is not refreshed too. Even with a single VM. I've never had a mouse that stops moving under Windows host even if 4 VMs were running (given, the other host is a much more powerful hardware than this lousy laptop). The mouse stops moving on this laptop not only within a VM, on the Linux desktop too, therefore I'm pretty sure that Linux has an issue with interrupt handling when there is a heavy disk I/O.
comment:5 by , 9 years ago
Rafcio, the logs you have posted in the 2nd archive are incomplete. I think that you have now reported a different issue. At the time that the first logs were created, from the first archive, you were using a much older VirtualBox version and the guest seems to have executed some invalid code, maybe from an invalid address. But the crash you're now talking I would dare to say it's caused by a bug in the AHCI controller emulation (see bug #13105). Try to enable the Host I/O Cache for the SATA controller, in the VM settings or disable it, if it's already enabled. Or try to reproduce the crash with a VM that uses a SAS, a SCSI or an IDE controller, instead of a SATA controller.
comment:6 by , 9 years ago
I have opened another ticket (13859) to track this other issue, however I strongly believe that these issues are related. The common thing is none of them happens if there is just one VM running. Both are triggered by the second VM running that generates a heavy disk I/O.
The logs ARE complete. That's all there is when the VM crashes (aborts). The other ticket has log from the latest code.
There used to be a warning that disabling the host I/O cache can lead to serious corruption (I don't remember the exact warning), so I never tried to run without caching. I'll give it a try and see what happens.
comment:7 by , 8 years ago
| Resolution: | → obsolete |
|---|---|
| Status: | new → closed |
Please reopen if still relevant with a recent VirtualBox release.
Logs