On Sat, 16 Nov 2013, yoma sophian wrote:
> hi all:
> When capturing audio through HS webcam by iso protocol under my
> embedded system, I can hear the audio is not continuous.
The problem is that sometimes the URBs don't get submitted soon enough.
> Then I check usb mon and i found sometime the return status will be
> EXDEV like below:
> (below is partial and detail log is attach in the mail)
I have shortened the lines to make the log easier to read:
> d8a81c00 99049439 C Zi:1:003:2 0:8:5535:0 10 0:0:96 0:512:96
> d8a81c00 99050046 S Zi:1:003:2 -115:8:0 10 -18:0:512 -18:512:512
Here URB d8a81c00 was resubmitted about 0.6 ms after it completed.
That's normal.
> d8a81a00 99059580 C Zi:1:003:2 0:8:5615:0 10 0:0:100 0:512:100
> d8a81c00 99069328 C Zi:1:003:2 0:8:5695:0 10 0:0:100 0:512:100
And then it completed 19.3 ms after submission. Again normal.
> d8a81a00 99078681 S Zi:1:003:2 -115:8:0 10 -18:0:512 -18:512:512
But here URB d8a81a00 wasn't resubmitted until 19.1 ms after it
completed. The latency was more than 18 ms! d8a81c00 completed at
timestamp 99069328, so d8a81a00 should have been resubmitted before
then. But it wasn't; it was submitted about 10 ms too late.
> d8a81c00 99080252 S Zi:1:003:2 -115:8:0 10 -18:0:512 -18:512:512
> d8a81a00 99094075 C Zi:1:003:2 0:8:5887:10 10 -18:0:0 -18:512:0
d8a81a00 should have been scheduled for uframe 5775 (80 uframes after
d8a81c00). Instead it was scheduled for uframe 5887, about 11 ms
later. Probably the -EXDEV errors in the C line are because the device
stopped sending data.
There are other examples in the log like this one. To fix the problem
you could put more packets in each URB, or use more URBs, or eliminate
the large interrupt latency.
> My questions are:
> 1. in usb driver,
> ehci-sched.c --> itd_complete ->
>
> if (unlikely (t & ISO_ERRS)) {
> ......................
> } else if (likely ((t & EHCI_ISOC_ACTIVE) == 0)) {
> ........................
> } else {
> /* URB was too late */
> urb->error_count++;
> }
> EXDEV seems come from above comment " /*URB was too late */"
Actually, I expect it comes from the "t & ISO_ERRS" test.
> As far as I know,itd_complete is called "in irq handler" and
> "scan_work thread", and urb is already submitted in these 2 places.
>
> if my conclusion is correct, why we said "urb was too late"?
> Does it mean urb too late to send or too late to service?
The comment means "too late to service".
> 2. In my case, the urbs are always submitted with URB_ISO_ASAP.
URBs with ISO_ASAP are never too late to service. That's part of the
reason I suspect the device stopped sending data.
> Except itd_complete is there any place will let iso EXDEV happen?
Yes, depending on which version of the kernel you are using,
iso_stream_schedule can also have that effect.
However, the problem doesn't lie in the ehci-hcd driver. The problem
lies in the fact that you aren't submitting URBs fast enough to keep
the isochronous pipeline filled.
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
