Bug 193672 - FreeBSD UEFI boot panics with VirtualBox UEFI loader
Summary: FreeBSD UEFI boot panics with VirtualBox UEFI loader
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.1-STABLE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
Keywords: uefi
Depends on:
Reported: 2014-09-15 21:24 UTC by Ed Maste
Modified: 2015-09-01 15:53 UTC (History)
5 users (show)

See Also:

verbose boot serial log from boot panic (28.52 KB, text/plain)
2014-09-15 21:24 UTC, Ed Maste
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Maste freebsd_committer 2014-09-15 21:24:52 UTC
Created attachment 147364 [details]
verbose boot serial log from boot panic

kernel trap 12 with interrupts disabled

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x486a8e215
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff80300007
stack pointer           = 0x28:0xffffffff81493070
frame pointer           = 0x28:0x0
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = resume, IOPL = 0
current process         = 0 ()
trap number             = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
#0 0xffffffff80947060 at ??+0
#1 0xffffffff8090c185 at ??+0
#2 0xffffffff80d07b6f at ??+0
#3 0xffffffff80d07e88 at ??+0
#4 0xffffffff80d074ea at ??+0
#5 0xffffffff80ced402 at ??+0
Uptime: 1s

Via LLDB the reported IP is:

      Address: kernel[0xffffffff80300007] (kernel..text + 161399)
      Summary: kernel`chopen + 855 [inlined] scsi_2btoul + 4 at scsi_ch.c:1632
               kernel`chopen + 851 [inlined] chgetparams + 288 at scsi_ch.c:485
               kernel`chopen + 563 at scsi_ch.c:485

(This seems a bit odd.)
Comment 1 Roger Leigh 2014-09-21 10:15:16 UTC
Also seen on real hardware (ASUS SABERTOOTH R2.0 UEFI mainboard with an AMD FX-8350 processor and 16GiB RAM) with the beta1 usb image.  I see the exact same output other than the backtrace:

KDB: stack backtrace:
#0: 0xffffffff80946c70 at ??+0
#1: 0xffffffff8090db95 at ??+0
#2: 0xffffffff80d0774f at ??+0
#3: 0xffffffff80d07a68 at ??+0
#4: 0xffffffff80d070ca at ??+0
#5: 0xffffffff80ced012 at ??+0
Uptime: 1s
Comment 2 Ed Maste freebsd_committer 2014-09-22 15:07:01 UTC
Can you check the reported instruction pointer (from the output just before the backtrace) to see if it also falls within chopen()?

For the beta1 kernel that is this range:

ffffffff802ffcb0 t chopen
ffffffff80300240 t chclose
Comment 3 Roger Leigh 2014-09-28 18:49:29 UTC
Yes, the instruction pointer is exactly the same.  Everything prior to the backtrace is identical to your output.
Comment 4 Glen Barber freebsd_committer 2014-10-21 15:39:59 UTC
I am able to successfully run FreeBSD with UEFI under VirtualBox.

The host environment details are:
CPU: Intel(R) Core(TM) i7-2700K CPU @ 3.50GHz (3605.74-MHz K8-class CPU)
Motherboard: ASUS P8Z77-V LX
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads
  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
  AMD Features2=0x1<LAHF>
  TSC: P-state invariant, performance statistics

VirtualBox version 4.3.10

Prior to installation, enable 'EFI' option for the virtual machine.
After installing from the UEFI disc1.iso, shutdown the virtual machine, and detach the installation CD from the virtual machine prior to booting the installed OS.
Comment 5 Kurt Lidl freebsd_committer 2014-12-08 23:48:40 UTC
I just tried to get this to work today.  Here are my notes.

I prepared a fresh image this morning (Last Changed Rev: 275104),
and attempted to boot it on VirtualBox 4.3.20 r96996 (on a Mac),
with the VirtualBox extensions installed.

It does work, if you give enough memory to the client VM.

With 3072MB of memory for the virtualbox instance, FreeBSD panics before
the kernel's autoconfiguration takes place.

With 3073MB..3090MB of memory, the FreeBSD boot hangs right after
it prints out the "EFI framebuffer information:" table, but before any
of the autoconfiguration happens.

With 3091MB (or more) of memory, the FreeBSD boot completes successfully.
Comment 6 Marcus von Appen freebsd_committer freebsd_triage 2015-02-18 11:54:19 UTC
Updated 10.1-BETA and 10.1-RC versioned bugs to 10.1-STABLE.
Comment 7 Jung-uk Kim freebsd_committer 2015-02-19 21:13:16 UTC
VirtualBox supports both UGA (Universal Graphic Adapter) and GOP (Graphics Output Protocol) but FreeBSD loader uses GOP.  Default GOP mode seems to be 2 (1024x768) and it panics kernel if the system memory is small.  As a stopgap, you may lower the resolution with VBoxManage, i.e.,

VBoxManage setextradata "VM name" VBoxInternal2/EfiGopMode N

where "VM name" is the name of your VM and N is from 0 to 5.

For example,

VBoxManage setextradata FreeBSD VBoxInternal2/EfiGopMode 1

will lower video mode to 800x600 for your "FreeBSD" VM.  Please see the manual for more information.

Comment 8 Jung-uk Kim freebsd_committer 2015-02-19 21:56:17 UTC
(In reply to Jung-uk Kim from comment #7)

This URL is more specific to the discussion:

Comment 9 Marcel Moolenaar freebsd_committer 2015-08-30 05:06:33 UTC
Is this bug still relevant? Can someone (Ed?) test again to see if the problem still exists?

I for one can boot FreeBSD just fine in VirtualBox 5 with EFI and with just 1GB of memory. So maybe the problem got resolved and this bug can be closed?
Comment 10 Ed Maste freebsd_committer 2015-08-31 16:55:02 UTC
I tested again at SVN r286874 with VirtualBox 4.3.30 and confirm that UEFI/efifb works with memory set to 256MB, 512MB, 1024MB, 3072MB, 3080MB, 4096MB.

As an aside the boot fails with memory set to 128MB with the following (unrelated) error:

failed to allocate staging area: 9223372036854775808
failed to allocate staging area
StartImage failed with error 8000000000000005
panic: Load failed
Comment 11 Ed Maste freebsd_committer 2015-09-01 15:53:45 UTC
See also PR 191564 which links to a series of UEFI/vt issues fixed by marcel@. Note that these fixes are not in FreeBSD 10.2-RELEASE. They have been merged to stable/10 and will be in 10.3-RELEASE.