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
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.)
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
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
Yes, the instruction pointer is exactly the same. Everything prior to the backtrace is identical to your output.
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
ACPI APIC Table: <ALASKA A M I>
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads
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.
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.
Updated 10.1-BETA and 10.1-RC versioned bugs to 10.1-STABLE.
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.
VBoxManage setextradata FreeBSD VBoxInternal2/EfiGopMode 1
will lower video mode to 800x600 for your "FreeBSD" VM. Please see the manual for more information.
(In reply to Jung-uk Kim from comment #7)
This URL is more specific to the discussion:
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?
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
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.