example0 failed

[crymsen]

Hi, somewhat new to using hashcast, sorry if this is a known issue, but I wasn't able to find an answer...
I am running v3.5.0.

I'm attempting to test my environment, running example0.sh. When I do it fails with:

Code:

Initializing device kernels and memory.../home/crymsen/hashcat-3.5.0/kernels/m00000_a1.c76b1e9f.kernel: Function not implemented

/home/crymsen/hashcat-3.5.0/hashcat.dictstat: Function not implemented

When hashcat starts, it announces:

Code:

* Device #1: This hardware has outdated CUDA compute capability (3.7).
             For modern OpenCL performance, upgrade to hardware that supports
             CUDA compute capability version 5.0 (Maxwell) or higher.
* Device #2: This hardware has outdated CUDA compute capability (3.7).
             For modern OpenCL performance, upgrade to hardware that supports
             CUDA compute capability version 5.0 (Maxwell) or higher.

Running with '-I' tells me:

Code:

OpenCL Info:

Platform ID #1
 Vendor  : NVIDIA Corporation
 Name    : NVIDIA CUDA
 Version : OpenCL 1.2 CUDA 8.0.0

 Device ID #1
   Type           : GPU
   Vendor ID      : 32
   Vendor         : NVIDIA Corporation
   Name           : Tesla K80
   Version        : OpenCL 1.2 CUDA
   Processor(s)   : 13
   Clock          : 823
   Memory         : 2867/11471 MB allocatable
   OpenCL Version : OpenCL C 1.2
   Driver Version : 375.20

 Device ID #2
   Type           : GPU
   Vendor ID      : 32
   Vendor         : NVIDIA Corporation
   Name           : Tesla K80
   Version        : OpenCL 1.2 CUDA
   Processor(s)   : 13
   Clock          : 823
   Memory         : 2867/11471 MB allocatable
   OpenCL Version : OpenCL C 1.2
   Driver Version : 375.20

I am not able to update the drivers on this system, as it's managed by someone else.
Am I running into a versioning issue with drivers/opencl?

Is there an older version of hashcat that would still be compatible with these versions? I looked and wasn't able to find a version/requirement mapping. 

Edit: Attempted to rollback to v3.0.0. Has a dependency issue with libXNVCtrl
Cheers!

[atom]

Looks like a problem when hashcat tries to access some of the files. This is not related to libXNVCtrl, the difference to 3.0.0 is that this version did not had a file check on startup. So maybe you're running it on a shared or network filesystem that could cause problems.

[crymsen]

Looks like a problem when hashcat tries to access some of the files. This is not related to libXNVCtrl, the difference to 3.0.0 is that this version did not had a file check on startup. So maybe you're running it on a shared or network filesystem that could cause problems.

I've continued to work on 3.5.0
On diggin a bit further I've run:
strace -ff -e open /bin/sh ./example0.sh

Ran for a bit and I'm getting:
clGetPlatformIDs(): CL_PLATFORM_NOT_FOUND_KHR

Seems that others have hit this issue as well:
https://github.com/hashcat/hashcat/issues/1207
https://devtalk.nvidia.com/default/topic...9/#3306829

It seems that this issue was focused on the creation of /dev/nvidiactl and nvidiaX devices.
Sadly, it seems like the those are 'fine' on my system. Or at least match the script provided in the nvidia post:

Code:

crw-rw---- 1 root root 244,   1 May  3 11:38 /dev/nvidia-uvm-tools
crw-rw-rw- 1 root root 244,   0 May  2 02:14 /dev/nvidia-uvm
crw-rw-rw- 1 root root 195,   0 May  2 02:14 /dev/nvidia0
crw-rw-rw- 1 root root 195,   1 May  2 02:14 /dev/nvidia1
crw-rw-rw- 1 root root 195,   2 May  2 02:14 /dev/nvidia2
crw-rw-rw- 1 root root 195,   3 May  2 02:14 /dev/nvidia3
crw-rw-rw- 1 root root 195, 255 May  2 02:14 /dev/nvidiactl

Strangely the behavior of hashcat -I changes depending on running strace on it. Without strace I get output similar to above. With strace it errors and exits in the same fashion about 'CL_PLATFORM_NOT_FOUND_KHR'

[crymsen]

Looks like a problem when hashcat tries to access some of the files. This is not related to libXNVCtrl, the difference to 3.0.0 is that this version did not had a file check on startup. So maybe you're running it on a shared or network filesystem that could cause problems.

Yeah... So you're right.

Apparently the 'function not implemented' was related to attempting to lock the kernel file during compilation

Code:

fcntl(38, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = -1 ENOSYS (Function not implemented)

Moving out of the shared file system cleared everything up

Thank you for the help!