On Fri, May 04, 2001, Martin Diehl [EMAIL PROTECTED] wrote:
On Thu, 3 May 2001, Johannes Erdfelt wrote:
On Thu, May 03, 2001, Georg Acher [EMAIL PROTECTED] wrote:
This is exactly the cause, why usb-uhci is always using a bottom QH (bqh)
as the last element in the vertical TD list
On Fri, May 04, 2001, Johannes Erdfelt [EMAIL PROTECTED] wrote:
On Fri, May 04, 2001, Martin Diehl [EMAIL PROTECTED] wrote:
However, now uhci looses in performance compared to usb-uhci: With my
usual 2 queued bulk transfers, len=2112, both to same endpoint,
usb-uhci provides 1MB/sec av.
On Thu, May 03, 2001 at 05:37:09PM +0200, Martin Diehl wrote:
...
spin_lock_irqsave, so status might be outdated (i.e. all its TD's
already inactive at this point). So we end up connecting the new QH's TD
to a lltd-link, which is now out-of-reach for the HC?
just proved: exactly this
On Thu, May 03, 2001, Martin Diehl [EMAIL PROTECTED] wrote:
Anyway - chances are the observation that uhci_append_queued_urb() makes
significant contribution to the problem might be helpful. Probably the
eurb which was determined much earlier with status==EINPROGRESS might be
racy: all
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
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).
Does this patch fix it? I haven't had the chance to test it
On Wed, 2 May 2001, Johannes Erdfelt wrote:
I suggest you go and read the UHCI docs and understand how the schedule
is processed.
Ok, seems I should check that. My reading of UHCI-1.1 docs, p32 was, the
HC would never advance to the next QH on NAK (or other error)...
This fix will fail for
