07-06-2011 09:44 AM
OS: OpenSuSE 11.4
Kernel: Linux 2.6.37.1-1.2-default #1 SMP 2011-02-21 10:34:10 +0100 i686 i686 i386 GNU/Linux
Installed NIDAQmx from DAQmx802f0.iso
Installation was successful with no errors, ran updateNIdrivers upon completion and no errors. Rebooted system.
NI Boards Installed: PXI-6534, PXI-6221, PXI-6052E
Results of lspci show 3 NI boards:
03:0d.0 Unassigned class [ff00]: National Instruments Device 70b5
03:0e.0 Unassigned class [ff00]: National Instruments PXI-6052E
03:0f.0 Unassigned class [ff00]: National Instruments Device 1490 (rev 01)
Ok, so here is where the problem comes in. When I run nilsdev or try to execute a command to read from any of the cards, I get the following errors:
Message from syslogd@dtags at Jul 6 14:02:27 ...
kernel:[ 7038.537247] Oops: 0000 [#10] SMP
Message from syslogd@dtags at Jul 6 14:02:27 ...
kernel:[ 7038.537255] last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:02:0c.0/0000:03:0f.0/class
Message from syslogd@dtags at Jul 6 14:02:27 ...
kernel:[ 7038.537395] Process ni (pid: 3835, ti=f4c40000 task=f597c1f0 task.ti=f4c40000)
Message from syslogd@dtags at Jul 6 14:02:27 ...
kernel:[ 7038.537403] Stack:
Message from syslogd@dtags at Jul 6 14:02:27 ...
kernel:[ 7038.537448] Call Trace:
Message from syslogd@dtags at Jul 6 14:02:27 ...
kernel:[ 7038.537531] Code: 10 00 39 d9 72 0e 01 c0 83 ea 01 75 ef 31 c0 5b c3 8d 76 00 b8 01 00 00 00 5b c3 89 f6 8d bc 27 00 00 00 00 53 83 ec 0c 8b 5a 74 <8b> 03 8b 00 8b 00 8b 50 24 b8 ea ff ff ff 85 d2 75 07 83 c4 0c
Message from syslogd@dtags at Jul 6 14:02:27 ...
kernel:[ 7038.537580] EIP: [<f806a0e7>] nNIKAL100_ioctl+0x7/0x40 [nikal] SS:ESP 0068:f4c41f68
Message from syslogd@dtags at Jul 6 14:02:27 ...
kernel:[ 7038.537596] CR2: 000000003cbe0d06
results of lsmod | grep ni:
nissrk 2037379 0
nisftk 287513 0
nixsrk 1682087 0
nitiork 996103 2 nissrk,nixsrk
nispdk 59427 0
niesrk 1014092 1 nispdk
niwfrk 852488 0
nidsark 1439468 0
nistcrk 182993 4 nissrk,niesrk,niwfrk,nidsark
nistc2k 225821 5 nissrk,niesrk,niwfrk,nidsark,nistcrk
nisdigk 435038 2 nixsrk,niesrk
niswdk 960723 0
niscdk 1095106 2 nispdk,niswdk
nicdrk 365202 9 nissrk,nixsrk,nitiork,niesrk,niwfrk,nistcrk,nisdigk,niswdk,niscdk
nimxpk 33664 12 nissrk,nixsrk,nitiork,niesrk,niwfrk,nidsark,nistcrk,nistc2k,nisdigk,niswdk,niscdk,nicdrk
nimru2k 427929 12 nissrk,nisftk,nixsrk,nitiork,nispdk,niesrk,niwfrk,nidsark,nistcrk,nisdigk,niswdk,niscdk
nipxirmk 115098 0
nidimk 320663 5 nitiork,niswdk,niscdk,nimru2k,nipxirmk
nimsdrk 231290 8 nissrk,nisftk,nixsrk,nitiork,niesrk,niwfrk,nidsark,nistcrk
nidmxfk 373992 11 nissrk,nisftk,nixsrk,nitiork,niesrk,niwfrk,nistcrk,nisdigk,niscdk,nicdrk,nimsdrk
nimxdfk 477960 16 nissrk,nisftk,nixsrk,nitiork,nispdk,niesrk,niwfrk,nidsark,nistcrk,nisdigk,niswdk,niscdk,nicdrk,nimru2k,nimsdrk,nidmxfk
nimstsk 78221 14 nissrk,nisftk,nixsrk,nitiork,niesrk,niwfrk,nidsark,nistcrk,nisdigk,niswdk,niscdk,nicdrk,nimsdrk,nidmxfk
nimdbgk 360264 19 nissrk,nisftk,nixsrk,nitiork,nispdk,niesrk,niwfrk,nidsark,nistcrk,nistc2k,nisdigk,niswdk,niscdk,nicdrk,nimru2k,nimsdrk,nidmxfk,nimxdfk,nimstsk
niorbk 95711 21 nissrk,nisftk,nixsrk,nitiork,nispdk,niesrk,niwfrk,nidsark,nistcrk,nisdigk,niswdk,niscdk,nicdrk,nimru2k,nipxirmk,nidimk,nimsdrk,nidmxfk,nimxdfk,nimstsk,nimdbgk
nipalk 1225232 25 nissrk,nisftk,nixsrk,nitiork,nispdk,niesrk,niwfrk,nidsark,nistcrk,nistc2k,nisdigk,niswdk,niscdk,nicdrk,nimxpk,nimru2k,nipxirmk,nidimk,nimsdrk,nidmxfk,nimxdfk,nimstsk,nimdbgk,niorbk
nikal 61078 1 nipalk
I've attached the report from the niSystemReport command...let me know if any additional info is needed.
Any suggestions to get this working???
Thanks!
Ed
07-06-2011 10:50 AM
Should have looked a little further on the site. I found the answer in the following message:
I apologize for the situation guys. We know that Linux support is painful for our customers. Linux moves pretty fast, and we only have limited resources dedicated for Linux internally, and we have other obligations and priorities. It's hard to keep up with Linux kernel changes. And yes, we know that there are better ways to support Linux with open source drivers and such, but that also comes with other set of problems. Sigh.
Anyway, I got KAL on Open SUSE 11.4 working. We're going to merge the changes to the main KAL source.
In the meantime, here's the diff that you can try out:
@@ -241,6 +241,9 @@
static int nNIKAL100_open(nLinux_inode *the_inode, nLinux_fileHandle *filePtr);
static int nNIKAL100_release(nLinux_inode *the_inode, nLinux_fileHandle *filePtr);
static int nNIKAL100_ioctl(nLinux_inode *the_inode, nLinux_fileHandle *filePtr, unsigned int command, unsigned long param);
+#ifdef HAVE_UNLOCKED_IOCTL
+static long nNIKAL100_unlockedIoctl(nLinux_fileHandle *filePtr, unsigned int command, unsigned long param);
+#endif
#ifdef HAVE_COMPAT_IOCTL
static long nNIKAL100_compatIoctl(nLinux_fileHandle *filePtr, unsigned int command, unsigned long param);
#endif
@@ -512,7 +515,11 @@
{
.open = nNIKAL100_open,
.release = nNIKAL100_release,
+#ifdef HAVE_UNLOCKED_IOCTL
+ .unlocked_ioctl = nNIKAL100_unlockedIoctl,
+#else
.ioctl = nNIKAL100_ioctl,
+#endif
#ifdef HAVE_COMPAT_IOCTL
.compat_ioctl = nNIKAL100_compatIoctl,
#endif
@@ -1798,6 +1805,13 @@
return status;
}
+#ifdef HAVE_UNLOCKED_IOCTL
+static long nNIKAL100_unlockedIoctl(nLinux_fileHandle *filePtr, unsigned int command,
+ unsigned long param)
+{
+ return (long)nNIKAL100_ioctl(NULL, filePtr, command, param);
+}
+#endif
#ifdef HAVE_COMPAT_IOCTL
static long nNIKAL100_compatIoctl(nLinux_fileHandle *filePtr, unsigned int command,
unsigned long param)
I've tested those changes, it seems to work.
I still don't know when the next official KAL release containing those changes will be released. We still need to discuss it internally to figure it out.
at least with this, you guys can make progress in parallel.
Post to this forum if you have prob. I'll try to answer.
Unfortunately, I can't attach files in here, otherwise, I'd have sent you guys the new kal file directly. Oh well.
Sorry again for the painful support here.
07-25-2018 10:55 AM
Linux moves pretty fast, and we only have limited resources dedicated for Linux internally, and we have other obligations and priorities.
The core problem is that NI refuses to collaborate with the community. This makes the whole show extremely unstable, unreliable and expensive. Free drivers are the only practically usable solution.
It's hard to keep up with Linux kernel changes.
That wouldn't be a problem with free drivers. The community would take care of that.
And yes, we know that there are better ways to support Linux with open source drivers and such, but that also comes with other set of problems.
Which problems, exactly ? Developing a new IIO driver afresh would take about 4..8 weeks per device for a single kernel hacker. Very cheap compared with the extreme costs of maintaining proprietary drivers, that don't work reliably anyways.
Anyway, I got KAL on Open SUSE 11.4 working. We're going to merge the changes to the main KAL source.
The whole idea of an "kernel abstraction layer" is ridiculous to begin with.