WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] 2.6.23.8 paravirt block hang

To: xen devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] 2.6.23.8 paravirt block hang
From: "Christopher S. Aker" <caker@xxxxxxxxxxxx>
Date: Sun, 25 Nov 2007 12:30:16 -0500
Delivery-date: Sun, 25 Nov 2007 09:29:56 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
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

<Prev in Thread] Current Thread [Next in Thread>