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