On Sun, 24 Nov 2013, yoma sophian wrote:
> >> My questions are:
> >> 1. in usb driver,
> >> ehci-sched.c --> itd_complete ->
> >>
> >> if (unlikely (t & ISO_ERRS)) {
> >> ...................... (case A)
> >> } else if (likely ((t & EHCI_ISOC_ACTIVE) == 0)) {
> >> ........................ (case b)
> >> } else {
> >> /* URB was too late */ (case c)
> >> urb->error_count++;
> >> }
> >> EXDEV seems come from above comment " /*URB was too late */"
> >> >
>
> >> >> 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".
> >>
> >> Does that mean
> >> 1. iso complete irq happen but
> >> 2. scan_isoc is too late to be called, such as delaying 30 ms, etc.
> >>
> >> if so, the EHCI_ISOC_ACTIVE will be 0 and should not run into this case.
> >
> > No, it means the URB was submitted too late for the hardware to carry
> > out the transfers at their scheduled times.
>
> Could I said that case mean after the urb is actually _was_ scheduled,
> the hardware doesn't service it until timeout?
Yes, that's another way to describe the same thing.
> > Here's the first place in your log where a problem occurs:
> >
> > d8a80400 78915228 C Zi:1:003:2 0:8:111:0 10 0:0:100 0:512:100
> > d8a80400 78923303 S Zi:1:003:2 -115:8:0 10 -18:0:512 -18:512:512
> > d8a80800 78925390 C Zi:1:003:2 0:8:191:0 10 0:0:100 0:512:100
> > d8a80800 78927016 S Zi:1:003:2 -115:8:0 10 -18:0:512 -18:512:512
> > d8a80400 78941545 C Zi:1:003:2 0:8:319:10 10 -18:0:0 -18:512:0
> >
> > In the first two lines, URB d8a80400 completes at 78.915 but doesn't
> > get resubmitted until 78.923, which is 8 ms later. In the meantime,
> > URB d8a80800 was running, and it completes at 78.925.
> >
> > Because there is only 2 ms remaining in the pipeline when d8a80400 is
> > resubmitted, the URB_ISO_ASAP flag causes it to be delayed. Normally
>
> I am not quite understand what does "URB_ISO_ASAP flag causes it to be
> delayed" mean.
In your log, the URBs are normally scheduled at intervals of 80 uframes
(which is the same as 10 ms). On the first line above, we see that URB
d8a80400 was scheduled to start in uframe 111. On the third line, we
see that URB d8a80800 was scheduled to start in uframe 191, which is 80
uframes later. But on the fifth line, we see that when d8a80400 was
resubmitted, it was scheduled to start in uframe 319, not uframe 271 =
191 + 80. In other words, it was scheduled 319 - 271 = 48 uframes too
late.
It was scheduled 48 uframes too late because the URB_ISO_ASAP flag was
set. If that flag wasn't set, the URB would have been scheduled for
uframe 271.
> Does that mean the 2 ms remaining is caused by "URB_ISO_ASAP"?
No. It was caused by something else.
> > it would have been scheduled to start in uframe 271, but instead it was
> > scheduled to start in uframe 319, which was 6 ms later (I don't
> > understand why this delay was so large; it shouldn't be more than 2
> > ms).
> Would you please let my know why you think it shouldn't be more than 2ms?
See the definition of Isochronous Scheduling Threshold in Table 2-7 and
Section 4.7.2.1 of the EHCI spec. Its value cannot be much larger than
8 uframes, so after rounding up, the delay should not be larger than 2
ms.
> > If the device does not send data, the driver will go into case a.
>
> Why If the device does not send data, the driver will go into case a. ?
> in case a, that mean host get any error from the data he recive.
> If no data get from device, how host determine the error from?
It is a Timeout error if the host controller does not receive a DATA
packet within a few microseconds of sending an IN packet. The
controller sets the XactErr bit in the iTD Transaction Status byte.
See Table 3-3 in the EHCI spec.
> > The driver will go into case c if the hardware isn't working right.
> Howabout below race condition happen for accidentlly run into case C.
>
> Actually in there are bulk/iso interleaving happening on my system.
Why aren't the bulk transfers in your usbmon log?
> Suppose itds are submitted then ehci_work is triggered by bulk
> interrupt and ehci->isoc_count >0.
>
> The race condition may happen if hardware hasn't handled those itds, right?
I don't know what race condition you are talking about. Please explain
in more detail.
> BTW, why don't we just turn off period schedule in ehci_poll_PSS like below
> (since we turn it on directly in ehci_poll_PSS, right)
> if (want == 0) { /* Stopped */
> if (ehci->periodic_count > 0)
> ehci_set_command_bit(ehci, CMD_PSE);
>
> } else { /* Running */
> if (ehci->periodic_count == 0) {
>
> /* Turn off the schedule after a while */
> - ehci_enable_event(ehci, EHCI_HRTIMER_DISABLE_PERIODIC,
> true);
> + ehci_clear_command_bit(ehci, CMD_PSE);
>
> }
> }
If the periodic count has just dropped to 0, it's quite likely that the
periodic count will increase again in the near future. Therefore the
driver leaves the periodic schedule running for a little while. That's
better than stopping the schedule and starting it again a few
milliseconds later.
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
