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
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
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