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@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 <d...@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.
> 

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to