On 21/02/13 10:18, tech mailinglists wrote:> Hello all, > > I have created a FreeBSD PV DomU image formatted with ZFS. I compiled > FreeBSD with KERNCONF=XEN for the kernel and the normal world and > distribution target. Then I transfered it to a Debian Dom0 with Xen 4.2.1. > > I tried to boot the image befor I migrate it to LVM and I now get teh > following output: >[...]> run_interrupt_driven_hooks: still waiting after 300 seconds for > xenbus_free_evtchn > panic: run_interrupt_driven_config_hooks: waited too long > cpuid = 0 > KDB: enter: panic > [ thread pid 0 tid 100000 ] > Stopped at kdb_enter+0x3a: movl $0,kdb_why > db>Try see if patch below should help the boot a bit along. Cheers, -- Cherry Index: xenbusb.c ==================================================================--- xenbusb.c (revision 248863) +++ xenbusb.c (working copy) @@ -594,8 +594,7 @@ KASSERT(xbs->xbs_connecting_children > 0, ("Connecting device count error\n")); xbs->xbs_connecting_children--; - if (xbs->xbs_connecting_children == 0 - && (xbs->xbs_flags & XBS_ATTACH_CH_ACTIVE) != 0) { + if ((xbs->xbs_flags & XBS_ATTACH_CH_ACTIVE) != 0) { xbs->xbs_flags &= ~XBS_ATTACH_CH_ACTIVE; mtx_unlock(&xbs->xbs_lock); config_intrhook_disestablish(&xbs->xbs_attach_ch);
On 31/03/13 19:45, Cherry G.Mathew wrote:> > On 21/02/13 10:18, tech mailinglists wrote: >> Hello all, >> >> I have created a FreeBSD PV DomU image formatted with ZFS. I compiled >> FreeBSD with KERNCONF=XEN for the kernel and the normal world and >> distribution target. Then I transfered it to a Debian Dom0 with Xen 4.2.1. >> >> I tried to boot the image befor I migrate it to LVM and I now get teh >> following output: >> > > [...] > >> run_interrupt_driven_hooks: still waiting after 300 seconds for >> xenbus_free_evtchn >> panic: run_interrupt_driven_config_hooks: waited too long >> cpuid = 0 >> KDB: enter: panic >> [ thread pid 0 tid 100000 ] >> Stopped at kdb_enter+0x3a: movl $0,kdb_why >> db> > > > Try see if patch below should help the boot a bit along.The problem is already solved, it was crashing because blkback in Dom0 was not correctly working -- nothing to do with FreeBSD. The 9.x releases work correctly, the problem is with HEAD and the backtrace I''ve posted. BTW, if you wish to try HEAD you will need the ELFNOTE patch I''ve posted and boot with "hw.mca.enabled=0" to get to the panic I''ve posted earlier.
>>>>> "Roger" == Roger Pau Monné <roger.pau@citrix.com> writes:Roger> On 31/03/13 19:45, Cherry G.Mathew wrote: >> >> On 21/02/13 10:18, tech mailinglists wrote: >>> Hello all, >>> >>> I have created a FreeBSD PV DomU image formatted with ZFS. I >>> compiled FreeBSD with KERNCONF=XEN for the kernel and the normal >>> world and distribution target. Then I transfered it to a Debian >>> Dom0 with Xen 4.2.1. >>> >>> I tried to boot the image befor I migrate it to LVM and I now >>> get teh following output: >>> >> >> [...] >> >>> run_interrupt_driven_hooks: still waiting after 300 seconds for >>> xenbus_free_evtchn panic: run_interrupt_driven_config_hooks: >>> waited too long cpuid = 0 KDB: enter: panic [ thread pid 0 tid >>> 100000 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> >> >> >> Try see if patch below should help the boot a bit along. Roger> The problem is already solved, it was crashing because Roger> blkback in Dom0 was not correctly working -- nothing to do Roger> with FreeBSD. The 9.x releases work correctly, the problem is Roger> with HEAD and the backtrace I've posted. I'd be keen to know why this is not an issue with other OSs (I run a NetBSD-pv on a xen linux dom0. For FreeBSD amd64 PV, I seem to be getting xenstore events, and the panic is caused by interrupt boot time hooks not being unhooked by the xenbus driver, because it waits for child devices on xenbus to finish their "attach". This is a bit redundant afaict, because the hooks are called together in the order of registration - the registrations themselves being in the autoconf device tree traversal order - and for the xen drivers, I don't see any interrupt hook specific dependencies in the children attaching to xenbus (I may be wrong). Anyway, that's what the patch does. Roger> BTW, if you wish to try HEAD you will need the ELFNOTE patch Roger> I've posted and boot with "hw.mca.enabled=0" to get to the Roger> panic I've posted earlier. Thanks, it's one of the first things I had to fix for amd64 PV on clang. There's a clock related issue with time offset calculation that is clang specific and is a bit bothersome too. Cheers, -- Cherry _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
>>>>> "Cherry" == Cherry G Mathew <cherry@zyx.in> writes:>>>>> "Roger" == Roger Pau Monné <roger.pau@citrix.com> writes:Roger> On 31/03/13 19:45, Cherry G.Mathew wrote: >>> >>> On 21/02/13 10:18, tech mailinglists wrote: >>>> Hello all, >>>> >>>> I have created a FreeBSD PV DomU image formatted with ZFS. I >>>> compiled FreeBSD with KERNCONF=XEN for the kernel and the >>>> normal world and distribution target. Then I transfered it to a >>>> Debian Dom0 with Xen 4.2.1. >>>> >>>> I tried to boot the image befor I migrate it to LVM and I now >>>> get teh following output: >>>> >>> >>> [...] >>> >>>> run_interrupt_driven_hooks: still waiting after 300 seconds for >>>> xenbus_free_evtchn panic: run_interrupt_driven_config_hooks: >>>> waited too long cpuid = 0 KDB: enter: panic [ thread pid 0 tid >>>> 100000 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> >>> >>> >>> Try see if patch below should help the boot a bit along. Roger> The problem is already solved, it was crashing because Roger> blkback in Dom0 was not correctly working -- nothing to do Roger> with FreeBSD. The 9.x releases work correctly, the problem is Roger> with HEAD and the backtrace I've posted. Cherry> I'd be keen to know why this is not an issue with other OSs Cherry> (I run a NetBSD-pv on a xen linux dom0. For FreeBSD amd64 Cherry> PV, I seem to be getting xenstore events, and the panic is Cherry> caused by interrupt boot time hooks not being unhooked by Cherry> the xenbus driver, because it waits for child devices on Cherry> xenbus to finish their "attach". This is a bit redundant Cherry> afaict, because the hooks are called together in the order Cherry> of registration - the registrations themselves being in the Cherry> autoconf device tree traversal order - and for the xen Cherry> drivers, I don't see any interrupt hook specific Cherry> dependencies in the children attaching to xenbus (I may be Cherry> wrong). Cherry> Anyway, that's what the patch does. Update - ignore that patch - I had a disk related configuration error which caused my problem (dom0 blkback is fine). Sorry for the noise. Cheers, -- Cherry _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users