dma hardware underrun

Hi all,


I'm currently experiencing a tough DMA underrun problem.

The system is like:

global bus
||
data-compressor ------||------//---- memory
IDE-PCI harddisk -----||
data-decompressor ----||
data-consumer --------||
||

1. harddisk has the compressed data, read to compressed buffer by DMA1;
2. data-decompressor gets data from compressed buffer by DMA2, and puts
decompressed data to decompressed buffers in ISR;
3. data-consumer eats the decompressed data at an uncompromisable speed;

The data-consumer encounters DMA underrun...

My debugging result shows the underrun goes away if I put 2 printf's in the
harddisk ISR. The printf is at milli-seconds whereas the duration of the
original ISR is at lower magnitude. In addition, I find a SATA-PCI harddisk
does not have the underrun problem. IDE-PCI device gets the trouble.

In addition, all interrupts are at the same priority and ISR's can not be
preempted by others.

So, do you have any idea about where the root cause can be hiding? Or what
do you think of adding printf's in ISR? (performance? incurring other
problems by disabling interrupt too long?)

Thanks!!


-treul

On Sun, 22 Jul 2007 22:14:24 +0800, treul <lgijnpuhx RemoveThis @gmail.com> wrote:

> I'm currently experiencing a tough DMA underrun problem.
>
> The system is like:
>
> global bus
> ||
> data-compressor ------||------//---- memory
> IDE-PCI harddisk -----||
> data-decompressor ----||
> data-consumer --------||
> ||
>
> 1. harddisk has the compressed data, read to compressed buffer by DMA1;
> 2. data-decompressor gets data from compressed buffer by DMA2, and puts
> decompressed data to decompressed buffers in ISR;
> 3. data-consumer eats the decompressed data at an uncompromisable speed;
>
> The data-consumer encounters DMA underrun...

Assuming this is an Intel-based system...

Have you tried turning IDE interrupt unmasking on/off with hdparm (the
-u switch)? It could be that the IDE device disables interrupts for too
long, or alternatively that something else is causing excessive latency
(maybe data-decompressor is doing programmed I/O in the ISR?).

That command masks/unmasks other interrupts during the IDE one, which
works on virtually all modern hardware but used to cause problems on
some back in the day.

You don't say what kernel you are using but SATA uses libata whereas IDE
has in the past used a different driver. That might explain why it
works with SATA. Perhaps the libata driver is just more efficient or
has a different pattern of interrupt masking/unmasking.

Also, how is data-decompressor's driver written? Is it copying and/or
decompressing a lot of data in the ISR? How long does that take, and
are other interrupts disabled during that time?

As for the printf's in the interrupt handler, probably you are just
preventing data-consumer from running as often as it normally would. It
is likely hiding the problem rather than fixing it.


--
-| Bob Hauck
-| "Reality has a well-known liberal bias." -- Stephen Colbert
-| http://www.haucks.org/