BSoD with GPLPV + tap:aio

[James Harper]

When I use my GPLPV drivers with tap:aio, I get a random BSoD after a
while, normally 0x0000000A.

Can anyone suggest what could be different with file|phy vs tap:aio that
might cause a problem? Is tap:aio otherwise known to be good?

Thanks

James

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

[James Harper]

>
> When I use my GPLPV drivers with tap:aio, I get a random BSoD after a
> while, normally 0x0000000A.
>
> Can anyone suggest what could be different with file|phy vs tap:aio
that
> might cause a problem? Is tap:aio otherwise known to be good?
>

Forgot to add, the underlying file is sparse.

Thanks

James

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

[Paul Durrant]

James Harper wrote:
> When I use my GPLPV drivers with tap:aio, I get a random BSoD after a
> while, normally 0x0000000A.
>
> Can anyone suggest what could be different with file|phy vs tap:aio that
> might cause a problem? Is tap:aio otherwise known to be good?
>

I guess the main difference is likely to be blkback vs. blktap. Guessing
from the minimal info., I'm guessing you're probably hitting a state
model problem. Was there any significant PnP going on when you got the BSOD?

   Paul

--
===============================
Paul Durrant, Software Engineer
Citrix Systems (R&D) Ltd.
===============================

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

[James Harper]

>
> James Harper wrote:
> > When I use my GPLPV drivers with tap:aio, I get a random BSoD after
a
> > while, normally 0x0000000A.
> >
> > Can anyone suggest what could be different with file|phy vs tap:aio
that
> > might cause a problem? Is tap:aio otherwise known to be good?
> >
>
> I guess the main difference is likely to be blkback vs. blktap.
Guessing
> from the minimal info., I'm guessing you're probably hitting a state
> model problem. Was there any significant PnP going on when you got the
BSOD?
>

No PnP. I/O was being saturated though - I was performing a restore via
network to the disk on the machine that crashed.

Using phy: or file: I can restore 600GB with no problems at all. With
tap:aio it crashes after a few tens of GB.

James

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

[Paul Durrant]

James Harper wrote:
>
> No PnP. I/O was being saturated though - I was performing a restore via
> network to the disk on the machine that crashed.
>
> Using phy: or file: I can restore 600GB with no problems at all. With
> tap:aio it crashes after a few tens of GB.
>

Another guess then... tap will probably have more outstanding
transactions than back as its datapath is likely to be longer and so is
higher latency. Is your frontend overflowing a queue of outstanding SRBs?

   Paul

--
===============================
Paul Durrant, Software Engineer

Citrix Systems (R&D) Ltd.
First Floor, Building 101
Cambridge Science Park
Milton Road
Cambridge CB4 0FY
United Kingdom

TEL: x35957 ([phone])
===============================

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

[James Harper]

>
> James Harper wrote:
> >
> > No PnP. I/O was being saturated though - I was performing a restore
via
> > network to the disk on the machine that crashed.
> >
> > Using phy: or file: I can restore 600GB with no problems at all.
With
> > tap:aio it crashes after a few tens of GB.
> >
>
> Another guess then... tap will probably have more outstanding
> transactions than back as its datapath is likely to be longer and so
is
> higher latency. Is your frontend overflowing a queue of outstanding
SRBs?
>

Thanks, that's a good lead. I think Windows is pretty limiting in the
amount of outstanding I/O that it allows (16 outstanding requests?) but
maybe that is too much for tap... I'll double check that I am catering
for a ring-full condition.

James

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