MBP not enough allocatable device-memory - Printable Version +- hashcat Forum (https://hashcat.net/forum) +-- Forum: Support (https://hashcat.net/forum/forum-3.html) +--- Forum: hashcat (https://hashcat.net/forum/forum-45.html) +--- Thread: MBP not enough allocatable device-memory (/thread-5575.html) |
MBP not enough allocatable device-memory - BeanBagKing - 06-30-2016 I'm wondering if anyone else has run into this issue when using a Macbook Pro. If I force Device 1 (-D 1), everything seems to work fine. However, anything using device 2 (-D 2 or -D 1,2) eventually runs into a allocatable device-memory error and stops. Judging by the location of the benchmark, the error is occuring when it reaches the scrypt hashtype. I suspect this is expected given the small amount of memory available to that device. If not though, I wanted to make sure others were aware of it, and I'll post it to the github issues. Even if it's expected, would the desired behavior be to skip that hashtype and move on? Code: XXX@XXX:~/xxx/hashcat-3.00$ ./hashcat.app -b Edit: I take that back, -D 1 eventually fails as well. Code: XXX@XXX:~/xxx/hashcat-3.00$ ./hashcat.app -D 1 -b RE: MBP not enough allocatable device-memory - atom - 07-01-2016 Quote:- Device #2: Device does not provide enough allocatable device-memory to handle this attack This kind of error is actually that you do not have enough (device) memory to handle scrypt. But you're right, it should skip over the error and continue. Please post a GitHub issue for that. Quote:ERROR: clEnqueueNDRangeKernel() : -54 : CL_INVALID_WORK_GROUP_SIZE This is a known error. For some reason on OSX, on CPU, it's not allowed to use a 2nd (or 3rd) dimension for the kernel execution in GPGPU. It's a runtime limitation which is basically not there, it's a pure software limitation. I can't workaround this, because for bitsliced DES kernel (like LM) it's required. However the problem is the same. It should skip over and continue with the benchmark. |