Sebastian Andrzej Siewior wrote: > * Arvid Brodin | 2011-04-27 21:43:10 [+0200]: > >> Sebastian Andrzej Siewior wrote: >>> If this is normal please add a comment where this happens. I tried to >>> remove the URB from the hardware so it does complete after removal. >> As far as I can see, what happens is that sometimes when unlinking >> (dequeueing) an urb with an active ptd, the ptd finishes while >> urb_dequeue() is executing within its spinlock, but before the ptd is >> zeroed out. This sets the interrupt flag for the ptd, and when the >> interrupt is later executed, priv->xxxints[x].qh for the ptd has been >> set to NULL by urb_dequeue(). It happens rather frequently when running >> the unlink tests in the usbtest suite. > > I see. Okay so the interrupts occurs while we are holding the spinlock. > So it is a tiny race. Could it help if were checking the skip_map? Possibly (it depends on the inner workings of the hardware, which are not described in the documentation). As far as I can see there really is no safe way to unlink an active transfer. I have even seen once how a ptd slot has been unlinked and then reused again by the driver before the completion interrupt for the unlinked ptd occured - with bad consequences of course. (This was with patch 5 applied - I have since started using the skip map again, as well as reading and storing the done_map with the ptd slot in question masked out just before starting a new transfer). The question is whether setting the skip bit for the transfer actually inhibits the setting of the done bit for the slot even if the transfer is already underway. I have also tried reading the ptd that is to be unlinked from the hardware, masking either the VALID (or ACTIVE) bit and writing it back, and spin reading the ptd and waiting for ACTIVE (or VALID) to become unset, but this only works if the ptd finishes correctly (i.e. the isp1761 doesn't care about changes to the ACTIVE or VALID bits once the transfer has started). I will get back to you with an updated patch series, both regarding WARN()/ BUG() and with skip map usage, but it'll have to wait two weeks until I'm back from vacation. :) Thanks for your comments so far! -- 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