Re: Help needed for EHCI problem: removing an active bulk-in QH

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

 



On Thu, Oct 22, 2015 at 05:14:41PM -0400, Alan Stern wrote:
> [Resend with Hans's correct email address this time...]
> 
> On Thu, 22 Oct 2015, Alan Stern wrote:
> 
> > Hans and everyone else:
> > 
> > This continues the discussion of a problem originally posted to the 
> > libusb-devel mailing list
> > (see <http://marc.info/?l=libusb-devel&m=144423444825269&w=2> if 
> > you're curious).
> > 
> > The EHCI controller in question is an AMD/ATI SB7x0/SB8x0/SB9x0, as 
> > found on the RX780/RX790 motherboard.  I haven't seen this problem 
> > occur with Intel hardware.
> > 
> > The problem arises when an active bulk-in QH is removed from the async
> > schedule.  The current qTD is cancelled, and it is the last qTD on the
> > QH's queue.  At the time the QH is removed from the async list, the
> > overlay region shows that only a fraction of the qTD has been completed
> > (maybe 4 KB transferred out of 16 KB total).
> > 
> > 10 ms later, four new qTDs are added to the QH and it gets added back
> > to the async schedule.  Although I don't know this for certain, I
> > believe the second of these qTDs is stored at the same address as the
> > one that was cancelled.  That's what naturally would happen if the
> > memory pool satisfies an allocation from the most recently freed area.
> > 
> > Anyway, a short time later, it sometimes happen that the controller
> > gets stuck.  The Active bit in the QH's overlay region is clear, and
> > the Current and Next qTD pointers both point to the second qTD in the
> > queue, which obviously is why the controller is not making any forward
> > progress.  The first qTD's Active bit is still set and its Bytes To
> > Transfer is still set to 16 KB.  The second qTD's Active bit is off and
> > its Bytes To Transfer is 0.  In spite of this, neither qTD's data
> > buffer has been overwritten.
> > 
> > Although it's hard to tell exactly what went wrong, my guess is that
> > the after the QH was removed from the async schedule, the controller
> > continued to process it until all 16 KB had been transferred.  (This
> > would have taken no more than 0.5 ms.)  Then at some point, the QH
> > overlay and the now-completed qTD were written back -- that would
> > explain why the second qTD in the queue shows up as not Active and with
> > no bytes remaining to transfer.
> > 
> > On the other hand, that qTD wasn't reused until 10 ms after the QH was
> > removed from the schedule, and it was completely reinitialized before
> > reuse.  The write-back must have occurred later than this; I have no
> > idea why.  I also don't know why the write-back of the QH's overlay
> > region didn't overwrite the Next qTD pointer.
> > 
> > 
> > This is clearly a complicated problem.  It's possible that we're simply
> > dealing with defective hardware, but I tend to doubt it.  It seems more
> > likely that the problem is caused by improperly removing the active QH
> > from the async schedule.  The driver does not follow the instructions
> > given in section 4.8.2 of the EHCI spec, which says that software
> > should not remove active QHs.
> > 
> > [In practice it's not feasible to wait for an active QH to become
> > inactive before removing it, for several reasons.  For one, the QH may
> > _never_ become inactive (if the endpoint NAKs indefinitely).  For
> > another, the procedure given in the spec (deactivate the qTDs on the
> > queue) is racy, since the controller can perform a new overlay or
> > writeback at any time.]
> > 

Alan, one question, what will happen if we never remove an active QH from
async list?

-- 

Best Regards,
Peter Chen
--
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