ATTENTION! OpenCL kernel self-test failed.

[philsmd]

it would be great if anyone of you (affected users) could try to find out what changes from the recent git history introduced this problem.
I think it would be enough git cloning the repository and trying with cygwin to compile and run the binaries

see
https://github.com/hashcat/hashcat/blob/..._CYGWIN.md or
https://github.com/hashcat/hashcat/blob/...D_MSYS2.md

on how to get the code running . we would then go back in history with git checkouts (make clean, git log, git checkout older versions, make, run) to see which commit introduced the problem. Without this information we can't do much here.

[intem]

it would be great if anyone of you (affected users) could try to find out what changes from the recent git history introduced this problem.
I think it would be enough git cloning the repository and trying with cygwin to compile and run the  binaries

see
https://github.com/hashcat/hashcat/blob/..._CYGWIN.md or
https://github.com/hashcat/hashcat/blob/...D_MSYS2.md

on how to get the code running . we would then go back in history with git checkouts (make clean, git log, git checkout older versions, make, run) to see which commit introduced the problem. Without this information we can't do much here.

All changes are made by the developer. He doesn’t look at our posts? His right to make adjustments based on our statements.

[philsmd]

too many changes since that specific version. it could be (almost) any change that introduced the problem:

current version: +1394 after release
your version: +910 after release

that's almost 500 changes (484 exactly, 1394-910) that could be the culprit

My guess is that this is the commit with the largest changes for -m 2500: https://github.com/hashcat/hashcat/commit/5b97fe7

but I'm also not totally sure if this is still after your +910 version (but seems so from my calculations), that would be a change/version from mid April

Unfortunately, without anybody trying to find the culprit and pinpointing the problem, it's kind of impossible to understand the self-test error. BTW: the code of course works with all new(er) Nvidia/AMD cards as far as we know, so it must be NOT ONLY source code related, but kind of a driver bug that was only triggered by this source code change (the current code works perfectly fine with new AMD and Nvidia GPUs as far as we tested).

[intem]

too many changes since that specific version. it could be (almost) any change that introduced the problem:

current version: +1394 after release
your version: +910 after release

that's almost 500 changes (484 exactly, 1394-910) that could be the culprit

My guess is that this is the commit with the largest changes for -m 2500: https://github.com/hashcat/hashcat/commit/5b97fe7

but I'm also not totally sure if this is still after your +910 version (but seems so from my calculations), that would be a change/version from mid April

Unfortunately, without anybody trying to find the culprit and pinpointing the problem, it's kind of impossible to understand the self-test error. BTW: the code of course works with all new(er) Nvidia/AMD cards as far as we know, so it must be NOT ONLY source code related, but kind of a driver bug that was only triggered by this source code change (the current code works perfectly fine with new AMD and Nvidia GPUs as far as we tested).

Yes. You are right on the newer Ellesmere processor (I have installed the second), the problem does not appear.
hashcat-5.1.0 + 914 gave an error. 14.04.19

[amk]

Hi intem, can you please share the hashcat-5.1.0+910 beta? I didn't find anywhere else to download this version. I having the same issue in my R9 280, Thanks!



Sent by mail.

Please share hashcat-5.1.0+910 beta. Thanks.

[intem]

Please share hashcat-5.1.0+910 beta. Thanks.

Take away:

http://zalil.su/5577819

[amk]

Thanks a lot! It works.

[philsmd]

Wouldn't it make MUCH more sense to find out the root of the problem and see when it was introduced and test how to fix it ?

Using old versions is always bad, they might soon be deprecated (also drivers/CPUs/GPUs might not be supported in the future) and then you got it: an old version that doesn't support your card, just to not invest a couple of minutes and see where the problem could be to fix the problem for everyone having the same problem. I don't understand why people are not willing to test and help others in a meaningful and future-proof manner, instead of just running old code because it "just-works" (who cares about what the problem might be and if hashcat won't work with newer versions, right?)

[amk]

I have tested v15.200.1045.0, v26.20.13001.9005 and latest v26.20.15002.61 AMD drivers on my end with hashcat-v5.1.0 and hashcat-v5.1.0+1508. Both hashcat versions do not work and you apparently claim this is not hashcat problem.

But it is.

It's a fact you can't deny, hashcat-5.1.0+910 works with all above AMD drivers. I can test few more, but do not see any sense as long as you blame AMD side. You probably joking about investing just a couple of minutes. In reality I wasted hours upon hours.

[philsmd]

We would need somebody to test and troubleshoot the hashcat "versions"/changes/commits on github to identify the problem. that is what I was trying to say.

If we know it can be fixed by using the volatile again, we can be sure what the problem is (driver issue) and how to fix it.
The problem also is that it's not currently reproducible by a dev... we would probably need to test the same setup/system with same GPU etc (windows? adrenalin driver? only 290x ?). The best thing would be if an affected user would be able to test the git changes (like mentioned here: https://hashcat.net/forum/thread-8605-po...l#pid45813), i.e. carefully compile the individual versions/changes one-by-one and see when it started to fail (we already pinpointed it a little bit with the "beta version" to git commit mapping)