- From: Alessandro Toso <toso_at_aero.polimi.it>
- Date: Fri, 18 May 2007 09:24:28 +0200
Hi all, I've downloaded and installed the latest version of comedi from CVS (May, 11) and tested for some days on a NI-PCI-6251 (M-series). Looks like it is working properly but calibration gives the following error: init_setup() failed for pci-6251 I attach the eeprom dump for my ADC hoping it's useful. Bye
On May 11, 2007, at 4:51 PM, Donatello Materassi wrote: > > 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 >> >> > > > _______________________________________________ > comedi mailing list > comedi_at_comedi.org > https://cvs.comedi.org/cgi-bin/mailman/listinfo/comedi Alessandro Toso Dipartimento di Ingegneria Aerospaziale Politecnico di Milano Via La Masa, 34 20156 Milano (Italy) tel : +39 02 2399 8044 fax : +39 02 2399 8329 e-mail : toso_at_aero.polimi.it
Attachments
- application/octet-stream attachment: eeprom_dump_ni_pci_6251
- application/pkcs7-signature attachment: smime.p7s
Received on 2007-05-18Z06:24:28