I write NIC module driver and implement it base functions like ndo_open, ndo_stop, ndo_start_xmit...
Sometimes Linux Kernel API is changed in the recent versions. So macro like LINUX_VERSION_CODE helps adopt code of the module to recent Linux Kernel versions. In CentOS(RHEL) I meet that function name that changes MTU of NIC differs from vanilla Linux Kernel. In vanilla Linux Kernel v.3.10.0 it prototype is:
int (*ndo_change_mtu)(struct net_device *dev,
int new_mtu);
But in the CentOS 7.6.1810 3.10.0-957.el7.x86_64 it is:
RH_KABI_RENAME(int (*ndo_change_mtu),
int (*ndo_change_mtu_rh74))(struct net_device *dev,
int new_mtu);
So I must to use ndo_change_mtu_rh74 instead of ndo_change_mtu which works as I expected.
Is it possible to use some macro to adopt code of the module between different Linux Kernel versions without patching code to prevent compilation errors against CentOS(RHEL) Linux Kernels?
Thnk's to #omajid who provides to me topic about kni: Fix build on RHEL 8. The next macro has solved my problem:
#if (defined(RHEL_RELEASE_CODE) && \
(RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(7, 5)))
(RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(7, 5)) && \
(RHEL_RELEASE_CODE < RHEL_RELEASE_VERSION(8, 0)))
#define ndo_change_mtu ndo_change_mtu_rh74
#endif
Related
I'm trying to support zgetrf() in both Ubuntu 18.04 and CentOS 7 by using dlopen() against the .so and opening the function in each version, but the calling convention is different. In CentOS it works using LAPACKE_zgetrf() but in Ubuntu 18.04 they do not export as LAPACKE_zgetrf, the only option is zgetrf_:
# objdump -T /usr/lib/i386-linux-gnu/libopenblas.so.0 |grep zgetrf
[...]
000c3a60 g DF .text 00000191 Base zgetrf_
I can make an LAPACKE_zgetrf() call as follows, this works:
LAPACKE_zgetrf(order, m, n, a, ndim, (int32_t*)ip);
How do I convert it to call zgetrf_(...) ?
The LAPACKE_ functions will call the linked openblas.so.0 library, so no need to link to openblas.so.0 directly.
For ATLAS, you can call the clapack_ functions exported by liblapack_atlas.so.3 which are nearly the same format (same order, same type) except that the transform argument is different. For example, in zgetrs() in ATLAS might take the standard BLAS CblasTrans enum for the transform argument. However, in OpenBLAS (and MKL) this argument should be converted from ATLAS to OpenBLAS as follows:
openblas_trans = ((trans) == CblasConjTrans ? 'C' : ((trans) == CblasTrans ? 'T' : 'N'))
I am porting a Windows C++ program to Linux using Visual Studio 2019, WSL Ubuntu 18.04 LTS and GCC (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0.
Compiling x64.
In Windows it works fine, but not in Linux.
Stripped-down source files:
In header file:
class CDetail {
public:
CDetail();
~CDetail();
CDetail *Function(void);
char m_code;
char m_name[100];
};
In module A:
CDetail *pointer = My Detail;
pointer->Function();
In module B:
CDetail* CDetail::Function()
{
char *name = m_name;
.
.
}
When debugging:
(The values are actual values for an expanded class)
In module A the value of pointer is 0x5555557d72b9
The value of &(pointer->m_name) is 0x5555557d72b9
In module B the value of this is 0x5555557d72b9 (as expected)
The value of &m_name is 0x5555557d72b6 (off by 3 bytes)
This looks like an alignment problem. How can it be solved?
I am following https://docs.platformio.org/en/latest/boards/nordicnrf52/nrf52840_dk.html but I don't actually have a DK, I have an NRF52840 "Dongle". Does anybody know if it's possible for that to work directly with PlatformIO? It has a built in bootloader, but I don't think it emulates the right kind of programmer. I have nrfutil installed but that wants a package (.zip) and platformio is producing .elf/.hex ... not sure how to connect these tools.
platformio.ini configuration:
[env:nrf52840_dongle]
platform = nordicnrf52
board = nrf52840_dk
framework = zephyr
board_build.zephyr.variant = nrf52840dongle_nrf52840
extra_scripts = dfu_upload.py
upload_protocol = custom
add to project root dfu_upload.py script:
import sys
import os
from os.path import basename
Import("env")
platform = env.PioPlatform()
def dfu_upload(source, target, env):
firmware_path = str(source[0])
firmware_name = basename(firmware_path)
genpkg = "".join(["nrfutil pkg generate --hw-version 52 --sd-req=0x00 --application ", firmware_path, " --application-version 1 firmware.zip"])
dfupkg = "nrfutil dfu serial -pkg firmware.zip -p COM14 -b 115200"
print( genpkg )
os.system( genpkg )
os.system( dfupkg )
print("Uploading done.")
# Custom upload command and program name
env.Replace(PROGNAME="firmware", UPLOADCMD=dfu_upload)
add nrfutil location to your system configuration "path" variable
before upload firmware switch dongle to dfu mode (button reset)
setup dongle COM number in line: dfupkg = "nrfutil dfu serial -pkg firmware.zip -p COM14 -b 115200" in dfu_upload.py
lots of examples you can find here: Zephyr github
You can use nrfutil pkg generate to convert the hex files into a package:
https://infocenter.nordicsemi.com/topic/ug_nrfutil/UG/nrfutil/nrfutil_pkg.html
FYI, you might not get much benefit from using PlatformIO since you don't have a debugging interface. Depending on the framework you're using, there might be other options, like this documentation for Zephyr:
https://docs.zephyrproject.org/latest/boards/arm/nrf52840dongle_nrf52840/doc/index.html
With Matlab R2015b on 32-bit Windows 7, LOADLIBRARY was working fine:
library = 'C:\Windows\System32\visa32.dll';
headerFile = 'C:\Program Files\IVI Foundation\VISA\WinNT\include\visa_Matlab.h';
loadlibrary(library, headerFile, 'alias','visa32');
and I can use functions in 'visa32.dll', such as,
defaultRm = 0;
[err, defaultRm] = calllib('visa32', 'viOpenDefaultRM', defaultRm);
vi = 0;
InstrAddr = 'GPIB0::29::INSTR';
pInstrAddr = libpointer('int8Ptr', [int8( InstrAddr ) 0] );
[err, tempVar, vi] = calllib('visa32', 'viOpen', defaultRm, pInstrAddr, 0, 0, vi);
to open instrument's communication port...
But after I have upgraded to 64-bit Windows 7 and Matlab R2017b, LOADLIBRARY won't work any more, even I have use 62-bit versions of 'visa32.dll' and 'visa.h'. There are two problems:
(1) Firstly, Matlab complaints about not have the right compiler installed and can't even run LOADLIBRAY. Follow their online instruction to install the MinGW-w64 Compiler addon. This problem seems to have revolved.
(2) LOADLIBRAY seems to be able to run, but then it has the following error:
Failed to parse type '( fastcall )) viOpenDefaultRM ( ViPSession vi' original input '( fastcall )) viOpenDefaultRM ( ViPSession vi '
Found on line 217 of input from line 93 of file C:\Program Files (x86)\IVI Foundation\VISA\WinNT\Include\visa.h
Error parsing argument for function attribute function may be invalid.
...
I wonder if somebody could help please. Many thanks in advance!
The advantages of using VISA library in MATLAB for instrument control are: direct (i.e. faster) access to ports, be able to use GTL (go-to-local) and handles communication error better, etc. Use LOADLIBRARY to load the VISA library and CALLLIB to access the functions in the loaded library, e.g.
loadlibrary('visa32.dll','visa.h','alias','visa32');
[err, defaultRm] = calllib('visa32', 'viOpenDefaultRM', defaultRm);
However, limitations in LOADLIBRARY have caused a lot of trouble, and it works differently for different Windows architecture. Here is the solution that has been tested on 32- and 64-bit Windows:
1. C++ compiler in MATLAB:
a. This only affects 64-bit MATLAB;
b. A MATLAB add-on called ‘MinGW-w64 Compiler’ must be installed:
i. this is relatively easy for R2017b, just use MATLAB’s Add-Ons Manager;
ii. for MATLAB version prior to R2017b, it is very difficult:
Download and install 'MinGW-w64' from:
tdm-gcc.tdragon.net/download
sourceforge.net/projects/tdm-gcc/postdownload?source=dlp
sourceforge.net/projects/mingw/files/
Then configure MATLAB as described in:
de.mathworks.com/help/matlab/matlab_external/compiling-c-mex-files-with-mingw.html
de.mathworks.com/help/matlab/matlab_external/install-mingw-support-package.html
de.mathworks.com/matlabcentral/answers/313298-i-already-have-mingw-on-my-computer-how-do-i-configure-it-to-work-with-matlab
2. VISA library file:
a. Different DLL file for different Windows architecture;
b. The library file is available after the installation of NI-488.2 driver (the latest version to date is 'NI4882_1760f0.exe';
c. For 32-bit Windows and 32-bit MATLAB:
i. Library file: ‘visa32.dll’
ii. Location: ‘C:\Windows\System32\’
d. For 64-bit Windows and 64-bit MATLAB:
i. Library file: ‘visa64.dll’
ii. Location: ‘C:\Windows\System32\’
iii. Notes:
1. According to NI’s website, the 64-bit VISA DLL is ‘visa32.dll’ that resides in 'C:\Windows\SysWOW64. This is not right;
2. Alternatively, a 64-bit version of ‘visa32.dll’, which is smaller than ‘visa64.dll’ installed by NI-488.2 driver, can be downloaded from: https://www.azdll.net/files/visa32-dll.html.
3. Header files:
a. Two headers files are needed to load the VISA library: ‘visa.h’ and ‘visatype.h’;
b. Both are available after the installation of NI-488.2 driver;
c. For 32-bit Windows, both files are in:
‘C:\Program Files\IVI Foundation\VISA\Win64\include’
d. For 64-bit Windows, both files are in:
‘C:\Program Files (x86)\IVI Foundation\VISA\WinNT\include’
e. ‘visatype.h’ can be used as it is;
f. ‘visa.h’ must be modified for MATLAB’s LOADLIBRARY. Changes made on ‘visa.h’ are:
i. Add the following at the beginning of the header file:
#ifdef _WIN64
#define __fastcall
#endif
ii. Mask out 'viInstallHandler' and 'viUninstallHandler', as they are not commonly used;
iii. Remove ', ...' from the following functions as it’s not supported by LOADLIBRARY (https://de.mathworks.com/matlabcentral/answers/103180-why-do-i-get-warnings-when-loading-a-dll-with-loadlibrary-in-matlab-7-13-r2011b):
viPrintf, viSPrintf, viScanf, viSScanf, viQueryf
iv. Replace 'ViVAList' with 'ViConstBuf' in the following functions:
viVPrintf, viVSPrintf, viVScanf, viVSScanf, viVQueryf
v. Replace the 'viVxiServantResponse' function with the following:
#ifndef _WIN64
ViStatus _VI_FUNC viVxiServantResponse(ViSession vi, ViInt16 mode, ViUInt32 resp);
#endif
g. The modified ‘visa.h’, renamed as ‘visa_Matlab.h’, can be downloaded from visa_Matlab.h.
Example:
% ‘visa32.dl’ or ‘visa64.dll’, ‘visa_Matlab.h’ and ‘visatype.h’ must be
% available in the local directory
archstr = computer('arch');
if ~isempty(strfind(archstr, 'PCWIN64')) || ~isempty(strfind(archstr, 'win64'))
dllName = 'visa64';
else
dllName = 'visa32';
end
headerFileName = 'visa_Matlab.h';
loadlibrary ([dllName '.dll'], 'visa_Matlab.h','alias',dllName);
visaFunctions = libfunctions(dllName,'-full');
OS : Ubuntu 14.04LTS
Language : Python Anaconda 2.7 (keras, theano)
GPU : GTX980Ti
CUDA : CUDA 7.5
I wanna run keras python code on IPython Notebook by using my GPU(GTX980Ti)
But I can't find it.
I want to test below code. When I run it on to Ubuntu terminal,
I command as below (It uses GPU well. It doesn't have any problem)
First I set the path like below
export PATH=/usr/local/cuda/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH
Second I run the code as below
THEANO_FLAGS='floatX=float32,device=gpu0,nvcc.fastmath=True' python myscript.py
And it runs well.
But when i run the code on pycharm(python IDE) or
When I run it on Ipython Notebook, It doesn't use gpu.
It only uses CPU
myscript.py code is as below.
from theano import function, config, shared, sandbox
import theano.tensor as T
import numpy
import time
vlen = 10 * 30 * 768 # 10 x #cores x # threads per core
iters = 1000
rng = numpy.random.RandomState(22)
x = shared(numpy.asarray(rng.rand(vlen), config.floatX))
f = function([], T.exp(x))
print(f.maker.fgraph.toposort())
t0 = time.time()
for i in xrange(iters):
r = f()
t1 = time.time()
print("Looping %d times took %f seconds" % (iters, t1 - t0))
print("Result is %s" % (r,))
if numpy.any([isinstance(x.op, T.Elemwise) for x in f.maker.fgraph.toposort()]):
print('Used the cpu')
else:
print('Used the gpu')
To solve it, I force the code use gpu as below
(Insert two lines more on myscript.py)
import theano.sandbox.cuda
theano.sandbox.cuda.use("gpu0")
Then It generate the error like below
ERROR (theano.sandbox.cuda): nvcc compiler not found on $PATH. Check your nvcc installation and try again.
how to do it??? I spent two days..
And I surely did the way of using '.theanorc' file at home directory.
I'm using theano on an ipython notebook making use of my system's GPU. This configuration seems to work fine on my system.(Macbook Pro with GTX 750M)
My ~/.theanorc file :
[global]
cnmem = True
floatX = float32
device = gpu0
Various environment variables (I use a virtual environment(macvnev):
echo $LD_LIBRARY_PATH
/opt/local/lib:
echo $PATH
/Developer/NVIDIA/CUDA-7.5/bin:/opt/local/bin:/opt/local/sbin:/Developer/NVIDIA/CUDA-7.0/bin:/Users/Ramana/projects/macvnev/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
echo $DYLD_LIBRARY_PATH
/Developer/NVIDIA/CUDA-7.5/lib:/Developer/NVIDIA/CUDA-7.0/lib:
How I run ipython notebook (For me, the device is gpu0) :
$THEANO_FLAGS=mode=FAST_RUN,device=gpu0,floatX=float32 ipython notebook
Output of $nvcc -V :
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2015 NVIDIA Corporation
Built on Thu_Sep_24_00:26:39_CDT_2015
Cuda compilation tools, release 7.5, V7.5.19
From your post, probably you've set the $PATH variable wrong.