KMDF1.5: Reading from USB interrupt endpoints
Johan Paul
Just a short question I have been wondering for a while now and I
would like to get this cleared; Am I right that I can read from a USB
interrupt endpoint in the same way I can read from a bulk endpoint? In
other words, I do not need to worry about if the endpoint is bulk or
interrupt as long as I parse the interface+endpoint descriptors right
and find my pipes? I remember reading from the Windows Driver
Foundation book that KMDF supports both bulk and interrupt endpoints,
but does this imply what I stated above?
I know that the osrusbfx2 example uses a continuous reader for an
interrupt endpoint, but I would like to read from the interrupt
endpoint just as I would from an bulk endpoint.
Now I just seem to have a problem that when I send a read request to
an interrupt endpoint the request's completion routine is never called
- although I can see from USB bus traces that the host controller ACKs
the IN transaction for the read - and thus the read request from the
user space application never returns.
I can successfully read from bulk endpoints with this same code - the
only difference is the endpoint's type.
What am I missing? Thanks!
BR,
Johan
![Doron Holan [MSFT]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Doron Holan [MSFT]
using the same APIs that you read/write to an bulk endpoint
d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Johan Paul" <johan...@gmail.com> wrote in message
news:dfa6b5b5-6bd9-4a57...@x41g2000hsb.googlegroups.com...
Johan Paul
have any ideas why I now seem to miss the completion routine although
the host controller ACKs the IN transaction? Do you know, for example,
if some host controllers would have issues with this? I am sure the same
code works, for example, inside VMWare (VMWare running XP32, Vista32
inside VMWare) but I tested this today on my AMD64 laptop with Vista32
installed on it and saw that the read never completes.
I thought I would try tomorrow to do the read operation synchronously to
see if that makes a differance.
--
Johan
Randy Aull (MSFT)
interrupt endpoint is larger than what the device is returning, and the
device happens to be returning a multiple of its MaxPacketSize, then your
request will not complete as it is waiting for more data from the device.
"Johan Paul" <johan...@gmail.com> wrote in message
news:NNW1k.13020$_03....@reader1.news.saunalahti.fi...
Johan Paul
Thanks for your answer. I have to look more into this, but I can say
that wMaxPacketSize the the interrupt endpoint is 64 bytes and I get
36 bytes of data that is ACKed. Before the ACKed transaction, I see
one NAKed IN transaction from that endpoint but that is ok.
I am more confused that the reading is definitely working in Vista32
inside VMWare but not on my laptop running Vista32. I will have to
look into this more today...
--
Johan
> What you may be missing is the packet size. If your request to the
> interrupt endpoint is larger than what the device is returning, and the
> device happens to be returning a multiple of its MaxPacketSize, then your
> request will not complete as it is waiting for more data from the device.
>
> "Johan Paul" <johan.p...@gmail.com> wrote in message
chris.a...@gmail.com
> Thanks for your answer. I have to look more into this, but I can say
> that wMaxPacketSize the the interrupt endpoint is 64 bytes and I get
> 36 bytes of data that is ACKed. Before the ACKed transaction, I see
> one NAKed IN transaction from that endpoint but that is ok.
It might help to place a lower filter between your KMDF function
driver and the usbhub PDO. That way, you can see if usbhub is
completing the URB and KMDF is somehow mishandling it, or if the data
just simply isn't coming back from the host controller.
Doron Holan [MSFT]
processing of the completion routine is rather trivial. if you really think
that KMDF is busted you can do one of 2 things
1) send your own URB in your own PIRP and set your own WDM completion
routine and see if your wdm c.r. runs. you can get the pipe handle from the
WDFUSBPIPE to do that
2) before sending the wdfrequest, break into the debugger, run
!wdfkd.wdfrequest <WDFREQUEST> to retrieve the PIRP, run !irp <PIRP> on that
irp and set a bp on the KMDF completion routine and see if it fires
d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
<chris.a...@gmail.com> wrote in message
news:548077ef-c752-4bce...@q24g2000prf.googlegroups.com...
chris.a...@gmail.com
wrote:
> i really doubt KMDF is mishandling the i/o. for such a simple case, the
> processing of the completion routine is rather trivial.
So do I, was just offering friendly advice :)
Johan Paul
Thanks to you and Chris for your replies!
I have a bit more information regarding this. Now I have tested the
same driver (based on KMDF 1.5) with the same device on two different
laptops both running XP32. My interrupt connection works great on the
other one, but not on the other one. I mention more details in a short
moment. First I want to say that the reason I cannot read from the non-
working machine is the lack of IN tokens going to the device. I see
from my driver traces that the READ request is sent down to the parent
driver and from there down parent's FDO stack down to host controller.
This request never completes on the other machine and on the bus I
cannot see any IN tokens...
Now, as I said the two machines run the same user mode applications
and the same driver and the same device was connected to both of
them.
Interrupt read works on Lenovo T61 with Intel ICH8 Family USB
Universal Host Controller - 2835.
Interrupt read does NOT work on HP Compaq nx6325 with "Standard
OpenHCD USB Host Controller". Drivers from Microsoft dated 7/1/2001,
version 5.1.2600.2180.
I don't know what to go from here.. Is there anything I can check from
my source code regarding interrupt reading? The same read code is used
for bulk endpoints and it has always worked.
--
Johan
> i really doubt KMDF is mishandling the i/o. for such a simple case, the
> processing of the completion routine is rather trivial. if you really think
> that KMDF is busted you can do one of 2 things
> 1) send your own URB in your own PIRP and set your own WDM completion
> routine and see if your wdm c.r. runs. you can get the pipe handle from the
> WDFUSBPIPE to do that
>
> 2) before sending the wdfrequest, break into the debugger, run
> !wdfkd.wdfrequest <WDFREQUEST> to retrieve the PIRP, run !irp <PIRP> on that
> irp and set a bp on the KMDF completion routine and see if it fires
>
> d
> --
> Please do not send e-mail directly to this alias. this alias is for
> newsgroup purposes only.
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> <chris.aselt...@gmail.com> wrote in message
Johan Paul
> > processing of the completion routine is rather trivial.
>
> So do I, was just offering friendly advice :)
Thanks Chris for the suggestion to set a filter driver below my parent
FDO. Now I see that the read request never returns from the USB host
controller to my parent FDO.
Br,
Johan
Johan Paul
> processing of the completion routine is rather trivial. if you really think
> that KMDF is busted you can do one of 2 things
Hi Doron,
So now, thanks to a filter driver below my KMDF parent driver, I know
that the read request never returns from the host controller to the
parent driver. So I guess KMDF would handle this read ok if it would
arrive from the host controller :)
But my big question is now, that I have also tested this interrupt
read with a WDM based driver, and the read works with that driver! Any
ideas why KMDF would make a difference that the host controller now
behaves this way?
--
Johan
chris.a...@gmail.com
> But my big question is now, that I have also tested this interrupt
> read with a WDM based driver, and the read works with that driver! Any
> ideas why KMDF would make a difference that the host controller now
> behaves this way?
If you set numPendingReads to 'one' for your continuous reader, what
happens?
Rarely, I've encountered host controller drivers that were so brain
dead, they didn't understand having more than one URB pended at them
(typically PCMCIA-to-USB bridge type devices).
Johan Paul
> > behaves this way?
>
> If you set numPendingReads to 'one' for your continuous reader, what
> happens?
Well, actually, as a describe in my original message, i want to read
the interrupt endpoint just as I read a bulk endpoint. Now I have code
that processes read requests to different interfaces and the only
difference is the endpoint's type. And as Doron replied to me already,
reading an interrupt endpoint in KMDF should work the same way as I
would read a bulk endpoint.
> Rarely, I've encountered host controller drivers that were so brain
> dead, they didn't understand having more than one URB pended at them
> (typically PCMCIA-to-USB bridge type devices).
In my case I can, as I mentioned earlier, see one IN request that is
ACKed to the device. However, thanks to your suggestion about a lower
filter driver for my parent, I see that this request never comes back
to me. Also the read should be pending, so I guess the host controller
should send IN tokens all the time (once every interval-value) but I
don't see any of those either on the bus after this occurs.
chris.a...@gmail.com
> > If you set numPendingReads to 'one' for your continuous reader, what
> > happens?
>
> Well, actually, as a describe in my original message, i want to read
> the interrupt endpoint just as I read a bulk endpoint. Now I have code
> that processes read requests to different interfaces and the only
> difference is the endpoint's type. And as Doron replied to me already,
> reading an interrupt endpoint in KMDF should work the same way as I
> would read a bulk endpoint.
I'm proposing that you do the experiment of setting numPendingReads to
1 just to see if it changes anything. You don't have to leave it that
way or change your design.