Prev: ksdebug.h and _DbgPrintF
Next: Windows 7 WDK Mirror Driver Question
From: Tim Roberts on 4 Feb 2009 22:19
Bhavik <bhavik.patel(a)gmail.com> wrote:
>
>In my previous post I mentioned that the the URB status code for
>resetting the pipe is USBD_STATUS_DEV_NOT_RESPONDING.
>But when I submit a write request from my application, the data is
>written successfully though. I can see the completed transactions in
>the Ellisys USB analyzer.
>If the OUT transactions are completed successfully, then how can the
>IN request return USBD_STATUS_DEV_NOT_RESPONDING at the same time?

Pipes are independent.

>Does this error code mean that the device is not responding to any
>request or it means that the device does not respond to only specific
>requests?

The error comes back in a request, and it means the device did not respond
to that request.
--
Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
From: Bhavik on 5 Feb 2009 10:34
Ok, with some more reading about windows driver development in Walter
Oney's book, I am now able to reset my device from my driver.
What I do in my driver is as following:

DispatchreadWrite (...)
{
...
...
if (had_error)
{
if (!NT_SUCCESS(ResetPipe(fdo, hpipe))
{
ResetDevice(fdo);
}
}
....
....
}

I set the had_error in OnReadWriteCompletion routine.

Now in the read request to my device, I get the error
USBD_STATUS_DEV_NOT_RESPONDING.
So first it tries to reset the pipe, but it also returns the same
error code. So it reset the device using IOCTL_INTERNAL_USB_RESET_PORT
IO request.
This time, it succeeds, and I am able to do successful reading next
time.

But I have multiple threads in my application. One for readin from the
device and one for writing to the device.

Now if there is a write request from application, when the read
request submits an IRP to reset the device, the data is written
successfully.
But the device responds with some data when a command data is sent to
the device. This response sometimes loses some data because just after
the write request, the previously stopped read request starts
execution, and it resets the device.

So now, I want to synchronize read and write requests in my driver.

Can I use event in this case to synchronize read and write requests?
Also, please let me know some possible problems if I do this kind of
synchronization in my driver.

Thanks,

Bhavik


On Feb 5, 4:19 am, Tim Roberts <t...(a)probo.com> wrote:
> Bhavik <bhavik.pa...(a)gmail.com> wrote:
>
> >In my previous post I mentioned that the the URB status code for
> >resetting the pipe is USBD_STATUS_DEV_NOT_RESPONDING.
> >But when I submit a write request from my application, the data is
> >written successfully though. I can see the completed transactions in
> >the Ellisys USB analyzer.
> >If the OUT transactions are completed successfully, then how can the
> >IN request return USBD_STATUS_DEV_NOT_RESPONDING at the same time?
>
> Pipes are independent.
>
> >Does this error code mean that the device is not responding to any
> >request or it means that the device does not respond to only specific
> >requests?
>
> The error comes back in a request, and it means the device did not respond
> to that request.
> --
> Tim Roberts, t...(a)probo.com
> Providenza & Boekelheide, Inc.

From: Tim Roberts on 7 Feb 2009 22:29
Bhavik <bhavik.patel(a)gmail.com> wrote:
>...
>But the device responds with some data when a command data is sent to
>the device. This response sometimes loses some data because just after
>the write request, the previously stopped read request starts
>execution, and it resets the device.
>
>So now, I want to synchronize read and write requests in my driver.
>
>Can I use event in this case to synchronize read and write requests?
>Also, please let me know some possible problems if I do this kind of
>synchronization in my driver.

Sure, there are ways to do this kind of synchronization, although it tends
to be quite error prone because of all the edge cases on cleanup, on
surprise removal, on file closing, etc. It's very tricky.

Personally, it seems to me that you are wasting an awful lot of development
time trying to create an ugly patch in software to work around hardware
that is provably broken.
--
Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
From: Bhavik on 9 Feb 2009 03:29
Yes, I know that it's taking a lot of time, but I have to do that.
Because the customer for which I am working, they have already
deployed some of the devices already.
And if they change the hardware, it might cost them a lot of money.

So the customer demands that the least required solution for this
problem is to change the hardware.
If all other ways in software fail, then they might be ready to change
the hardware.

So can you please give me some idea about the synchronization question
I asked in my previous post?
And some concerns which I need to take care of while using the
synchronization?

Regards,

Bhavik

On Feb 8, 4:29 am, Tim Roberts <t...(a)probo.com> wrote:
> Bhavik <bhavik.pa...(a)gmail.com> wrote:
> >...
> >But the device responds with some data when a command data is sent to
> >the device. This response sometimes loses some data because just after
> >the write request, the previously stopped read request starts
> >execution, and it resets the device.
>
> >So now, I want to synchronize read and write requests in my driver.
>
> >Can I use event in this case to synchronize read and write requests?
> >Also, please let me know some possible problems if I do this kind of
> >synchronization in my driver.
>
> Sure, there are ways to do this kind of synchronization, although it tends
> to be quite error prone because of all the edge cases on cleanup, on
> surprise removal, on file closing, etc.  It's very tricky.
>
> Personally, it seems to me that you are wasting an awful lot of development
> time trying to create an ugly patch in software to work around hardware
> that is provably broken.
> --
> Tim Roberts, t...(a)probo.com
> Providenza & Boekelheide, Inc.

From: Tim Roberts on 10 Feb 2009 01:25
Bhavik <bhavik.patel(a)gmail.com> wrote:
>
>Yes, I know that it's taking a lot of time, but I have to do that.
>Because the customer for which I am working, they have already
>deployed some of the devices already.
>And if they change the hardware, it might cost them a lot of money.
>
>So the customer demands that the least required solution for this
>problem is to change the hardware.
>If all other ways in software fail, then they might be ready to change
>the hardware.

Let me try to explain what you're up against. You have seen how one
specific host controller in one computer behaves when it encounters this
situation. However, because this is a protocol violation, you have no
guarantees that it's going to behave the same way on other machines. Your
"reset" scheme might make it work on your computer, but what about other
computers? What about hosts with hubs, or hubs-in-hubs-in-hubs?

>So can you please give me some idea about the synchronization question
>I asked in my previous post?
>And some concerns which I need to take care of while using the
>synchronization?

I can't really answer that; you're the only one that knows what your
requests are and how they are related. You can use a cancel-safe queue to
hold a request in a relatively safe way, if you need to, but you're the
only one who can draw up the flowchart that works out how the requests come
out of the queue.
--
Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
First  |  Prev  | 
Pages: 1 2 3
Prev: ksdebug.h and _DbgPrintF
Next: Windows 7 WDK Mirror Driver Question