On Thu, May 03, 2001, Martin Diehl <[EMAIL PROTECTED]> wrote:
> turns out much interrupt work (like ping -f localhost) was a pretty
> reliable trigger for the problem I've seen (uhci failes do IOC after
> some queued bulk processing).
The real problem is that transfers get stalled because of a race
condition with the controller.
> Hence all kinds of races and interrupt pileup was what I was looking for.
> One candidate is the HC which updates various fields in the TD and QH's
> during scheduling. Especially qh->element is changed whenever a TD from
> this QH is transfered. Having pci-consistent mappings does not protect us
> from situtations where the HC changes things concurrently. Ok, "don't
> touch active TD's" is a rule to follow but what could protect us when we
> assume some state of the system would be not have changed?
> I mean all kinds of read-modify-write logic.
It's alright to touch active TD's and qh->element, as long as you adhere
to the rules the UHCI spec specifies.
> Well, admittedly, I don't have complete understood how the HCD works in
> this detail. So what I've tried was somewhat a blind man's approach.
> However, tentatively not using uhci_append_queued_urb() is a big success
> for me - in combination with depth-first linking!.
>
> The problem disappeared, nothing seems to be broken, queued bulk with uhci
> is now working for me. I've just transfered several GB in a row, all in
> 2112 byte queued transfers. Rock solid - withstands even floodpings from
> localhost and remote (which saturates eth0 on this box - "too much work in
> interrupt"). And oh, btw: for an idle testbox the sustained throughput
> averaged over 1 hour was >1.1MB/sec - i.e. same as usb-ohci and about 10%
> gain over usb-uhci!
>
> Ok, I'm not really sure, what the reason was and if I would have broken
> something else - but I have no such indication so far. So I'd like to ask
> everyone with problem using queued bulk on uhci to test the patch and
> report, how it behaves.
> Besides few cosmetic changes (/proc inconsistencies removed, GFP_DMA not
> needed) it doesn't touch anything except the queued-bulk submit-path.
>
> patch vs. 2.4.4 below. should be ok for -ac too.
>
> Comments? Ideas?
This patch (aside from the pci_pool and proc stuff) is very dangerous
and won't work.
I cut out the unrelated stuff.
> --- linux-2.4.4/drivers/usb.orig/uhci.c Wed May 2 19:41:41 2001
> +++ linux-2.4.4/drivers/usb/uhci.c Wed May 2 19:53:49 2001
> @@ -1275,13 +1279,22 @@
> urbp->qh = qh;
> qh->urbp = urbp;
>
> - /* Always assume breadth first */
> - uhci_insert_tds_in_qh(qh, urb, 1);
> + /* queued bulk: depth first - otherwise: assume breadth first */
> +
> + if (urb->transfer_flags & USB_QUEUE_BULK)
> + uhci_insert_tds_in_qh(qh, urb, 0);
> + else
> + uhci_insert_tds_in_qh(qh, urb, 1);
> +
> +#if 0
> + /* doesn't work - but normal insert works for queued bulk too! */
>
> if (urb->transfer_flags & USB_QUEUE_BULK && eurb)
> uhci_append_queued_urb(uhci, eurb, urb);
> else
> - uhci_insert_qh(uhci, uhci->skel_bulk_qh, qh);
> +#endif
> +
> + uhci_insert_qh(uhci, uhci->skel_bulk_qh, qh);
>
> uhci_inc_fsbr(uhci, urb);
I suggest you go and read the UHCI docs and understand how the schedule
is processed.
This fix will fail for any device which NAK's a single packet. It will
then continue onto the next "queued" urb and start processing that
before the first one is finished. This is guaranteed to corrupt the
data being sent to the device.
It may be that your device is quick enough to not need to NAK any
packets, but your device would be the exception rather than the rule.
JE
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
