- From: Jed Wing <jed_at_salk.edu>
- Date: Mon, 30 Apr 2007 18:32:40 -0700
I have an NI-PCIE-6259 card which I'm trying to get working, but I see
some strange behavior. I see that a few other people have encountered
this, but I don't see any responses to the problem. I'm using the
latest version in CVS, as the 0.7.73 version doesn't recognize the
NI-PCIE-6259 card, as the card's PCI id (717f) was not in any of the
released versions of comedi, as far as I can tell.
When I run comedi_test, I see the following:
----------------------------------------
I: Comedi version: 0.7.73
I: Comedilib version: unknown =)
I: driver name: ni_pcimio
I: device name: pcie-6259
I:
I: subdevice 0
I: testing info...
rev 1
I: subdevice type: 1 (analog input)
number of channels: 32
max data value: 65535
ranges:
all chans: [-10,10] [-5,5] [-2,2] [-1,1] [-0.5,0.5] [-0.2,0.2] [-0.1,0.1]
I: testing insn_read...
rev 1
comedi_do_insn returned 1, good
I: testing insn_read_0...
comedi_do_insn returned 0, good
I: testing insn_read_time...
rev 1
comedi_do_insn: 3
read time: 141 us
I: testing cmd_no_cmd...
not applicable
I: testing cmd_probe_src_mask...
rev 1
command source mask:
start: now|ext|int
scan_begin: timer|ext
convert: timer|ext
scan_end: count
stop: none|count
I: testing cmd_probe_fast_1chan...
command fast 1chan:
start: now 0
scan_begin: timer 800
convert: timer 800
scan_end: count 1
stop: count 2
I: testing cmd_read_fast_1chan...
I: testing cmd_write_fast_1chan...
not applicable
I: testing cmd_logic_bug...
rev 1
command_test returned 1, good
I: testing cmd_fifo_depth_check...
64, 1
128, 1
256, 1
512, 1
1024, 1
2048, 1
4096, 2
8192, 4
16384, 8
32768, 15
I: testing cmd_start_inttrig...
I: testing mmap...
0xb7f83000 ok
0xb7f84000 ok
0xb7f85000 ok
0xb7f86000 ok
0xb7f87000 ok
compare ok
0xb7f83000 segfaulted (ok)
0xb7f84000 segfaulted (ok)
0xb7f85000 segfaulted (ok)
0xb7f86000 segfaulted (ok)
0xb7f87000 segfaulted (ok)
I: testing read_select...
I: testing bufconfig...
buffer size 65536
max buffer size 65536
setting buffer size to 4096
buffer size set to 4096
buffer size now at 4096
setting buffer size past limit, 69632
got EPERM, good
setting buffer size to max, 65536
buffer size now at 65536
I:
I: subdevice 1
I: testing info...
rev 1
I: subdevice type: 2 (analog output)
number of channels: 4
max data value: 65535
ranges:
all chans: [-10,10] [-5,5] [-1,1]
I: testing insn_read...
rev 1
comedi_do_insn returned 1, good
I: testing insn_read_0...
comedi_do_insn returned 0, good
I: testing insn_read_time...
rev 1
comedi_do_insn: 3
read time: 0 us
I: testing cmd_no_cmd...
not applicable
I: testing cmd_probe_src_mask...
rev 1
command source mask:
start: int
scan_begin: timer
convert: now
scan_end: count
stop: none|count
I: testing cmd_probe_fast_1chan...
command fast 1chan:
start: int 0
scan_begin: timer 0
convert: now 0
scan_end: count 1
stop: count 2
I: testing cmd_read_fast_1chan...
not applicable
I: testing cmd_write_fast_1chan...
----------------------------------------
At this point, it hangs. Delving a little deeper, it seems that what
happens is that the async buffer into which comedi_write is depositing
bytes fills up. Several times, we get interrupts indicating that DMA
has successfully disposed of the bytes, but the interrupts stop coming,
and comedi_write then blocks indefinitely. I've gone through several
iterations of adding debug printks to the driver, and it seems that the
interrupts stop coming after DMA has handled about 16 kb worth of data,
meaning that the writes start failing after approx. 80 kb of data is
written to the comedi device.
When the comedi drivers are initialized and configured, the following
information is sent to syslog:
----------------------------------------
comedi: version 0.7.73 - David Schleef <>
rt_pend_tq: RT bottom half scheduler initialized OK
Available NI device IDs: 0x717f
comedi0: ni_pcimio: pcie-6259<6>ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 16 (level, low) -> IRQ 16
MITE:0xdcefe000 mapped to f88ae000 DAQ:0xdceff000 mapped to f8960000
mite: version = 1, type = 4, mite mode = 1, interface mode = 3
mite: num channels = 8, write post fifo depth = 1, wins = 0, iowins = 2
( irq = 16 )
----------------------------------------
I'm running using an RTAI-patched kernel running the Debian etch
distribution. The system details are as follows:
# uname -a:
Linux laser2 2.6.20.3rtai #1 SMP PREEMPT Wed Apr 11 07:04:29 PDT 2007 i686 GNU/Linux
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 CPU 6300 _at_ 1.86GHz
stepping : 6
cpu MHz : 1862.035
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 3726.50
clflush size : 64
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 CPU 6300 _at_ 1.86GHz
stepping : 6
cpu MHz : 1862.035
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 3724.09
clflush size : 64
# gcc --version
gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Does anyone know what might be wrong here? Let me know if there's
anything I can do to help track it down. If it would be useful, I can
send logs of when the interrupts occurred, what the "A" and "B" status
flags were, when the DMA transfers were initiated, and details on how
much data was in the async buffer.
Thanks in advance!
--
- Jed Wing
Received on 2007-05-01Z00:32:40