[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 16 Sep 2013 22:47:37 +0200
From: Katja Malvoni <kmalvoni@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: bcrypt-parallella on 64-core (was: Katja's weekly
report #13)
On Mon, Sep 16, 2013 at 8:20 PM, Yaniv Sapir <yaniv@...pteva.com> wrote:
> BTW, the restriction is not just with fetch, but with load in general. The
> only safe method for a core on this row to read data from ERAM is using
> eDMA. Writing to ERAM, or writing data from host (or external space in
> general) onto these cores is no problem.
>
This partially explains why test failed. Some cores never read start flag,
row 3 cores are among them. But not only row 3. Row 7 as well and some
cores from other rows. After reading start flag, each core should put it to
zero and wait for new one. In total, 38 cores do not read start flag
although they should (file cores). In other runs there were 25 (cores2), 23
and 19 cores which didn't read start flag. First row worked fine except in
case when 38 cores failed to read start flag and proceed with computation.
Because of this host is stuck in polling loop.
I tried reading registers but I don't know what to conclude from them. And
unfortunately before I copied contents of registers into this email, e-read
0 0 0xf0400 25 locked up the system.
Katja
Content of type "text/html" skipped
Download attachment "cores" of type "application/octet-stream" (2439 bytes)
Download attachment "cores2" of type "application/octet-stream" (1671 bytes)
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.
