Re: rtlinux dma get_buffer_contents number of bytes transferred

Hi Frank,

thank you for your answer.

# Is your board sharing its irq with anything else?  If so, the interrupt 
# handler won't get set to rt priority.

No, it's not shared. After a lot of tries the BIOS was convinced to
allocate one IRQ for each of the 3 boards that eventually need RT
priority. Everything else end up sharing the IRQ9! :)

lspci -v | grep IRQ | sed s/.\*IRQ/IRQ/

IRQ 9
IRQ 9
IRQ 11
IRQ 10
IRQ 9
IRQ 9
IRQ 9
IRQ 5

The last one is the ni board, and the test program is the only RT one
running during the tests. I've also verified if ni_pcimio entry in
/proc/interrupts changes from "RT SPVISD" to "REAL TIME" when the
program is running.

I even added this "printk"s:

printk("comedi switched interrupt %d to RT priority\n", dev->irq);
printk("comedi switched interrupt %d to non-RT priority\n", dev->irq);

respectively at the and of these functions in comedi/rt.c:

int comedi_switch_to_rt(comedi_device *dev)
void comedi_switch_to_non_rt(comedi_device *dev)

to be really sure they were succeeding.

An additional information is that I've tested with PCIDMA disabled and
enabled in comedi/drivers/ni_pcimio.c. It's not possible to use with DMA
because latencies are too big and the "long sleep" problem happens just
a few minutes after the program starts.

Other than that, I'm using comedi CVS updated when you made the
announcement at the beginning of this thread.

I've also performed a lot of "torture" tests (with disk and network IO)
and the callback latency always remained below 30us (20us in a idle
system). The 1ms glitches always happened after one hour running the
program with the system idle.

Thanks for your help! Regards,

Vitor.

Received on 2004-03-23Z10:42:59