It can be compiled and linked successfully. But when I insert this module into Linux kernel, ippsSum throw an exception. It seems like ipp funcs can't access directly the memory allocated in kernel-space. But I can't allocate user-space memory with ippMalloc/ippFree, that is because these funcs use C runtime library which is not loaded by kernel.
Chuck De Sylva (Intel) wrote:
What happens? Does it Compile? Link? Or crash when ran?
Thanks for your reply. I did the same experiment on Windows/Linux user-space. It works fine too. But when I transform it to a driver program. It can't work. I have not much experience on Linux driver development. I just hope somebody in this forum can tell me how to integrate IPP funcs with my driver code.
Sergey Kostrov wrote:
It works and if the source image is initialized with 1 then:
[ Output ]
1 1 1 1 1 1 1 1 1 1 1 1
[ Core processing ]
status = ippsSum_16s_Sfs( ( Ipp16s * )&iImg, ( int )iLen, ( Ipp16s * )&iSum, 0 );
if( status == ippStsNoErr )
printf( "Sum: %d\n", iSum );
printf( "Error: %d\n", status );
can you implement IPP code in user mode application and call the kernel mode driver is this possible in Linux? in windows user mode app can send the driver IRP's in order to request some work beign done on behalf of user mode code.
Here is the system logs when I insert module into Linux kernel. I appreciate your help.
[ 149.074810] ippSP SSE2 (w7) 7.1.1 (r37466)
[ 149.074814] 0 1 2 3 4 5 6 7 8 9 10 11
[ 149.074831] BUG: unable to handle kernel NULL pointer dereference at 00000009
[ 149.074837] IP: [<f86d8982>] LGLAST2gas_2+0xa/0x1c [ipptest]
[ 149.074848] *pde = 00000000
[ 149.074851] Oops: 0000 [#1] SMP
[ 149.074855] last sysfs file: /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map
[ 149.074858] Modules linked in: ipptest(+) binfmt_misc vesafb snd_hda_codec_idt nvidia(P) snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq ppdev snd_timer snd_seq_device dcdbas snd parport_pc psmouse serio_raw i82975x_edac soundcore snd_page_alloc edac_core lp parport usbhid hid ahci libahci tg3
[ 149.074896] Pid: 1687, comm: insmod Tainted: P 2.6.38-8-generic #42-Ubuntu Dell Inc. Precision WorkStation 390 /0DN075
[ 149.074903] EIP: 0060:[<f86d8982>] EFLAGS: 00010206 CPU: 0
[ 149.074910] EIP is at LGLAST2gas_2+0xa/0x1c [ipptest]
[ 149.074913] EAX: 00010000 EBX: 0000000c ECX: 00000003 EDX: 00010000
[ 149.074916] ESI: 00000001 EDI: 00010000 EBP: f86db3e8 ESP: ef313ea4
[ 149.074919] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 149.074922] Process insmod (pid: 1687, ti=ef312000 task=ef0dd860 task.ti=ef312000)
[ 149.074925] Stack:
[ 149.074926] ef313f04 00000001 00000001 f86d82d0 00000001 0000000b 39343120 3437302e
[ 149.074934] 5d343138 01310020 00000000 f86d651a 00000001 0000000b 00000000 00000006
[ 149.074942] 00000002 ef313ef0 f86dc040 f86d636b 00000001 0000000b ef313f04 00000000
[ 149.074950] Call Trace:
[ 149.074958] [<f86d82d0>] ? w7_ownippsSum_16s32s_Sfs+0x10/0x20 [ipptest]
[ 149.074966] [<f86d651a>] ? w7_ippsSum_16s32s_Sfs+0x2a/0x50 [ipptest]
[ 149.074973] [<f86d636b>] ? w7_ippsSum_16s_Sfs+0x2b/0x80 [ipptest]
[ 149.074980] [<f86d6063>] ? init_module+0x63/0x80 [ipptest]
[ 149.074987] [<c1001255>] ? do_one_initcall+0x35/0x170
[ 149.074993] [<f86d6000>] ? init_module+0x0/0x80 [ipptest]
[ 149.074999] [<c108899b>] ? sys_init_module+0xdb/0x230
[ 149.075004] [<c1125925>] ? sys_close+0x75/0xd0
[ 149.075010] [<c1509bf4>] ? syscall_call+0x7/0xb
[ 149.075012] Code: 7c 1f f3 0f 6f 06 f3 0f 6f 4e 10 66 0f f5 c6 83 c6 20 66 0f f5 ce 83 e9 10 66 0f fe e0 66 0f fe e9 83 c1 10 7e 5f 83 e9 08 7c 12 <f3> 0f 6f 06 83 c6 10 66 0f f5 c6 83 e9 08 66 0f fe e0 83 c1 08
[ 149.075060] EIP: [<f86d8982>] LGLAST2gas_2+0xa/0x1c [ipptest] SS:ESP 0068:ef313ea4
[ 149.075070] CR2: 0000000000000009
[ 149.075074] ---[ end trace d3fa9a9bc3cf75ea ]---
Do you have 64-bit machine?
I'm not experienced in Linux debugging, but I will try to help you as much as I can.From call stack observation the faulting ip is located 9 bytes after this instruction LGLAST2gas_2+0xa/0x1c which simply dereferences null pointer.I'm not sure if In Linux kernel architecture code which dereferences null pointer cannot be trapped in exception handler and simply oops_begin() is called to bring the system down.The last transfer call should be made from this routine w7_ownippsSum_16s32s_Sfs+0x10/0x20 [ipptest].I think that your system is using FPO because ebp is pointing to executable area and esp points to stack space.It would be interesting to dump the esp pointer and try to find the dereferenced pointer.
I tried to link it with IPP threaded libraries as you said. But it still can't work. It shows a system log as follows.
[ 893.449624] ipptest: Unknown symbol _GLOBAL_OFFSET_TABLE_ (err 0)
I guess this is because the IPP threaded libraries used POSIX pthread library internally which can't be used in kernel-space.