Guru meditation (VERR_EM_INTERNAL_ERROR) booting OpenSolaris with VT-x and SATA enabled => Fixed in 2.0.4

[Robert Krawitz]

Trying to boot or install OpenSolaris (installing from onnv build 86, or booting an existing build 98 installation), I get a critical error if the SATA controller is enabled and VT-x is enabled. I've tried with IO APIC enabled (required with VT-x); it doesn't matter if ACPI or PAE is either enabled or disabled. It appears to happen around when OpenSolaris tries to probe the device tree, judging by the installation messages.

Note that there's no problem if either VT-x or SATA is enabled, but not both; it's only when both are enabled that the critical error happens.

Host: Dell Inspiron E1705, Core 2 Duo@1.83 GHz, 4 GB RAM (3.33 GB effectively), 320 GB SATA drive (running as an IDE drive, since the BIOS doesn't support AHCI :-(), OpenSUSE 11.0, uname -a:

Linux rlk-mobile 2.6.25.16-0.1-default #1 SMP 2008-08-21 00:34:25 +0200 x86_64 x86_64 x86_64 GNU/Linux

[Robert Krawitz]

Logfile from the critical error

[Robert Krawitz]

What looks like the same issue was also reported on Windows, see

​http://forums.virtualbox.org/viewtopic.php?t=9448&highlight=

[Robert Krawitz]

I cannot reproduce this installing OpenSUSE 11.0 into VirtualBox, even if the VM is set to OpenSolaris at the machine type. It appears to be OpenSolaris as the guest that's the issue.

[deltatux]

I can verify this. To get around this problem, I'm using IDE only for my HDD.

deltatux

[Frank Mehnert]

Please could you retry to boot with VT-x enabled until you get the Guru mediation? Then have a look at the syslog (dmesg) of the host and post the last few lines, they should contain an error message from VBox.

[Robert Krawitz]

The last messages I get are:

ACPI: PCI interrupt for device 0000:0c:00.0 disabled CPU0 attaching NULL sched-domain. CPU1 attaching NULL sched-domain. CPU0 attaching sched-domain:

domain 0: span 00000000,00000000,00000000,00000003

groups: 00000000,00000000,00000000,00000001 00000000,00000000,00000000,00000002 domain 1: span 00000000,00000000,00000000,00000003

groups: 00000000,00000000,00000000,00000003

CPU1 attaching sched-domain:

domain 0: span 00000000,00000000,00000000,00000003

groups: 00000000,00000000,00000000,00000002 00000000,00000000,00000000,00000001 domain 1: span 00000000,00000000,00000000,00000003

groups: 00000000,00000000,00000000,00000003

b44: eth7: Link is up at 100 Mbps, full duplex. b44: eth7: Flow control is off for TX and off for RX. ADDRCONF(NETDEV_CHANGE): eth7: link becomes ready eth7: no IPv6 routers present CPU0: Temperature/speed normal Machine check events logged

I don't know where the machine check events would be logged. I can't find them in anything in /var/log.

[Frank Mehnert]

Hmm, and this are the lines from the system log after your guest aborted with a Guru meditation?

[jkeil]

Replying to frank:

Please could you retry to boot with VT-x enabled until you get the Guru mediation? Then have a look at the syslog (dmesg) of the host and post the last few lines, they should contain an error message from VBox.

I get exactly the same sort of "Guru Meditation -1149 (VERR_EM_INTERNAL_ERROR)" error when booting the pre-release opensolaris 2008.11 LiveCD (based on snv_97) in a vbox 2.0.2 guest.

My host is running OpenSolaris? SXCE (build 96), on an AMD64 X2 cpu, AMD-V is enabled. There are no messages (dmesg) reported by the opensolaris kernel.

The opensolaris guest is automatically booting the 64-bit kernel. The SATA controller is enabled for the guest, and a 8GB virtual HDD is configured on SATA port 0.

Btw. when I force booting the 32-bit guest opensolaris kernel, by editing the kernel$ grub boot command line and removing the "$ISADIR/" part, there is no such guru mediation error.

And another workaround is to configure the virtual HDD as a PATA disk, in this case the 64-bit opensolaris guest doesn't crash with guru mediation error, either.

[jkeil]

opensolaris guest kernel stack backtrace, for the VERR_EM_INTERNAL_ERROR

[jkeil]

The caller stack frame for i_ddi_vaddr_put64() is missing in the VBox-guru_meditation.png screendump. It called from ahci`ahci_alloc_rcvd_fis+0x121.

It crashing in a 64-bit ahci device memory write at line 4001 in Opensolaris' ahci.c, function ahci_alloc_rcvd_fis():

​http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/sata/adapters/ahci/ahci.c#4000

   4000 	/* Config Port Received FIS Base Address */
   4001 	ddi_put64(ahci_ctlp->ahcictl_ahci_acc_handle,
   4002 	    (uint64_t *)AHCI_PORT_PxFB(ahci_ctlp, port),
   4003 	    ahci_portp->ahciport_rcvd_fis_dma_cookie.dmac_laddress);

[jkeil]

Hmm, it seems that the source code for the the virtualbox AHCI controller (DevAHCI.cpp) is missing in the Virtualbox OSE version...

Does it implement setting the full 64-bit physical "FIS Base Address" (PxFB, PxFBU) with one 64-bit write?

Apparently, when Opensolaris is running the 32-bit kernel, the i_ddi_vaddr_put64() function is compiled as two 32-bit device memory writes, and that appears to be supported by DevAHCI.cpp...

[Robert Krawitz]

That's my dmesg output from everywhere near the crash...er...guru meditation.

This was with the full VirtualBox 2.0.2, not the OSE, by the way.

[aeichner]

This issue will be fixed in the next release.

jkeil: Thank you very much for finding the issue.