Re: Linux UVC driver can not handle urb_submit error

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear Alan,
Below is my comments.

2011/6/1 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
> On Wed, 1 Jun 2011, Soho Soho123 wrote:
>
>> Dear Alan,
>>
>>
>> We have questions:
>> We still do not get unstanding about :why we get -FEBIG error when uvc
>> driver re-submit urb yet.
>> Because we try to use another platform that CPU is faster. The error
>> is still occur.
>> And,the amount of URB is 5 totally.
>> the another platform : CPU 620MHz, RAM 64MB
>
> Do you still see "now" > stream->next_uframe + 160?

Soho: Yes, you could check the picture that I attached in last e-mail.

>
>> if each urb must use 5 iTDs, then  totally 25 iTDs will be occupied in
>> schedule list. The max schedule list is also large enough for that.
>> And the new urb will be submit when the previous urb had complete.
>> it is strange why urb submit is too late: in iso_stream_schedule()
>> start - now is negative
>> Do you have idea?
>
> Look at an example you posted earlier:
>
> [1943592448] iso_stream_schedule:line=1514, request 81631800 would overflow (3908+31 >= 3936)
> [1943592448] iso_stream_schedule
> [1943592448] mod=4096, span=32
> [1943592448] now=1195
> [1943592448] start=5103
> [1943592448] next=1195
> [1943592448] period=1
> [1943592448] excess=3907
> [1943592448] stream->next_uframe=1007
> [1943592448] uvcvideo: Failed to resubmit video URB (-27).
>
> This means that the last URB ended in microframe 1006.  The URB
> being submitted should start in microframe 1007.  But "now" indicates
> that the current microframe is 1195, so the URB was submitted 188
> microframes late!  That's more than 23 ms after the previous URB
> completed, so you have an interrupt latency of 23 ms or more.
>
>> About the precision of timestamp that I post from usbmon.
>> the precision is in microsecond, do you mean nano is needed, right?
>
> No.  Look at the timestamps; you'll see that even though the times
> printed are in microseconds, the last four digits are always 2448.
> (That's also true in the log messages above.)  This means the actual
> precision is only 10 ms.
>

Soho: in our platform the time precision is 10ms per tick .

> Alan Stern
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux