Linux Users

cancel
Showing results for 
Search instead for 
Did you mean: 

kernel-3.10.0-693.2.2.el7.x86_64 update centos 7.4

Solved!
Go to solution

 

Hello guys.

 

 

I'm update my Centos 7.3 to ---->> CentOS 7.4 and new kernel 3.10.

 

After update NI-VSA 17 fail to open everytime. 

 

Please anybody have the same issue?

 

 

 

0 Kudos
Message 1 of 9
(8,987 Views)
Solution
Accepted by vpinho13

you need to call updateNIdrivers, but nikal.c needs a small patch (add NULL to the arguments list of do_munmap) in order to compile.

0 Kudos
Message 2 of 9
(8,952 Views)

hello,

sorry, but I don't know how to do this.

Could you please, tell me details.

 

 

thanks in advance.

0 Kudos
Message 3 of 9
(8,937 Views)
Solution
Accepted by vpinho13

[elsys@localhost ~]$ cd /usr/local/bin
[elsys@localhost bin]$ sudo ./updateNIDrivers
[sudo] password for elsys:
Configuring NI-KAL for kernel version 3.10.0-693.2.2.el7.x86_64...
Building module nikal...
nikal:   CC [M]  /var/lib/nikal/3.10.0-693.2.2.el7.x86_64/nikal/nikal.o
nikal: /var/lib/nikal/3.10.0-693.2.2.el7.x86_64/nikal/nikal.c: In function ‘nNIKAL240_do_munmap’:
nikal: /var/lib/nikal/3.10.0-693.2.2.el7.x86_64/nikal/nikal.c:3723:4: error: too few arguments to function ‘do_munmap’
nikal:     return do_munmap(mm, addr, len);
nikal:     ^
nikal: In file included from /var/lib/nikal/3.10.0-693.2.2.el7.x86_64/nikal/nikal.c:61:0:
nikal: include/linux/mm.h:1931:12: note: declared here
nikal:  extern int do_munmap(struct mm_struct *, unsigned long, size_t,
nikal:             ^
nikal: make[2]: *** [/var/lib/nikal/3.10.0-693.2.2.el7.x86_64/nikal/nikal.o] Error 1
nikal: make[1]: *** [_module_/var/lib/nikal/3.10.0-693.2.2.el7.x86_64/nikal] Error 2
nikal: make: *** [nikal.ko] Error 2
nikal: ERROR:  failed to build nikal
nikal: ERROR:  NI-KAL update failed.
nikal: ERROR:  make of nikal kernel module failed, not installing kernel module.
nikal: ERROR:  updateNIDrivers should be called again after fixing the problem.
nikal: ERROR: Update of National Instruments drivers failed.
[elsys@localhost bin]$

0 Kudos
Message 4 of 9
(8,902 Views)

New Kernel kernel version 3.10.0-862.2.3.el7.x86_64.

 

 

fail updateNIDrivers.

 

nikal:   CC [M]  /var/lib/nikal/3.10.0-862.2.3.el7.x86_64/nikal/nikal.o
nikal: /var/lib/nikal/3.10.0-862.2.3.el7.x86_64/nikal/nikal.c:2043:10: error: ‘GENL_ID_GENERATE’ undeclared here (not in a function)
nikal:     .id = GENL_ID_GENERATE,
nikal:           ^
nikal: /var/lib/nikal/3.10.0-862.2.3.el7.x86_64/nikal/nikal.c: In function ‘nNIKAL100_initDriver’:
nikal: /var/lib/nikal/3.10.0-862.2.3.el7.x86_64/nikal/nikal.c:2083:4: error: implicit declaration of function ‘genl_register_family_with_ops’ [-Werror=implicit-function-declaration]
nikal:     if ((status = genl_register_family_with_ops(&nikal_netlink_family, nikal_netlink_ops, 1))) return status;
nikal:     ^
nikal: cc1: some warnings being treated as errors
nikal: make[2]: *** [/var/lib/nikal/3.10.0-862.2.3.el7.x86_64/nikal/nikal.o] Error 1
nikal: make[1]: *** [_module_/var/lib/nikal/3.10.0-862.2.3.el7.x86_64/nikal] Error 2
nikal: make: *** [nikal.ko] Error 2
nikal: ERROR:  failed to build nikal
nikal: ERROR:  NI-KAL update failed.
nikal: ERROR:  make of nikal kernel module failed, not installing kernel module.
nikal: ERROR:  updateNIDrivers should be called again after fixing the problem.
nikal: ERROR: Update of National Instruments drivers failed.
[elsys@unknown bin]$

0 Kudos
Message 5 of 9
(7,048 Views)

@vpinho13 wrote:

New Kernel kernel version 3.10.0-862.2.3.el7.x86_64.

3.10 is really ancient and unsupportedDo not use in production anymore.

Current stable is 4.16.8, LTS is 4.14.* (3.10 never was LTS)

  

fail updateNIDrivers.

 

nikal:   CC [M]  /var/lib/nikal/3.10.0-862.2.3.el7.x86_64/nikal/nikal.o
nikal: /var/lib/nikal/3.10.0-862.2.3.el7.x86_64/nikal/nikal.c:2043:10: error: ‘GENL_ID_GENERATE’ undeclared here (not in a function)
nikal:     .id = GENL_ID_GENERATE,

It is (actually was - long ago) in uapi/linux/genetlink.h. But it was never intended for general use, just a workaround for some special drivers, and looooong obsolete. Should have never been in uapi in the first place.


nikal:           ^
nikal: /var/lib/nikal/3.10.0-862.2.3.el7.x86_64/nikal/nikal.c: In function ‘nNIKAL100_initDriver’:
nikal: /var/lib/nikal/3.10.0-862.2.3.el7.x86_64/nikal/nikal.c:2083:4: error: implicit declaration of function ‘genl_register_family_with_ops’ [-Werror=implicit-function-declaration]
nikal:     if ((status = genl_register_family_with_ops(&nikal_netlink_family, nikal_netlink_ops, 1))) return status;

genl_register_family_with_ops() was dropped long ago. Drivers are supposed to statically initialize the struct.

 

Oh, BTW, using those inline functions makes the driver a derivative work, so GPL applies.

@okay, @User002: can we have the full source code now or shall we file criminal charges ?

 

Few weeks ago I made another contact attempt to resolve this ancient problem.

No answer. NI doesn't wanna talk to me. Obviously they're absolutely NOT interested in any solution.

Ergo: no Linux support whatsoever.

 

EDIT: I really wonder what they're doing w/ netlink in the first place.

It's NOT supposed for daq devices at all - we have IIO for that. It really seems they have no idea whatsoever how the Linux kernel works.

 

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 6 of 9
(7,040 Views)

centos 7.4 supported by National, I'm sure about that.

 

 

0 Kudos
Message 7 of 9
(7,022 Views)

One specific distro in one specific version, with one specific kernel version (or very small version range) in one specific configuration is far from being "linux support". (it'd somewhat about 1 permill of that).

 

When it comes to kernel drivers, supporting binary-only drivers is practically impossible.

Requires an extrem amount of work - magnitudes more than just rewriting everything from scratch and bringing it to mainline.

 

There're hundreds to thousands of factors that must match exactly in order to make a kernel module really fit to the rest of the kernel on binary level (the hard lifting is done by the compiler, lots of macros/inlines, ...). There is not, never has been any kind of binary compatibility between individual kernel versions and configurations. It's a monolithic kernel - "modules" here just means that some pieces of the code can be put into extra files that are loaded after bootup - they're not separate programs (like on other OS'es), not even libraries. This is a fundamental design decision which won't change in the forseeable future.

 

The proper solution is to just write IIO drivers. Here, the framework already does all the heaving lifting (buffer management, signalling, sample conversion, ...) in a generic way. We just need the little pieces that speak to the actual hardware. Usually few hundred LOC per model - with proper specs about 2..4 weeks of work. For the LV side, they could just add a generic driver that speaks to IIO into DAQmx, and then all IIO devices work w/ LV.

 

To put it into numbers: maybe 10k$ per model. Assuming they had 100 different models to support, we end up w/ 1Mio. Peanuts for a billion-dollar-company. 

 

The fact that they just don't invest these few bucks - over many years now - and instead burn resources with their kernel blob crap, clearly shows they don't have the slightest interest in any decent Linux support. They don't wanna have any market share in the Linux world - otherwise they already would have invested the few bucks, years ago.

 

--mtx

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 8 of 9
(7,010 Views)

Addendum: just in case someone asks where I get these numbers from.

Well, I am one of those folks who regularily write kernel drivers.

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 9 of 9
(7,009 Views)