Re: [Xen-devel] 2.6.23.8 paravirt block hang

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

What kernel version is dom0? Presumably not 2.6.23.8 pv_ops, since pv_ops
does not yet support dom0 operation.

Since it looks like the lockups are in dom0, does it work okay without
2.6.23.8 guests?

 -- Keir

On 25/11/07 17:30, "Christopher S. Aker" <caker@xxxxxxxxxxxx> wrote:

> I have a test user reporting hangs during disk IO on paravirt_ops
> 2.6.23.8, Xen 3.1.2 (64 bit Xen, pae host and guest).  Blocked processes
> continue to go up until the system is unusable.  No output on the
> guest's dmesg, nor anything unusual on the dom0 is logged.
> 
> root@dallas38:/xendev# xm block-list xen8
> Vdev  BE handle state evt-ch ring-ref BE-path
> 51712    0    0     4      15     8
> /local/domain/0/backend/vbd/96/51712
> 51728    0    0     4      16     9
> /local/domain/0/backend/vbd/96/51728
> 
> 
> blkback.96.xv S C037369D     0   851     19           852 16848 (L-TLB)
>         cab1df24 00000246 cc3b6580 c037369d c0101227 cea24684 cea24684
> 266fbeb5
>         0001c834 00001868 00000000 cab1dfbc ca365030 267124fc 0001c834
> c1213920
>         00000000 4ddd48df 00000001 c6f76040 cab1dfbc c9e9b954 c02c373b
> cfac4b84
> Call Trace:
>   [<c037369d>] scsi_dispatch_cmd+0x180/0x2a5
>   [<c02c373b>] __generic_unplug_device+0x1f/0x25
>   [<c02c3ebc>] generic_unplug_device+0x15/0x42
>   [<c03e389b>] dm_table_unplug_all+0x21/0x2a
>   [<c01304cb>] prepare_to_wait+0x12/0x4f
>   [<c0353d55>] blkif_schedule+0x359/0x574
>   [<c04918fb>] schedule+0x394/0x879
>   [<c0130360>] autoremove_wake_function+0x0/0x37
>   [<c03539fc>] blkif_schedule+0x0/0x574
>   [<c013029a>] kthread+0xde/0xe2
>   [<c01301bc>] kthread+0x0/0xe2
>   [<c0102b75>] kernel_thread_helper+0x5/0xb
> blkback.96.xv S C9037F10     0   852     19                 851 (L-TLB)
>         c9037f24 00000246 00000002 c9037f10 00000001 cfa0050c cfac4b84
> dfbc6185
>         0001c4c2 00000776 00000000 c9037fbc cfafa570 dfbcc1b2 0001c4c2
> c1213920
>         c02c3662 0007088d 00000000 d04503c0 c9037fbc c9e9b3a8 c02c373b
> cfac4b84
> Call Trace:
>   [<c02c3662>] blk_remove_plug+0x38/0x6f
>   [<c02c373b>] __generic_unplug_device+0x1f/0x25
>   [<c02c3ebc>] generic_unplug_device+0x15/0x42
>   [<c03e389b>] dm_table_unplug_all+0x21/0x2a
>   [<c0353d55>] blkif_schedule+0x359/0x574
>   [<c04918fb>] schedule+0x394/0x879
>   [<c0130360>] autoremove_wake_function+0x0/0x37
>   [<c03539fc>] blkif_schedule+0x0/0x574
>   [<c013029a>] kthread+0xde/0xe2
>   [<c01301bc>] kthread+0x0/0xe2
>   [<c0102b75>] kernel_thread_helper+0x5/0xb
> 
> Do either of these stacks look unusual?
> 
> Have any other hints on how to further debug this?  He can reproduce it
> quite easily (un/tarring kernel ball, git --reset, etc).
> 
> -Chris
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel