Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

6133 linux driver: dma address always increasing and logfile gets huge

Using driver nirlpk.ko, we are finding that the kernel is writing 100 of thousands of bytes per minute to /var/log/message.  For example, during a one second data collection period,  one channel, there might be 35 "page downs" of DMA transfer messages ~50 * 35 lines.   This is a diskless system and very quickly the ram disk fills up and no more loging occurs.  Other problems start occuring when the ramdisk is filled.
 
Here is a stop and start of the data acquisitiion program:  Note that about 3 minutes of inactivity occur when we stop the program.
Aug  1 20:42:20 (none) kernel: nirlpk: nNIRLP_release
Aug  1 20:42:20 (none) kernel: nirlpk: Exit clear DMA
Aug  1 20:42:20 (none) kernel: nirlpk: free nNIRLP_tDriverContext (ffff8100bcea9440)
Aug  1 20:42:20 (none) kernel: nirlpk: exit release
Aug  1 20:45:04 (none) kernel: nirlpk: nNIRLP_open(inode (ffff8100bd47f160), file (ffff81005fc78e80))
Aug  1 20:45:04 (none) kernel: nirlpk: minor 0
Aug  1 20:45:04 (none) kernel: nirlpk: Allocated nNIRLP_tDriverContext (ffff8100bcea9840)
Aug  1 20:45:04 (none) kernel: nirlpk: set device 0 (0xffff8100bc5d3640)
Aug  1 20:45:04 (none) kernel: nirlpk: mmap: vma->vm_start = 0x2aaaabc28000
Aug  1 20:45:04 (none) kernel: nirlpk: mmap: vma->vm_end   = 0x2aaaabc29000
Aug  1 20:45:04 (none) kernel: nirlpk: mmap: vma->vm_pgoff = 0xfc7ff
Aug  1 20:45:04 (none) kernel: nirlpk: mmap: vma->vm_start = 0x2aaaabc29000
Aug  1 20:45:04 (none) kernel: nirlpk: mmap: vma->vm_end   = 0x2aaaabc2a000
Aug  1 20:45:04 (none) kernel: nirlpk: mmap: vma->vm_pgoff = 0xfc7fc
 
Note the address  0x2aaaabc28000 it is the first DMA address used for I/O after the program starts up.
The DMA address constantly increases

vma->vm_start = 0x2aaab0a06000
vma->vm_end = 0x2aaab0a16000

  A search thru the entire log shows that address is only re-used if we start the program and restart it.  If we do not stop the program we find the system (3gb diskless dual opteron) eventually locks up and needs to be physically reset.
 
A grep of our executable code & source does not show any of the above messages.  We assume the kernel must be loging those messages.  Any calls to release/acquire those dma buffers seem to underneath our code.  ie: at the driver level.
 
0 Kudos
Message 1 of 2
(2,590 Views)
Hi jstateson,

It sounds like you are trying to use the Register Level Programming for your 6133 device, if so please post your question here:
Driver Development Kit (DDK) Forums

Regards,
0 Kudos
Message 2 of 2
(2,568 Views)