zhonghong200@163.com wrote:
when my application buffer is not multiple of 512 bytes ,then error as :
Usts 12 00 00 c0 babble detected
There are so many details omitted from this message that it’s almost
impossible to tell what you mean, but I’ll take a stab.
When you make a USB read request, the host controller schedules enough
time in the frame for actually buffer you requested, and then schedules
the next transfer immediately after that. However, when you do a USB
read, the device is never told how much data to send. It is merely told
“GO”.
If you asked for 128 bytes, and the host controller only allowed enough
time for 128 bytes, but your device sends 512 (which it is allowed to
do), then your device is writing over the top of the next device’s time
slot. That is called “babble”. It’s a USB protocol error. If it
occurs at the very end of a frame, it can actually cause the hub to be
shut down.
Always do your bulk reads as a multiple of the endpoint’s packet size.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim Roberts
thank you for you answer.
my camera device usually run well ,for example ,my camera can receive 100 frame,then lose 1 frame ,I don’t know why ? i debug it ,find it timeout ,and cannot receive any data.
and I reduce the size of camera return ,for example my application program buffer is 2014208 ,and now the device return size is 1449472, at this time ,my applciation can not receive any dada.and this problem is too hard to me? can you give me some advice,thank very much indeed.
hong zhong wrote:
my camera device usually run well ,for example ,my camera
can receive 100 frame,then lose 1 frame ,I don’t know why ?
i debug it ,find it timeout ,and cannot receive any data.
You were told a long time ago to get a USB bus analyzer in order to diagnose this problem. I suspect in your “timeout” case, there is some sort of bus error caused by your device. At a minimum, you’ll be able to see if 1) the host continues to issue IN tokens, and 2) if the device is responding to them within specification.
Chris Aseltine : thank you .
I don’t have usb analyzer, and at “timeout” case,the host send In tokens,but device don’t return dada.
and another question, if the device capability (return dada) is less than the application program buffer,it can not receive,for example,my camera is 2 Million Pixel cameras, at this time,let the camera equipment only return 1.4 million pixel dada, the application program buffer is 2 million pixel buffer,at this time ,the application can not receive any dada,but in linux system,at this time ,the application can receive 1.4 million pixel dada. thank you .why this happened.
hong zhong wrote:
I don’t have usb analyzer, and at “timeout” case,the host
send In tokens,but device don’t return dada.
Just curious, if you don’t have an analyzer, how did you come to this conclusion?
Also, why is your device not returning “dada” if it is receiving IN tokens? That seems to be the real problem, the OS is asking for data but your device is not sending it.
and another question, if the device capability (return dada) is
less than the application program buffer,it can not receive,for
example,my camera is 2 Million Pixel cameras, at this time,let
the camera equipment only return 1.4 million pixel dada, the
application program buffer is 2 million pixel buffer,at this time ,
the application can not receive any dada,but in linux system,at
this time ,the application can receive 1.4 million pixel dada. thank
you .why this happened.
Go back to my original post regarding the conditions on which the USB core will complete a read URB back to you. I suspect you’ve sent down a request for 2MB down to USB, and the device has responded with some fraction of that which is an exact multiple of the endpoint’s maximum packet size. Since the device did not send a short packet, the transfer never completed. Some possible solutions:
-
Have the device send a zero-byte packet at the end of each frame;
-
Use a continuous reader and some sort of buffering mechanism;
-
Send reads to the device that are appropriately sized.
zhonghong200@163.com wrote:
I don’t have usb analyzer, and at “timeout” case,the host send In tokens,but device don’t return dada.
and another question, if the device capability (return dada) is less than the application program buffer,it can not receive,for example,my camera is 2 Million Pixel cameras, at this time,let the camera equipment only return 1.4 million pixel dada, the application program buffer is 2 million pixel buffer,at this time ,the application can not receive any dada,but in linux system,at this time ,the application can receive 1.4 million pixel dada. thank you .why this happened.
The word you want is “data”, not “dada”.
You need to debug this in your driver. Print information to the debug
log showing you the size and status values you are getting in your
requests. That’s the only way you’re going to be able to chase this
down. This is NOT the kind of problem we can debug remotely, at least
not without a crystal ball.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
thank you ,Tim Roberts, I debug it and print log,I use windbg and dbgview ,and find that ,when it timeout ,the log show that it have no dada,and the return size is zero. thank you very much indeed.
zhonghong200@163.com wrote:
thank you ,Tim Roberts, I debug it and print log,I use windbg and dbgview ,and find that ,when it timeout ,the log show that it have no dada,and the return size is zero. thank you very much indeed.
The word is “data”, NOT “dada”.
When you say “the return size is zero”, where were you looking, exactly?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
thank you Tim Roberts:
I use dbgview find “UsbSamp: Read request completed with status 0xc00000b5” ,then use windbg debug it find it run in the follow code page ; and I add some print sentence,and find the receive size is zero. at the same time ,i use bus hound watch ,find have no dada. thank you very much indeed.
if (!NT_SUCCESS(status)){
//
// Queue a workitem to reset the pipe because the completion could be
// running at DISPATCH_LEVEL.
//
UsbSamp_DbgPrint(1, (“status not success,and reset pipe\n”));
urb = (PURB) WdfMemoryGetBuffer(rwContext->UrbMemory, NULL);
bytesReadWritten = urb->UrbBulkOrInterruptTransfer.TransferBufferLength;
rwContext->Numxfer += bytesReadWritten;
UsbSamp_DbgPrint(1, (“the transfer size is %d\n”, rwContext->Numxfer));
QueuePassiveLevelCallback(WdfIoTargetGetDevice(Target), pipe);
goto End;
}
zhonghong200@163.com wrote:
thank you Tim Roberts:
I use dbgview find “UsbSamp: Read request completed with status 0xc00000b5” ,then use windbg debug it find it run in the follow code page ; and I add some print sentence,and find the receive size is zero. at the same time ,i use bus hound watch ,find have no dada. thank you very much indeed.
Well, here is a question for the KMDF folks. If I submit a USB request
and set a timeout in the WDF_REQUEST_SEND_OPTIONS, will I be able to
recover whatever partial buffer had been transferred by the time of the
timeout? I’ve never had occasion to test that.
if (!NT_SUCCESS(status)){
//
// Queue a workitem to reset the pipe because the completion could be
// running at DISPATCH_LEVEL.
//
If you have a timeout, you almost certainly do NOT want to reset the pipe.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I would be VERY surprised to discover that works.
Peter
OSR
Tim Roberts wrote:
Well, here is a question for the KMDF folks. If I submit a
USB request and set a timeout in the
WDF_REQUEST_SEND_OPTIONS, will I be able to recover
whatever partial buffer had been transferred by the time
of the timeout?
You forgot to tell him that the word is not “dada”.
It doesn’t work. The WDF request just cancels the irp for you when the timer expires. Kmdf provides this to give you well tested code that hndles the race between timer cancelation/io completion/io cancelation, it does not magically give you partial buffers (WDM can’t do it, so kmdf can’t either)
d
dent from a phpne with no keynoard
-----Original Message-----
From: xxxxx@osr.com
Sent: August 31, 2010 1:45 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] is it the bug of wdk and wdm?
I would be VERY surprised to discover that works.
Peter
OSR
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Doron Holan wrote:
It doesn’t work. The WDF request just cancels the irp for you when the timer expires. Kmdf provides this to give you well tested code that hndles the race between timer cancelation/io completion/io cancelation, it does not magically give you partial buffers (WDM can’t do it, so kmdf can’t either)
Interesting. There must be a solution for this, because there are
situations in USB that cannot be reasonably handled in any other way.
Consider a device that sends between 100k and 200k bytes at random
(potentially long) intervals. You can’t afford to send a bazillion
512-byte requests because of the overhead. You need to send a larger
request, but then you need a way to bring back the partial buffer after
a timeout.
And, as the originally poster pointed out, Linux can do it.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I don’t understand the question: You keep a BIG read (more than 200K) active at the HCD. The read gets completed when the zero-length packet gets sent from the device, and you get back you dada. Done.
You don’t need the timeout.
What’s the problem that I’m missing?
Peter
OSR
Peter Viscarola (OSR) wrote:
I don’t understand the question: You keep a BIG read (more
than 200K) active at the HCD. The read gets completed when
the zero-length packet gets sent from the device, and you get
back you dada. Done.
Exactly (note I said exactly this solution over two days ago now…), whatever this guy is doing to get his partial “dada” is working on Linux (or so he says), but I think the device needs to be modified to properly terminate its transfers with a short packet if it is going to work on Windows.
xxxxx@osr.com wrote:
I don’t understand the question: You keep a BIG read (more than 200K) active at the HCD. The read gets completed when the zero-length packet gets sent from the device, and you get back you dada. Done.
You don’t need the timeout.
What’s the problem that I’m missing?
You are assuming the device is capable of sending a short packet when it
has completed some predefined unit of work. That is not necessarily a
valid assumption. What if the data comes in from some outside source in
a bursty way, so that the device doesn’t know in advance that there will
be a gap?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
xxxxx@gmail.com wrote:
Peter Viscarola (OSR) wrote:
> I don’t understand the question: You keep a BIG read (more
> than 200K) active at the HCD. The read gets completed when
> the zero-length packet gets sent from the device, and you get
> back you dada. Done.
Exactly (note I said exactly this solution over two days ago now…), whatever this guy is doing to get his partial “dada” is working on Linux (or so he says), but I think the device needs to be modified to properly terminate its transfers with a short packet if it is going to work on Windows.
“The device needs to be modified.” You make it sound so simple.
Haven’t you ever worked with a hardware team? Can’t you already hear
the response? “Well, it works on Linux. It’s a valid design according
to the spec. It’s a Windows problem, go make it work.”
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
On 09/02/2010 01:08 AM, Tim Roberts wrote:
You are assuming the device is capable of sending a short packet when it
has completed some predefined unit of work. That is not necessarily a
valid assumption. What if the data comes in from some outside source in
a bursty way, so that the device doesn’t know in advance that there will
be a gap?
Tim, OP claimed the device is a webcam, and it is using a fixed data
block size. So this should not really be a problem here (and Chris is
probably right with his statement).
But of course it *would* help if people seeking assistance actually told
about their setup, instead of letting everyone poke in the dark.
xxxxx@gmail.com wrote:
[…] I think the device needs to be modified to properly terminate
its transfers with a short packet if it is going to work on Windows.
On 09/02/2010 01:17 AM, Tim Roberts wrote:
Haven’t you ever worked with a hardware team? Can’t you already hear
the response? “Well, it works on Linux. It’s a valid design
according to the spec. It’s a Windows problem, go make it work.”
Well, here Chris is backed by the USB 2.0 spec, section 5.8.3:
A bulk transfer is complete when the endpoint does one of the
following: • Has transferred exactly the amount of data expected •
Transfers a packet with a payload size less than wMaxPacketSize or
transfers a zero-length packet
If the OPs device does *not* comply to this, the device violates the USB
standard, it therefore is broken and needs to be fixed (modified).
It does not matter if it works *accidentally* with some versions of
other operating systems, or not.