On Sat, 31 May 2008 01:12:08 +0400 Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> On Fri, May 30, 2008 at 03:48:20PM -0500, Kim Phillips ([EMAIL PROTECTED]) > wrote: > > sorry, by ISR I meant interrupt status registers. but I can't tell > > where the suspected simultaneous accesses are. Evgeniy, can you point > > out the register accesses you're talking about? > > priv->status is accessed from tasklets, although readonly, but that rises > a red flag... Also callback invocation tasklet drops the lock around ok, I see what you are saying now; if a channel gets done during talitos_done processing, it'll trigger an interrupt and reset priv->status, leaving the tasklet in the dark as to which channel has done status, depending on how many channel dones it has already processed. I think the only solution here is to call flush_channel on each channel, regardless of the bits in the interrupt status - I'll send out a patch shortly. > callback, during that time cached status and priv itself (and tail like > in two simultaneous flushes) could change (or not?) I think you're talking about a different 'status' here; flush_channel's local 'status' doesn't resemble priv->status bits in any way, it looks at the descriptor header writeback bits for done status, on a per descriptor basis. It forwards this descriptor done vs. error status to the callback. priv itself won't change; it's uniquely associated to the device. Kim _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
