On Tue, 3 Nov 2015, Peter Chen wrote: > On Mon, Nov 02, 2015 at 11:24:54AM -0500, Alan Stern wrote: > > On Mon, 2 Nov 2015, Peter Chen wrote: > > > > > Hi Alan, > > > > > > After a discussion with IC engineer, a brief idea like below: > > > > > > - Delete the QH from the asynclist directly, Issue the first IAA > > > routine, this is we do now. > > > - During the first IAA interrupt, judge if asynclistaddr is next address of > > > the QH we want to remove, if it does not, issue the second IAA > > > routine, else, we consider the controller will not process the removed > > > QH any more, so it is safe to remove. > > > - If the controller still handles the QH previous than the one we want to > > > remove , issue IAA again. > > > > I don't understand this completely. It sounds like you're saying: > > > > Find qh2 such that qh2->qh_next == &qh. > > > > Keep doing IAA interrupts until (asynclistaddr != qh2->qh_dma && > > asynclistaddr != qh->qh_dma). > > > > Is that what you mean? It doesn't sound right. Consider the case > > where the async list contains only two QHs: qh2 and qh. Then > > asynclistaddr will always point to one or the other. > > > > What about this instead? > > > > Keep doing IAA interrupts until (asynclistaddr != qh->qh_dma). > > > > Then do one more IAA interrupt. > > > > That's may not enough, it does not consider the QH which we want to > remove is doing transfer now. Whoops, you're right. I forgot that asynclistaddr is the address of the next QH to execute, not the address of the currently executing QH. > We need to know clearly what things the IAA can make sure for us, if > these things can prove the controller thinks the QH has removed. I'm convinced that for these AMD/ATI controllers, IAA tells us practically nothing. If it worked properly then this bug would not have occurred. 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
