First make sure you CPU supports both EPT and has a IOMMU. It sounds like you have Xen to use the serial console.
To /etc/ttys, you need to add: xc0 "/usr/libexec/getty Pc" vt100 on secure Also, make sure all the ttyu[0-4] are off. Recent versions of FreeBSD maybe putting onifconsole … and I can't remember all the combinations I used, but I had a lot of issues with Xen and FreeBSD fighting for the serial ports. Also, make sure /boot/loader.conf is configured for console=“vidconsole" on the freebsd side, and that the xen_cmdline should have “console=vga” and not =com1. It’s not explicit, but the Xen kernel creates the “console”. The xc0 device (and Xen itself) seems to take care of piping the Dom0 console over to whatever Xen is using as console. Other tips, if you are running ZFS, you will probably need to add "vm.max_wired=-1” to /etc/sysctl.conf (I’m actually not sure this is valid, but if you don’t you’ll run out of wired memory and all the “xl” commands will fail. Or limit the size of ARC. ) You might need to turn off MSI interrupts on AHCI, "hint.ahci.0.msi=0” in /boot/loader.conf. However, try both ways (default I believe is =1). I’m running Intel ICH10 and have to disable MSI. Roger has ICH8 and doesn’t seem to have the issue. The latest issue is very poor network performance (with Intel 82574L) from the DomU (guests) over the bridge and to the network. However, Guests -> Dom0 seem ok. - David P. Discher http://davidpdischer.com/ AIM: DavidDPD | Y!M: daviddpdz On Dec 13, 2014, at 10:51 PM, Miguel Clara <miguelmcl...@gmail.com> wrote: > I was just trying too boot Freebsd Xen dom0 on a laptop but I just get a > black screen after the boot process.... > > any idea what it could be? > > the system boots fine wihtout loading "boot/xen", I'm not sure how to get > more info with the black scren! > > thanks > > > Melhores Cumprimentos // Best Regards > ----------------------------------------------- > Miguel Clara > IT - Sys Admin & Developer > E-mail: miguelmcl...@gmail.com > <linkedin.png> www.linkedin.com/in/miguelmclara/ > > On Tue, Dec 9, 2014 at 7:17 PM, David P. Discher <d...@dpdtech.com> wrote: > ah, sorry missed that. Will try that today. > > AHCI lasted over night with MSI off. Something I noticed, is that when the > AHCI bus was timing out, it looked like the Xen Kernel was re-scanning the > PCI bus. (Sorry, didn’t save these logs). I’ve love to dig into this further. > > Please let me know what/where to add some debugging code. > > - > David P. Discher > http://davidpdischer.com/ > AIM: DavidDPD | Y!M: daviddpdz > Mobile: 408.368.3725 > > > > On Dec 9, 2014, at 12:27 AM, Roger Pau Monné <roger....@citrix.com> wrote: > > > Hello, > > > > El 08/12/14 a les 23.45, David P. Discher ha escrit: > > <SNIP> > >> > >> Sent SIGTERM to all processes > >> │ > >> Sent SIGKILL to all > >> processes───────────────────────────────────────────────┘ > >> Requesting system reboot > >> [ 1157.299205] Restarting system. > >> root@borg:/zdata/debian # > >> root@borg:/zdata/debian # > >> root@borg:/zdata/debian # xl create -c debian.cfg > >> root@borg:/zdata/debian # xl destroy debian > >> xc: error: Could not bounce buffer for version hypercall (35 = > >> Resource temporarily unavailabl): Internal error > >> xc: error: Could not bounce buffer for version hypercall (35 = > >> Resource temporarily unavailabl): Internal error > >> xc: error: Could not bounce buffer for version hypercall (35 = > >> Resource temporarily unavailabl): Internal error > >> xc: error: Could not bounce buffer for version hypercall (35 = > >> Resource temporarily unavailabl): Internal error > >> xc: error: Could not bounce buffer for version hypercall (35 = > >> Resource temporarily unavailabl): Internal error > >> xc: error: Could not bounce buffer for version hypercall (35 = > >> Resource temporarily unavailabl): Internal error > >> libxl: error: libxl.c:658:libxl_list_domain: getting domain info > >> list: Resource temporarily unavailable > >> debian is an invalid domain identifier (rc=-5) > >> root@borg:/zdata/debian # > >> > >> I’m running AHCI with MSI off in the FreeBSD kernel, and so far, so good > >> on that front. The great thing is now I got the Xen console working, so > >> can get the debug output. However the bounce buffer/hypercall issue i > >> would think is far more important than MSI interrupts at the monument. > > > > Glad to know you got it working at the end! I've already pointed this > > out in my last email, but did you try to increase vm.max_wired even further? > > > > This usually happens when mlock in > > freebsd_privcmd_alloc_hypercall_buffer (xc_freebsd_osdep.c) fails to > > wire down the memory that would be used by the hypercalls. > > > > Roger. > > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
