[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAEUbfUBEE16Ebw4gN7VS7xhT4=6HLiJ35-0NsbJ6QDqHKxjWUQ@mail.gmail.com>
Date: Fri, 9 Jan 2026 20:46:56 -0500
From: Daniel Isenberg <djisenberg2015@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: zip-opencl FAILED (crypt_all(1) = 0
>The problem is usually AMD drivers.
>Was this all with the same driver? What driver are you using?
To be perfectly honest I can't say with any certainty which driver I was
using.
I know I tried more than one but not all of them even detected openCL
capability. I hadn't done any really systematic testing yet and was learning
about a lot of different things all at once so it got a bit chaotic. I now
have
a xubuntu installation that I've spun up specifically to test in a more
controlled environment. (although I'm still working out some hardware and
driver kinks) I'm assuming that linux is probably preferable
to Windows both in terms of testing and general usage?
I also have another question regarding the use of --fork. If I am running
in incremental mode with 2 or more devices on the same machine, and
one of those devices is ~3 times faster than the other, is the use of --fork
on it's own enough to properly balance between the 2 devices? The
documentation made it clear that using --node does not automatically
balance devices of differing speed, but it seemed somewhat ambiguous
about that with --fork.
What I think I'm really asking is if --fork in incremental mode distributes
the
total amount of work to be done all at once at the very beginning, assigning
an equal number of candidate passwords to each device, or does it give
chunks of candidate passwords to each device as they complete the
previous chunk? I was running the ASCII charset with min and max lenght=6
and noticed that it gave a %completed value when updated, however the
more powerful card reached 100% sooner than the other devices as one
would expect. However the more powerful card didn't stop. I'm not sure if it
was still doing useful work though.
Another quick question; Are there some questions that are too trivial to
ask here, and if so, where would be a more appropriate place to ask them?
My concern is cluttering up the mailing list with more traffic than they are
really intended for. I also seem to remember reading that the best-practice
is to have a given message only cover a single topic, so I'm a bit concerned
about flooding the list with short questions as a result of this as well.
On Fri, Dec 19, 2025 at 11:24 PM Solar Designer <solar@...nwall.com> wrote:
> Hi Daniel,
>
> On Sat, Dec 06, 2025 at 06:47:44PM -0500, Daniel Isenberg wrote:
> > My first question is if this is the correct way to ask questions/use the
> > mailing list, but as that will likely answer itself, I'll move onto my
> next
> > one.
>
> Yes, it is the correct way, and I'm really sorry no one replied earlier.
>
> > I've been trying to get the zip-opencl format to work on several AMD
> GPU's.
> > (An R7 450 verde and some older Oland cards) but they fail. This is the
> > output with verbosity set to 5:
> >
> > ./john --test=10 --format=zip-opencl --devices=1
> > initUnicode(UNICODE, RAW/RAW)
> > RAW -> RAW -> RAW
> > 0: No OpenCL devices were found on platform #2: CL_DEVICE_NOT_FOUND (-1)
> > Device 1: AMD Radeon (TM) R9 M360 (verde, LLVM 15.0.7, DRM 3.64,
> > 5.15.0-163-generic)
> > Benchmarking: ZIP-opencl, WinZip [PBKDF2-SHA1 OpenCL]... Loaded 4 hashes
> > with 4 different salts to test db from test vectors
> > Build time: 182.729 us
> > LWS=256 GWS=256 (1 blocks) FAILED (crypt_all(1) = 0 for
> > $zip2$*0*1*0*0675369741458183*5dc5*0**36b85538918416712640*$/zip2$)
> >
> > This looks a lot like https://github.com/openwall/john/issues/5709
> however
> > that workaround has been applied in the bleeding edge release that I am
> > using. Instead of the output being (cmp_one(1)) in my case it
> > is (crypt_all(1) = 0).
>
> This looks like a similar kind of issue, but not the same - if you're in
> fact already on a later code revision.
>
> > Does anyone have any idea what the problem is or how I might fix it? I
> have
> > a wide assortment of both nvidia and amd cards at my disposal. Could I
> > contribute by running the --test=0 and making the results and other info
> > available to the developers, and hopefully get my particular issue
> resolved
> > in the process?
>
> The problem is usually AMD drivers. The problem will almost certainly
> go away if you move to an NVIDIA card. It may also go away if you move
> to a different AMD driver and/or card... but you say you've already
> tried several cards - was this all with the same driver? What driver
> are you using? I do notice the device name string says "LLVM 15.0.7,
> DRM 3.64", but these are just lower-level components perhaps in use by a
> higher-level OpenCL backend/driver.
>
> Yes, it will be mildly useful to us to have `--test=0` output for all
> formats, along with information on your system software. You could open
> a GitHub issue for that. It is unlikely we'll address such issues, but
> at least we'll have a record of them.
>
> Thank you!
>
> Alexander
>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
