On Mon, 2009-11-23 at 12:09 -0500, Devin Heitmueller wrote:
> On Mon, Nov 23, 2009 at 7:12 AM, Andy Walls <awa...@radix.net> wrote:
> > 5. If you don't give an MDL back to the firmware, it never uses it
> > again. That's why you see the sweep-up log messages. As soon as an MDL
> > is skipped *on the order of the depth* of q_busy times, when looking for
> > the currently DMA_DONE'd MDL, that skipped MDL must have been dropped.
> > It is picked up and put back into rotation then.
>
> Perhaps I am misinterpreting the definition of "sweep-up" in this
> context. Don't the buffers get forcefully returned to the pool at
> that point?
You've got it right.
> If so, why would I see the same error over and over long
> after the CPU utilization has dropped back to a reasonable level.
>
> I feel like I must be missing something here.
>
> 1. CPU load goes up (ok)
> 2. Packets start to get dropped (expected)
> 3. CPU load goes back down (ok)
> 4. Packets continue to get dropped and never recycled, even after
> minutes of virtually no CPU load?
>
> I can totally appreciate the notion that the video would look choppy
> when the system is otherwise under high load, but my expectation would
> be that once the load drops back to 0, the video should look fine
> (perhaps with some small window of time where it is still recovering).
OK the messages are coming from the sweep up implementation, let's
assume it's not working right (which is reasonable to me).
The sweep up algorithm relies on an assumption.
Assumption: The firmware uses MDL on a FIFO basis based on the order in
which we submitted the MDLs to the firmware. Thus, the order of MDLs in
the q_busy linked list should match how the firmware returns them.
Given that the decision to perform sweep up is based on the absolute
current depth of q_busy (was the buffer skipped q_busy.depth - 1 times
or more?), it turns out that
a. For large numbers of MDLs on q_busy, the assumption needs to only be
approximately true.
b. For very small numbers of MDLs on q_busy (i.e. 2), the assumption
needs to be strictly true or errant sweep-ups happen.
So I suspect for the case of the CX23418 firmware only having 1 MDL and
use giving it another MDL, the CX23418 might use the one we just gave it
first - violating the assumption amd causing errant sweep ups.
The fix is simple: don't sweep up a skipped buffer that meets the
current
skipped > = (q_busy.depth -1)
criteria in the case of
q_full.depth > q_free.depth + qbusy.depth
Which says if we've got a lot of MDLs tied up waiting for the
application to read them, don't both sweeping up potentially lost
buffers until the q_busy.depth increases. Since "lost" MDLs stay on
q_busy and are counted in q_busy.depth, this will always end up
returning MDLs to the firmware as the application reads data and returns
MDLs.
Of course that's all speculation about the problem. If you could
reproduce the condition and then
# echo 271 > /sys/modules/cx18/parameters/debug
to record the sequence of CX18_DE_SET_MDLs and DMA_DONE sequence numbers
for the YUIV stream, it might provide conifrmation of what is going on.
271 is high volume messages for info, warning, mailbox, and dma debug
messages. It will write a lot to your logs.
Regards,
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
