|
Message-ID: <CA+EaD-bmOLe3ZiZR4ZivmDveJGGzAkbzz2p2FWRGHDM3Rua8WA@mail.gmail.com> 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.