This might be a side effect of using 4.0, blktap2, and a very new pv_ops
kernel. blktap2 support added code to pause/unpause blktap2 devices on the
domain pause/unpause path (I don''t know why -- no other backend device
type
needs such special treatment) -- it looks like that which is hanging on this
particular dom0 kernel. Try not using blktap2, or try an older pv_ops
kernel, or even try removign the obvious blktap2-specific code from the
pause and unpause methods in xen/xend/XendDomainInfo.py in xend.
-- Keir
On 26/04/2010 11:44, "Leandro Neves de Oliveira"
<leandro-xen@dataworks.com.br> wrote:
>
> I''ve trying Xen 4.0 on Ubuntu 9.10. (xen-test-ubuntu
> 2.6.32.11-xen0-amd64 #8 SMP x86_64), but i have some problem
> with xm pause command. It hangs.
>
> After about 120 seconds I have the follow syslog message:
>
> [58921.334917] INFO: task xend:27739 blocked for more than 120
> seconds.
> [58921.334923] "echo 0
>> /proc/sys/kernel/hung_task_timeout_secs"
> disables this message.
> [58921.334926] xend D 0000000000007ac0 0 27739
> 22471
> 0x00000000
> [58921.334930] ffff880039cebc08 0000000000000282
> 0000000000000002
> ffffffff809d8240
> [58921.334934] 00000000000080d0 00000c0c00000000
> ffff88006f451c18
> ffff88006f451c00
> [58921.334937] ffff88000bf7c768 ffff880039cebfd8
> 0000000000007b28
> ffff88000bf7c768
> [58921.334941] Call Trace:
> [58921.334950] [<ffffffff8022affc>] ? __enqueue_entity
> +0x7c/0x80
> [58921.334953] [<ffffffff8023523c>] ?
enqueue_entity+0xbc/0x350
> [58921.334958] [<ffffffff8072a53d>] schedule_timeout
> +0x1fd/0x2d0
> [58921.334961] [<ffffffff80237951>] ? dequeue_entity
> +0x1a1/0x1e0
> [58921.334964] [<ffffffff8022ae9b>] ? __dequeue_entity
> +0x2b/0x50
> [58921.334967] [<ffffffff80237758>] ?
set_next_entity+0x88/0x90
> [58921.334970] [<ffffffff8072a160>]
wait_for_common+0x100/0x200
> [58921.334973] [<ffffffff80230200>] ? default_wake_function
> +0x0/0x10
> [58921.334977] [<ffffffff80306d70>] ? ifind_fast+0x70/0xc0
> [58921.334980] [<ffffffff8072a2f8>] wait_for_completion
> +0x18/0x20
> [58921.334985] [<ffffffff8035b8b8>] sysfs_addrm_finish
> +0x298/0x2e0
> [58921.334988] [<ffffffff803593a6>] sysfs_hash_and_remove
> +0x56/0x80
> [58921.334992] [<ffffffff8035a170>]
sysfs_remove_file+0x10/0x20
> [58921.334996] [<ffffffff804e26b2>] device_remove_file
> +0x12/0x20
> [58921.335000] [<ffffffff80512d27>]
blktap_sysfs_pause_device
> +0xe7/0x130
> [58921.335003] [<ffffffff804e177b>] dev_attr_store+0x1b/0x20
> [58921.335006] [<ffffffff80359c30>]
sysfs_write_file+0xe0/0x160
> [58921.335011] [<ffffffff802ef698>] vfs_write+0xb8/0x1a0
> [58921.335014] [<ffffffff8072f0b2>] ?
do_page_fault+0x1a2/0x370
> [58921.335017] [<ffffffff802f013c>] sys_write+0x4c/0x80
> [58921.335021] [<ffffffff80209bc8>] system_call_fastpath
> +0x16/0x1b
> [58921.335024] [<ffffffff80209b60>] ? system_call+0x0/0x52
>
>
> Then, after a "xm destroy" command, xen doesn''t work
more. If I
> do "xm create windowsXP.cfg" again I received the follow message:
>
> Using config file "./windowsXP.cfg".
> Error: Device 768 (tap2) could not be connected. Hotplug scripts not
> working.
>
> No substancial messages at xend.log or xend-debug.log.
>
>
> The same windows machine is working on a 2.6.31.8-xen0-amd64 #1
> SMP Tue
> Apr 6 17:04:48 BRT 2010 x86_64 with Xen 3.4.2.
>
> Someone can help me?
>
> Att,
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel