Re: [PATCH 2/5] usb/isp1760: Remove false error printout

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

 



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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux