<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">I've made one more clean install with repo file :-<br><br>[root@ServerXen341 yum.repos.d]# cat fedora-myoung-dom0.repo<br>[myoung-dom0]<br>name=myoung's repository of Fedora based dom0 kernels - $basearch<br>baseurl=http://fedorapeople.org/~myoung/dom0/$basearch/<br>enabled=1<br>gpgcheck=0<br><br>[myoung-dom0-source]<br>name=myoung's repository of Fedora based dom0 kernels - Source<br>baseurl=http://fedorapeople.org/~myoung/dom0/src/<br>enabled=1<br>gpgcheck=0<br><br> Then tried to load kernel been built as vanilla. Console dropped into stack trace<br>and hanged. <br> However, kernel loads fine and works under Xen. Dmesg report<br>under Xen stays the same ( stack trace entries ).<br><br>Boris.<br><br>--- On <b>Wed, 8/26/09, Boris Derzhavets <i><bderzhavets@yahoo.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16,
255); margin-left: 5px; padding-left: 5px;"><br>From: Boris Derzhavets <bderzhavets@yahoo.com><br>Subject: Re: [fedora-virt] Re: [Fedora-xen] Dom0 kernels<br>To: fedora-xen@redhat.com, fedora-virt@redhat.com, "M A Young" <m.a.young@durham.ac.uk><br>Date: Wednesday, August 26, 2009, 7:26 AM<br><br><div id="yiv1914242220"><table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font-family: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; font-size: inherit; line-height: inherit; font-size-adjust: inherit; font-stretch: inherit;" valign="top">Upstream issues looks DomU related. <br>Kernel 2.6.31-0.1.2.58.rc7.git1.xendom0.fc11.x86_64 works stable at runtime.<br><br>Boris.<br><br>--- On <b>Wed, 8/26/09, Boris Derzhavets <i><bderzhavets@yahoo.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Boris Derzhavets
<bderzhavets@yahoo.com><br>Subject: Re: [fedora-virt] Re: [Fedora-xen] Dom0 kernels<br>To: fedora-xen@redhat.com, fedora-virt@redhat.com, "M A Young" <m.a.young@durham.ac.uk><br>Cc: xen-devel@xensource.com<br>Date: Wednesday, August 26, 2009, 3:58 AM<br><br><div id="yiv1040215465"><table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font-family: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; font-size: inherit; line-height: inherit; font-size-adjust: inherit; font-stretch: inherit;" valign="top">Not sure how 2.6.31-0.1.2.58.rc7.git1.xendom0.fc11.x86_64 has been built.<br>There are pretty recent ongoing issues with 2.6.31-rc7 in upstream :-<br><br>http://lkml.org/lkml/2009/8/25/347<br>http://patchwork.kernel.org/patch/43791/<br><br><br>I was able to load Xen guest under 2.6.31-0.1.2.58.rc7.git1.xendom0.fc11.x86_64 <br>followed by kernel error with sky2 (?) and loosing vnc
connection to Xen Host 3.4.1 on top of F11. I'll do some more testing.<br><br>Boris.<br><br><br>--- On <b>Wed, 8/26/09, Boris Derzhavets <i><bderzhavets@yahoo.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Boris Derzhavets <bderzhavets@yahoo.com><br>Subject: Re: [fedora-virt] Re: [Fedora-xen] Dom0 kernels<br>To: fedora-xen@redhat.com, fedora-virt@redhat.com, "M A
Young" <m.a.young@durham.ac.uk><br>Cc: xen-devel@xensource.com<br>Date: Wednesday, August 26, 2009, 2:50 AM<br><br><div id="yiv901522983"><table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font-family: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; font-size: inherit; line-height: inherit; font-size-adjust: inherit; font-stretch: inherit;" valign="top">With rpm upgraded can load Dom0. However, dmesg report contains :-<br><br>Initializing cgroup subsys cpuset<br>Initializing cgroup subsys cpu<br>Linux version 2.6.31-0.1.2.58.rc7.git1.xendom0.fc11.x86_64 (root@ServerXenSRC) (gcc version 4.4.0 20090506 (Red Hat 4.4.0-4) (GCC) ) #1 SMP Wed Aug 26 08:14:58 MSD 2009<br>Command line: root=/dev/mapper/vg_serverxensrc-LogVol00 ro console=tty0<br>KERNEL supported cpus:<br> Intel GenuineIntel<br> AMD AuthenticAMD<br> Centaur CentaurHauls<br>BIOS-provided physical
RAM map:<br> Xen: 0000000000000000 - 000000000009ec00 (usable)<br> Xen: 000000000009ec00 - 0000000000100000 (reserved)<br> Xen: 0000000000100000 - 00000000cff80000 (usable)<br> Xen: 00000000cff80000 - 00000000cff8e000 (ACPI data)<br> Xen: 00000000cff8e000 - 00000000cffe0000 (ACPI NVS)<br> Xen:
00000000cffe0000 - 00000000d0000000 (reserved)<br> Xen: 00000000fee00000 - 00000000fee01000 (reserved)<br> Xen: 00000000ffe00000 - 0000000100000000 (reserved)<br> Xen: 0000000100000000 - 00000001f1a6b000 (usable)<br>DMI 2.4 present.<br>AMI BIOS detected: BIOS may corrupt low RAM, working around it.<br>e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)<br>last_pfn = 0x1f1a6b max_arch_pfn = 0x400000000<br>last_pfn = 0xcff80 max_arch_pfn = 0x400000000<br>initial memory mapped : 0 - 20000000<br>init_memory_mapping: 0000000000000000-00000000cff80000<br> 0000000000 - 00cff80000 page 4k<br>kernel direct mapping tables up to cff80000 @ 100000-785000<br>init_memory_mapping: 0000000100000000-00000001f1a6b000<br> 0100000000 - 01f1a6b000 page 4k<br><br>. . . . . . .<br><br>======================================================<br>[ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
]<br>2.6.31-0.1.2.58.rc7.git1.xendom0.fc11.x86_64 #1<br>------------------------------------------------------<br>khubd/28 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:<br> (&retval->lock){......}, at: [<ffffffff8112a240>] dma_pool_alloc+0x45/0x321<br><br>and this task is already holding:<br> (&ehci->lock){-.....}, at: [<ffffffff813d4654>] ehci_urb_enqueue+0xb4/0xd5c<br>which would create a new lock dependency:<br> (&ehci->lock){-.....} -> (&retval->lock){......}<br><br>but this new dependency connects a HARDIRQ-irq-safe lock:<br> (&ehci->lock){-.....}<br>... which became HARDIRQ-irq-safe at:<br> [<ffffffff8109908b>] __lock_acquire+0x254/0xc0e<br> [<ffffffff81099b33>] lock_acquire+0xee/0x12e<br> [<ffffffff8150b987>] _spin_lock+0x45/0x8e<br> [<ffffffff813d325c>] ehci_irq+0x41/0x441<br> [<ffffffff813b7e5f>]
usb_hcd_irq+0x59/0xcc<br> [<ffffffff810ca810>] handle_IRQ_event+0x62/0x148<br> [<ffffffff810ccda3>] handle_level_irq+0x90/0xf9<br> [<ffffffff81017078>] handle_irq+0x9a/0xba<br> [<ffffffff8130a0c6>] xen_evtchn_do_upcall+0x10c/0x1bd<br> [<ffffffff8101527e>] xen_do_hypervisor_callback+0x1e/0x30<br> [<ffffffffffffffff>] 0xffffffffffffffff<br><br>to a HARDIRQ-irq-unsafe lock:<br> (purge_lock){+.+...}<br>... which became HARDIRQ-irq-unsafe at:<br>... [<ffffffff810990ff>] __lock_acquire+0x2c8/0xc0e<br> [<ffffffff81099b33>] lock_acquire+0xee/0x12e<br> [<ffffffff8150b987>] _spin_lock+0x45/0x8e<br> [<ffffffff811233a4>] __purge_vmap_area_lazy+0x63/0x198<br> [<ffffffff81124c74>] vm_unmap_aliases+0x18f/0x1b2<br> [<ffffffff8100eeb3>] xen_alloc_ptpage+0x5a/0xa0<br> [<ffffffff8100ef97>]
xen_alloc_pte+0x26/0x3c<br> [<ffffffff81118381>] __pte_alloc_kernel+0x6f/0xdd<br> [<ffffffff811241a1>] vmap_page_range_noflush+0x1c5/0x315<br> [<ffffffff81124332>] map_vm_area+0x41/0x6b<br> [<ffffffff8112448b>] __vmalloc_area_node+0x12f/0x167<br> [<ffffffff81124553>] __vmalloc_node+0x90/0xb5<br> [<ffffffff811243c8>] __vmalloc_area_node+0x6c/0x167<br> [<ffffffff81124553>] __vmalloc_node+0x90/0xb5<br> [<ffffffff811247ca>] __vmalloc+0x28/0x3e<br> [<ffffffff818504c9>] alloc_large_system_hash+0x12f/0x1fb<br> [<ffffffff81852b4e>] vfs_caches_init+0xb8/0x140<br> [<ffffffff8182b061>] start_kernel+0x3ef/0x44c<br> [<ffffffff8182a2d0>] x86_64_start_reservations+0xbb/0xd6<br> [<ffffffff8182e6d1>] xen_start_kernel+0x5ab/0x5b2<br> [<ffffffffffffffff>] 0xffffffffffffffff<br><br>other info that might help
us debug this:<br><br>2 locks held by khubd/28:<br> #0: (usb_address0_mutex){+.+...}, at: [<ffffffff813b2e82>] hub_port_init+0x8c/0x7ee<br> #1: (&ehci->lock){-.....}, at: [<ffffffff813d4654>] ehci_urb_enqueue+0xb4/0xd5c<br><br>the HARDIRQ-irq-safe lock's dependencies:<br>-> (&ehci->lock){-.....} ops: 0 {<br> IN-HARDIRQ-W at:<br> [<ffffffff8109908b>] __lock_acquire+0x254/0xc0e<br> [<ffffffff81099b33>] lock_acquire+0xee/0x12e<br> [<ffffffff8150b987>]
_spin_lock+0x45/0x8e<br> [<ffffffff813d325c>] ehci_irq+0x41/0x441<br> [<ffffffff813b7e5f>] usb_hcd_irq+0x59/0xcc<br> [<ffffffff810ca810>] handle_IRQ_event+0x62/0x148<br> [<ffffffff810ccda3>] handle_level_irq+0x90/0xf9<br><br>. . . . . .<br><br>Jeremy's current version is rc6. I believe this issue has been noticed at
xen-devel.<br>Boris<br><br><br><br></td></tr></tbody></table><br>
</div><br>-----Inline Attachment Follows-----<br><br><div class="plainMail">--<br>Fedora-xen mailing list<br><a rel="nofollow">Fedora-xen@redhat.com</a><br><a rel="nofollow" target="_blank" href="https://www.redhat.com/mailman/listinfo/fedora-xen">https://www.redhat.com/mailman/listinfo/fedora-xen</a><br></div></blockquote></td></tr></tbody></table><br>
</div><br>-----Inline Attachment Follows-----<br><br><div class="plainMail">--<br>Fedora-xen mailing list<br><a rel="nofollow">Fedora-xen@redhat.com</a><br><a rel="nofollow" target="_blank" href="https://www.redhat.com/mailman/listinfo/fedora-xen">https://www.redhat.com/mailman/listinfo/fedora-xen</a><br></div></blockquote></td></tr></tbody></table><br>
</div><br>-----Inline Attachment Follows-----<br><br><div class="plainMail">--<br>Fedora-xen mailing list<br><a ymailto="mailto:Fedora-xen@redhat.com" href="/mc/compose?to=Fedora-xen@redhat.com">Fedora-xen@redhat.com</a><br><a href="https://www.redhat.com/mailman/listinfo/fedora-xen" target="_blank">https://www.redhat.com/mailman/listinfo/fedora-xen</a><br></div></blockquote></td></tr></table><br>