[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen on ARM basic questions
On Mon, 2013-12-02 at 08:02 -0500, Vaibhav Bedia wrote: > I currently get > /usr/include/libfdt.h:54:24: fatal error: libfdt_env.h: No such file > or directory > > Google tells me this was bug in the library build [1]... trying to figure > out how to get this sorted out. I keep hitting this, I just grabbed the source and copied libfdt_env.h to /usr/include. Works for me ;-) > >> vcpus = 1 > >> vif = [ 'bridge=xenbr0','mac=00:16:3e:23:24:32'] > > > > This is actually creating two vifs. One one xenbr0 with a random mac and > > one with the given mac address on the default bridge (probably xenbr0!) > > > > You probably wanted: > > vif = [ 'bridge=xenbr0,mac=00:16:3e:23:24:32'] > > Or just: > > vif = [ 'mac=00:16:3e:23:24:32'] > > which works because xenbr0 is the default bridge. > > > > Ok. I wanted only one vif. Didn't realize this was creating two of those. > > Now that i get the console in the ubuntu filesystem for domU i was > hoping to dig deeper into the "unable to ping" domU problem. > > My fresh builds of the kernels for dom0 and domU seems to have > uncovered some other issue since i just can't get a reliable domU > boot now. Right now most of the domU creation hangs and it also > kills off dom0. I have a heartbeat led in dom0 and that just stops - > i can switch to xen using ctrl-a keystrokes and back but the dom0 > seems to have crashed. > > Any suggestions on how to debug this? There are few "failed to unmap" > messages when creating domUs but i don't know how to debug this :( Yes, these are annoying. In the absence of a proper fix I've been: diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index 8e74590..7b383bf 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -533,11 +533,16 @@ static void privcmd_close(struct vm_area_struct *vma) { struct page **pages = vma->vm_private_data; int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT; + int rc; if (!xen_feature(XENFEAT_auto_translated_physmap) || !numpgs || !pages) return; - xen_unmap_domain_mfn_range(vma, numpgs, pages); + rc = xen_unmap_domain_mfn_range(vma, numpgs, pages); + if (rc < 0) { + pr_crit("PRIVCMD: leaking %d pages\n", numpgs); + return; + } free_xenballooned_pages(numpgs, pages); kfree(pages); } > [...] > (XEN) *** Dumping CPU0 guest state (d0:v0): *** > (XEN) ----[ Xen-4.4-unstable arm32 debug=y Not tainted ]---- > (XEN) CPU: 0 > (XEN) PC: c0097518 Does this address correspond to anything interesting in the dom0 kernel? That might give some hint where it has gotten stuck. > (XEN) CPSR: 60000193 MODE:32-bit Guest SVC > (XEN) R0: 00000018 R1: 00000478 R2: 00000000 R3: c09008e8 > (XEN) R4: c09008e8 R5: c08f2000 R6: c1322a04 R7: c04f784c > (XEN) R8: 60000193 R9: c099c4c4 R10:00000001 R11:c08f3e64 R12:60000193 > (XEN) USR: SP: be9724f8 LR: b6f01234 > (XEN) SVC: SP: c08f3de8 LR: c05e7120 SPSR:60000113 > (XEN) ABT: SP: c0997a0c LR: c05e7a80 SPSR:80000193 > (XEN) UND: SP: c0997a18 LR: c05e78e0 SPSR:80070093 > (XEN) IRQ: SP: c0997a00 LR: c05e76c0 SPSR:60000193 > (XEN) FIQ: SP: 00000000 LR: 00000000 SPSR:00000000 > (XEN) FIQ: R8: 00000000 R9: 00000000 R10:00000000 R11:00000000 R12:00000000 > (XEN) > (XEN) SCTLR: 10c5387d > (XEN) TCR: 00000000 > (XEN) TTBR0: 000000009d27406a > (XEN) TTBR1: 000000008000406a > (XEN) IFAR: b6eb1aa0, IFSR: 00000007 > (XEN) DFAR: b6c00008, DFSR: 00000817 > (XEN) > (XEN) VTCR_EL2: 80002558 > (XEN) VTTBR_EL2: 00010000a200e000 > (XEN) > (XEN) SCTLR_EL2: 30cd187f > (XEN) HCR_EL2: 0000000000282835 > (XEN) TTBR0_EL2: 00000000feedf000 > (XEN) > (XEN) ESR_EL2: 07e00000 > (XEN) HPFAR_EL2: 0000000000482110 > (XEN) HDFAR: d0800100 > (XEN) HIFAR: 00000000 > (XEN) > (XEN) No stack trace for 32-bit guest kernel-mode > (XEN) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |