Attempting to Get Xen FreeBSD Dom0 working

[David P. Discher]

Update: So, I changed a few things, and stuff is working better.

The Xen kernel line is now:

  dom0_mem=2048M dom0_max_vcpus=4 dom0pvh=1 sync_console com1=115200,8n1,0x3e8 console=vga,com1 iommu=debug

Also note, I have these set in FreeBSD:

  console="comconsole vidconsole"
  comconsole_speed="115200"
  comconsole_port="0x3e8"
  boot_multicons="yes"
  vm.max_wired=2097152
  verbose_loading="YES"
  boot_verbose=""	# -v: Causes extra debugging information to be printed

  hint.ahci.0.msi=0
  hw.acpi.verbose=1
  debug.acpi.enable_debug_objects=1

So far, no AHCI timeouts. I’v gotten completely through an install of Debian … granted it failed, but for a linux reasons - couldn’t find/download a package.  But is still going.

The change to the console lines also help … console=vga,com1 & sync_console to xen allowed the IPMI SOL COM3 to fully complete the boot under freebsd.  And the tty/login ran and displayed on xc0 :

   FreeBSD/amd64 (borg.dpdtech.com) (xc0)

However, this console will not take any input.   I still can’t get switched into the Xen console (Ctrl-A x3) on either the serial of VGA consoles. 

Another troubling item, em0 flaps when debian is starting up:

	xnb(xnb_probe:1144): Claiming device 0, xnb
	xnb1.0: bpf attached
	xnb(xnb_attach:1292): Attaching to backend/vif/1/0
	xnb(xnb_frontend_changed:1416): frontend_state=Initialising, xnb_state=InitWait
	em0: Link is Down
	xnb1.0: 2 link states coalesced
	(d1) mapping kernel into physical memory
	(d1) about to get started...
	xnb(xnb_frontend_changed:1416): frontend_state=Connected, xnb_state=InitWait
	xnb(xnb_connect_comms:796): rings connected!
	em0: Link is up 1000 Mbps Full Duplex

em0 is in bridge0, which is what the debian.cfg is using.


Also, something really odd … hyper calls aren’t working after launching the debian guest - which also means I can’t launch any more guests. 

	root at borg:~ # xl list
	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
	libxl_list_domain failed.


I’m heading out for the afternoon shortly, but it seems the next thing to do is to get the consoles working correctly so I can get debugging info from the hypervisor.  Will hopefully bang on this this evening. 


-
David P. Discher
http://davidpdischer.com/
AIM: DavidDPD | Y!M: daviddpdz 
Mobile: 408.368.3725



On Dec 4, 2014, at 12:26 PM, David P. Discher <dpd at dpdtech.com> wrote:

> Yes, ICH10. I’m not sure if an idle Dom0 does this, however limited access to the disks, even just editing things like /boot/loader.conf and /etc/rc.conf will eventually hang.  But I’m also trying to launch a DomU, and for the convince of a documented process, I’m following your debian steps … and the debian installer is running.   I’m running a zpool mirror across 4k aligned GPT partitions for the root drive.  I’ll also attempt to break break the mirror, as I don’t remember this being a problem with a single drive. 
> 
> As first step last night, I actually moved the msi interrupts to = 2, instead of fully disabled.  And this helped a little.  It seemed to allow the AHCI driver to recovered after the first several timeouts.   I will try disabling MSI as well and well as iommu debug.  However, I’m still without a Xen console. Durning the ACPI/pci probing … my console over SOL com3 cuts out. I haven’t try to recover it yet.  I will see what I can do.  However, from what it looks like, Xen kernel is latching on the com port, and freebsd sees it as “busy”.   I’ll see what I can figure out.  I believe the pm_level is default to 0, but will double check that.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-xen/attachments/20141204/d78b696e/attachment.sig>