URB_FUNCTION_ABORT_PIPE in a bus driver

NTDEV
1

Hello,

i am writing a virtual bus driver and i need some help for the implementation of URB_FUNCTION_ABORT_PIPE.

At the moment URB_FUNCTION_ABORT_PIPE is implemented as follow:

  1. Cancel all outstanding IRPs for the pipe

irp->IoStatus.Status = STATUS_CANCELD;
irp->IoStatus.Information = 0;

IoCompleteRequest(irp, IO_NO_INCREMENT);

  1. Complete the URB_FUNCTION_ABORT_PIPE IRP

irp->IoStatus.Status = STATUS_SUCCESS;

Is this behaviour correct ?

I am very grateful for every help

2

xxxxx@seh.de wrote:

i am writing a virtual bus driver and i need some help for the implementation of URB_FUNCTION_ABORT_PIPE.

At the moment URB_FUNCTION_ABORT_PIPE is implemented as follow:

  1. Cancel all outstanding IRPs for the pipe

irp->IoStatus.Status = STATUS_CANCELD;
irp->IoStatus.Information = 0;

IoCompleteRequest(irp, IO_NO_INCREMENT);

  1. Complete the URB_FUNCTION_ABORT_PIPE IRP

irp->IoStatus.Status = STATUS_SUCCESS;

Is this behaviour correct ?

I am very grateful for every help

That looks fundamentally correct. Does this not work for you?

Also remember that, if you have already submitted these requests
somewhere else, you need to make sure they get canceled there as well.
If you cancel the IRP, and then the live hardware that you are proxying
actually completes them later, that’s a blue screen.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

>At the moment URB_FUNCTION_ABORT_PIPE is implemented as follow:

  1. Cancel all outstanding IRPs for the pipe

irp->IoStatus.Status = STATUS_CANCELD;
irp->IoStatus.Information = 0;

IoCompleteRequest(irp, IO_NO_INCREMENT);

  1. Complete the URB_FUNCTION_ABORT_PIPE IRP

irp->IoStatus.Status = STATUS_SUCCESS;

Is this behaviour correct ?

The bus driver should attempt to return an accurate transfer length even when transfers are aborted or canceled.

For example, if the transfer request was an IN for 1024 bytes an the device returned 512 bytes before NAKing forever, the bus driver should indicate that 512 bytes were transferred from the device to host, not zero bytes.

Some client drivers might not care how much data was actually transferred when an in progress transfer was aborted or canceled, but it might be important to some client drivers.

4

> For example, if the transfer request was an IN for 1024 bytes an the device

returned 512 bytes before NAKing forever

Am I wrong that “NAK forever” is not abort or cancel, but the “no more data
yet” situation?

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

5

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Maxim S. Shatskih[SMTP:xxxxx@storagecraft.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, November 13, 2007 9:46 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] URB_FUNCTION_ABORT_PIPE in a bus driver

> For example, if the transfer request was an IN for 1024 bytes an the device
>returned 512 bytes before NAKing forever

Am I wrong that “NAK forever” is not abort or cancel, but the “no more data
yet” situation?

You’re right but the original question was how to handle abort or cancel requested by client/application. In above scenario application asks for 1024 bytes, device returns 512 and NAKs forever because don’t have more data. Application request is blocked so app has to use abort or cancel pipe IOCTL to finish processing.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

6

Thank you very much for your replies and sorry for my late response.
The last days i was out of the office.

@Tim Roberts

That looks fundamentally correct. Does this not work for you?

I have a problem with a BSOD and i don’t know the reason. I only
want to assure that the implementation of URB_FUNCTION_ABORT_PIPE
is correct. I will create a new thread in this forum with a question
about the BSOD.

Also remember that, if you have already submitted these requests
somewhere else, you need to make sure they get canceled there as well.
If you cancel the IRP, and then the live hardware that you are proxying
actually completes them later, that’s a blue screen.

I think that can not happen in my bus driver.

Best Regards,

Stefan Witt