RE: [Xen-devel] Dom0 hang caused by DomU crash

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

softlockup is a mechanism to check system goodness. One specific
thread is created per cpu and below warning jumps out when it's not
scheduled within predefined period (default 10s). So it's likely to be 
backend in dom0 blocking on request to frontend in domU, and in
the meantime Windows crash dump prevents frontend to respond
immediately. If there's nothing wrong for such a long non-response
period, backend driver may be changed accordingly to not block
scheduler at given point...

Thanks,
Kevin

>From: James Harper
>Sent: 2008年5月26日 10:15
>
>I have found that I can hang Dom0 for upwards of 5 minutes from DomU
>when I use my GPL PV drivers. Can anyone tell me something about this
>crash?:
>
>"
>BUG: soft lockup detected on CPU#0!
>
>Call Trace:
> <IRQ> [<ffffffff8029fb2c>] softlockup_tick+0xdb/0xed
> [<ffffffff80267dba>] timer_interrupt+0x38d/0x3db
> [<ffffffff80211154>] handle_IRQ_event+0x2d/0x60
> [<ffffffff8029fe6b>] __do_IRQ+0xa4/0x105
> [<ffffffff8028364e>] _local_bh_enable+0x59/0xb3
> [<ffffffff802665a8>] do_IRQ+0x65/0x73
> [<ffffffff80360feb>] evtchn_do_upcall+0x86/0xe0
> [<ffffffff8025c616>] do_hypervisor_callback+0x1e/0x2c
> <EOI> [<ffffffff8020622a>] hypercall_page+0x22a/0x1000
> [<ffffffff8020622a>] hypercall_page+0x22a/0x1000
> [<ffffffff803607c4>] force_evtchn_callback+0xa/0xb
> [<ffffffff8036a7a3>] make_response+0xeb/0x131
> [<ffffffff8036b020>] blkif_schedule+0x24f/0x328
> [<ffffffff8028fa70>] autoremove_wake_function+0x0/0x2e
> [<ffffffff8028f8ad>] keventd_create_kthread+0x0/0x61
> [<ffffffff8036add1>] blkif_schedule+0x0/0x328
> [<ffffffff8028f8ad>] keventd_create_kthread+0x0/0x61
> [<ffffffff8023352b>] kthread+0xd4/0x107
> [<ffffffff8025c86c>] child_rip+0xa/0x12
> [<ffffffff8028f8ad>] keventd_create_kthread+0x0/0x61
> [<ffffffff80233457>] kthread+0x0/0x107
> [<ffffffff8025c862>] child_rip+0x0/0x12
>"
>
>This is happening when the windows DomU is performing a crash dump
>(manually triggered). The windows crash dump environment for scsiport
>drivers (which xenvbd is) is at a very high IRQL, eg with all 
>interrupts
>disabled. Apart from making it a real pain to code for, I 
>think it might
>have something to do with this crash...
>
>After 5 or so minutes, Dom0 comes good again, and DomU gets a bit
>further down the crash dump path before really crashing hard. The point
>at which the Dom0 'BUG' occurs is before the final DomU crash though...
>
>Can anyone tell me what sort of conditions could cause this to 
>happen to
>Dom0?
>
>Thanks
>
>James
>
>_______________________________________________
>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