I'm scratching my head on this one. Running 11-current from today (svn r275291) with defaults will fail to boot on my rootbsd Xen HVM instance. It will have intermittent vnc consoles and will exhibit numerous disk errors when trying to boot multiuser or doing an installworld from single user. If I set kern.vty="sc" in loader.conf, magically all of these problems go away. I am using rootbsd's xen infrastructure for this: Nov 29 11:49:57 box kernel: FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Nov 29 11:49:57 box kernel: XEN: Hypervisor version 4.2 detected. Nov 29 11:49:57 box kernel: CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2400.05-MHz K8-class CPU) Nov 29 11:49:57 box kernel: Origin="GenuineIntel" Id=0x206c2 Family=0x6 Model=0x2c Stepping=2 Nov 29 11:49:57 box kernel: Features=0x1783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT> Nov 29 11:49:57 box kernel: Features2=0x81ba2201<SSE3,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,HV> Nov 29 11:49:57 box kernel: AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM> Nov 29 11:49:57 box kernel: AMD Features2=0x1<LAHF> Nov 29 11:49:57 box kernel: Hypervisor: Origin = "XenVMMXenVMM" Nov 29 11:49:57 box kernel: real memory = 1434451968 (1368 MB) Nov 29 11:49:57 box kernel: avail memory = 1353445376 (1290 MB) Nov 29 11:49:57 box kernel: Event timer "LAPIC" quality 400 Nov 29 11:49:57 box kernel: ACPI APIC Table: <Xen HVM> Nov 29 11:49:57 box kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Nov 29 11:49:57 box kernel: FreeBSD/SMP: 1 package(s) x 2 core(s) Nov 29 11:49:57 box kernel: cpu0 (BSP): APIC ID: 0 Nov 29 11:49:57 box kernel: cpu1 (AP): APIC ID: 2 Nov 29 11:49:57 box kernel: ioapic0: Changing APIC ID to 1 Nov 29 11:49:57 box kernel: MADT: Forcing active-low polarity and level trigger for SCI Nov 29 11:49:57 box kernel: ioapic0 <Version 1.1> irqs 0-47 on motherboard Nov 29 11:49:57 box kernel: random: entropy device infrastructure driver Nov 29 11:49:57 box kernel: random: selecting highest priority adaptor <Dummy> Nov 29 11:49:57 box kernel: random: SOFT: yarrow init() Nov 29 11:49:57 box kernel: random: selecting highest priority adaptor <Yarrow> Nov 29 11:49:57 box kernel: kbd1 at kbdmux0 Nov 29 11:49:57 box kernel: xenpv0: <Xen PV bus> on motherboard Nov 29 11:49:57 box kernel: xen_et0: <Xen PV Clock> on xenpv0 Nov 29 11:49:57 box kernel: Event timer "XENTIMER" frequency 1000000000 Hz quality 950 Nov 29 11:49:57 box kernel: Timecounter "XENTIMER" frequency 1000000000 Hz quality 950 Nov 29 11:49:57 box kernel: xenstore0: <XenStore> on xenpv0
Created attachment 150078 [details] Make vt_vga reserve the memory it uses Yes, I'm aware of the issue. It comes from the fact that FreeBSD/Xen uses the holes in the memory map to map the grant table, foreign memory from other domains, &c. The problem is that the vt_vga driver doesn't reserve the memory region it uses, so Xen will happily use it for it's ends, this as you already realized ends up very badly. I'm attaching a crappy patch that solves this by making vt_vga register the memory it uses, but the patch is incomplete: * It unconditionally reserves the memory, even if vt_vga is not used. * I've not checked if other vt_* drivers have the same issue.
A commit references this bug: Author: royger Date: Mon Dec 22 16:46:08 UTC 2014 New revision: 276064 URL: https://svnweb.freebsd.org/changeset/base/276064 Log: vt: register the memory regions used by the vt drivers Current VT drivers don't register the memory regions they use with the nexus. This patch makes vt_vga and vt_efifb register the memory regions they use. This is needed (at least) for Xen support, since the FreeBSD kernel will try to use the holes in the memory map to map memory from other domains and setup it's grant table. Sponsored by: Citrix Systems R&D Reported by: sbruno Tested by: emaste Reviewed by: ray PR: 195537 Differential Revision: https://reviews.freebsd.org/D1291 Changes: head/sys/dev/vt/hw/efifb/efifb.c head/sys/dev/vt/hw/vga/vt_vga.c
Fixed in r276064.