Dmesg report for 2.6.31.4 been built on F12 and loaded under Xen 3.4.1
(installed via rawhide 3.4.1-5 ) Dom0 on top of F12 ( yum updated)

[drm] Initialized drm 1.1.0 20060810 [drm] radeon default to kernel modesetting. [drm] radeon kernel modesetting enabled. xen: registering gsi 16 triggering 0 polarity 1 xen_allocate_pirq: returning irq 16 for gsi 16 xen: --> irq=16 xen_set_ioapic_routing: irq 16 gsi 16 vector 152 ioapic 0 pin 16 triggering 1
polarity 1 radeon 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 radeon 0000:01:00.0: setting latency timer to 64 [drm] radeon: Initializing kernel modesetting. [drm:radeon_driver_load_kms] *ERROR* Failed to initialize radeon, disabling
IOCTL radeon 0000:01:00.0: PCI INT A disabled radeon: probe of 0000:01:00.0 failed with error -22

.   .   .   .   .   .

====================================================== [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ] 2.6.31.4 #2

------------------------------------------------------ khubd/28 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:  (&retval->lock){......}, at: [<ffffffff81126fa4>] dma_pool_alloc+0x46/0x312

and this task is already holding:  (&ehci->lock){-.....}, at: [<ffffffff814359e4>] ehci_urb_enqueue+0xb4/0xd7c 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:   [<ffffffff810996d8>] __lock_acquire+0x256/0xc11   [<ffffffff8109a181>] lock_acquire+0xee/0x12e   [<ffffffff81579e9f>] _spin_lock+0x45/0x8e   [<ffffffff814345ec>] ehci_irq+0x41/0x441   [<ffffffff814195d5>] usb_hcd_irq+0x59/0xcc   [<ffffffff810c8200>] handle_IRQ_event+0x62/0x148   [<ffffffff810ca797>] handle_level_irq+0x90/0xf9   [<ffffffff81018038>] handle_irq+0x9a/0xba   [<ffffffff81302342>] xen_evtchn_do_upcall+0x10c/0x1bd   [<ffffffff8101623e>] xen_do_hypervisor_callback+0x1e/0x30   [<ffffffffffffffff>] 0xffffffffffffffff

to a HARDIRQ-irq-unsafe lock:  (purge_lock){+.+...} ... which became HARDIRQ-irq-unsafe at: ...  [<ffffffff8109974d>] __lock_acquire+0x2cb/0xc11   [<ffffffff8109a181>] lock_acquire+0xee/0x12e   [<ffffffff81579e9f>] _spin_lock+0x45/0x8e   [<ffffffff81120137>] __purge_vmap_area_lazy+0x63/0x198   [<ffffffff81121a15>] vm_unmap_aliases+0x18f/0x1b2   [<ffffffff8100e400>] xen_alloc_ptpage+0x47/0x75   [<ffffffff8100e46b>] xen_alloc_pte+0x13/0x15   [<ffffffff81115495>] __pte_alloc_kernel+0x6f/0xdd   [<ffffffff81120f42>] vmap_page_range_noflush+0x1c5/0x315   [<ffffffff811210d3>] map_vm_area+0x41/0x6b   [<ffffffff8112122c>] __vmalloc_area_node+0x12f/0x167   [<ffffffff811212f4>] __vmalloc_node+0x90/0xb5   [<ffffffff81121169>] __vmalloc_area_node+0x6c/0x167   [<ffffffff811212f4>] __vmalloc_node+0x90/0xb5   [<ffffffff8112156b>] __vmalloc+0x28/0x3e   [<ffffffff81adb40a>] alloc_large_system_hash+0x12f/0x1fb   [<ffffffff81addc9a>] vfs_caches_init+0xb8/0x140   [<ffffffff81ab5a69>] start_kernel+0x3ef/0x44c   [<ffffffff81ab4d70>] x86_64_start_reservations+0xbb/0xd6   [<ffffffff81ab93b7>] xen_start_kernel+0x5d5/0x5dc   [<ffffffffffffffff>] 0xffffffffffffffff

other info that might help us debug this:

2 locks held by khubd/28:  #0:  (usb_address0_mutex){+.+...}, at: [<ffffffff81414344>]
hub_port_init+0x8c/0x81e  #1:  (&ehci->lock){-.....}, at: [<ffffffff814359e4>]
ehci_urb_enqueue+0xb4/0xd7c

the HARDIRQ-irq-safe lock's dependencies: -> (&ehci->lock){-.....} ops: 0 {    IN-HARDIRQ-W at:                         [<ffffffff810996d8>] __lock_acquire+0x256/0xc11                         [<ffffffff8109a181>] lock_acquire+0xee/0x12e                         [<ffffffff81579e9f>] _spin_lock+0x45/0x8e                         [<ffffffff814345ec>] ehci_irq+0x41/0x441                         [<ffffffff814195d5>] usb_hcd_irq+0x59/0xcc                         [<ffffffff810c8200>] handle_IRQ_event+0x62/0x148                         [<ffffffff810ca797>] handle_level_irq+0x90/0xf9                         [<ffffffff81018038>] handle_irq+0x9a/0xba                         [<ffffffff81302342>] xen_evtchn_do_upcall+0x10c/0x1bd                         [<ffffffff8101623e>]
xen_do_hypervisor_callback+0x1e/0x30                         [<ffffffffffffffff>] 0xffffffffffffffff .  .  .  .

The most recent build 2.6.31.1 on F12 produced clean dmesg output.  Builds 2.6.31.4 ( same commit on top) on F11 and Ubuntu 9.04 Server seem clean.

Boris.

--- On Thu, 10/15/09, Konrad Rzeszutek Wilk <konr...@oracle.com> wrote:

From: Konrad Rzeszutek Wilk <konr...@oracle.com> Subject: Re: [Xen-devel] Announcing xen/master: pvops git trees rearranged To: "Pasi Kärkkäinen" <pas...@iki.fi> Cc: "Jeremy Fitzhardinge" <jer...@goop.org>, "Xen-devel"
<xen-...@lists.xensource.com> Date: Thursday, October 15, 2009, 4:04 PM

On Thu, Oct 15, 2009 at 12:14:15AM +0300, Pasi Kärkkäinen wrote:

I forgot to mention that you probably need to have CONFIG_DRM set to 'y' instead
of 'm' for this to work. Or you could hack up the initrd (modprobe.conf) and make drm
load with the 'debug=255' parameter.

.. snip ..

Nah. Still has the same problem:

[drm:r100_ring_test] *ERROR* radeon: ring test failed
(sracth(0x15E4)=0xCAFEDEAD) [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-

add here: export LIBGL_DEBUG=verbose

Add this to your kernel command line: plymouth:debug