Sebastian Andrzej Siewior wrote: > Arvid Brodin wrote: >> These patches fixes one known and a couple of suspected bugs: > > Thanks for working on this. > >> 1) urb_dequeue() always aborted the active transfer on the urb's >> endpoint, even if the transfer in question belonged to a different >> urb. (known bug) >> >> 2) Since there is no known way to actually terminate a started >> transfer with the isp1760, we reinstate the use of the skip maps >> and use them as a filter for interrupts and done maps. > > Didn't you say once that the transfer is still active? With the use of the > skipmap we don't get interrupts with (qtd == NULL) but the slot might be > re-used right? If this is still the case what about leaving things as it > and assigning qtd = (void*)1 on dequeue. Once we get the interrupt for > qtd == 1 we would set it to NULL. So we won't re-use this slot too early. > The transfer *might* be active. There's no way to tell, as far as I can see. So even if we don't mask the interrupt using the skip map, we might not get an interrupt (in fact this seemed to be the usual case when I looked into this before). And if we don't get the interrupt, we never release the slot, which is of course bad in the long run. :) To avoid the problem of re-using the slot too early, I have done this (in patch #2 in this series): When unlinking: 1) Set skip bit When queueing new transfer at some later time: 2) Write new ptd 3) Read done_map, mask out the bit for this slot. (The done maps are now stored in struct isp1760_hcd to allow this, since they cannot be written back to the isp1760.) 4) Clear skip map bit. This should avoid errouneous interrupts for unlinked ptds, unless we can get "done interrupts" for ptds even after writing new data to the slot (not impossible I guess, if the hardware starts the transfer and we are then very quick to reuse the slot). I would like to have some kind of way to communicate with the hardware to make sure the hardware considers a ptd inactive, but I haven't found any. I.e. clear DW0_VALID_BIT and wait for DW3_ACTIVE_BIT to become unset or something like that. But the hardware seems to totally ignore changes to both the ACTIVE and the VALID bit after it has started processing the slot. :( > Sebastian -- Arvid Brodin Enea Services Stockholm AB -- 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
