Re: comedi_test hangs with NI-PCIE-6259

Just to give you a kind of moral support...
I had your same problem, I tried the CVS update and
it was fixed.

Bye
Donatello Materassi

Jed Wing wrote:
> 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
>
> _______________________________________________
> comedi mailing list
> comedi_at_comedi.org
> https://cvs.comedi.org/cgi-bin/mailman/listinfo/comedi
>
>   

Received on 2007-05-11Z13:51:35