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@lists.xensource.com
http://lists.xensource.com/xen-devel
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@theshore.net> 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@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote:> 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?Dom0 is 2.6.18, from Xen 3.1.2. DomU works fine under 2.6.18 (also from Xen 3.1.2) -- 30 loops through an untar/delete/untar loop without problems. Reboot domU into 2.6.23.3 and the hang happens within the first few loops through. -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel