RE: RE: blue screen in windows balloon driver

["James Harper" <james.harper@bendigoit.com.au>]

> 
> Two crash logs attached.
> 
> The last two XenVbd_HwScsiResetBus happened almost at the same time.
> May it be the problem?
> 

Timestamps are in milliseconds.

HwScsiResetBus completes the queued requests not yet sent to Dom0 with a
status of SRB_STATUS_BUS_RESET. It can't touch the requests on the ring
so what it does then is set their status to SRB_STATUS_BUS_RESET and
then checks for that when Dom0 signals that they are complete.

The first reset at 12943529855375 is completed in under 1 second. All
the requests on the ring are marked with SRB_STATUS_BUS_RESET and then
they complete shortly after and the system seems to recover.

The second reset happens at 12943530977390. All the requests on the ring
are marked but it is 12 seconds before Dom0 completes one of them. Two
more are completed immediately and then 10 seconds later still no more
requests are completed by Dom0 and Windows issues another reset. This
time after 5 seconds all the requests are finished by Dom0.

The last reset happens at 12943531085390. At 12943531148593 (over 60
seconds later) with no response from Dom0, Windows finally gives up and
crashes.

I don't think the problem really lies with GPLPV and I don't think there
is anything I can do about it. Maybe you could look at the IO scheduling
policy. It seems that maybe Dom0 is not servicing IO requests fairly
from your DomU's. Either that or there is a bug in Dom0 and your disk IO
requests are getting stuck under high IO load.

I could be wrong and it is a bug in GPLPV but I can't see any evidence
of it.

James