linux-kernel - dma hardware underrun

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 22 Jul 2007 21:59:44 +0800
From:	"treul" <lgijnpuhx@...il.com>
To:	linux-kernel@...r.kernel.org
Subject:  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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/