[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 9 Jul 2013 01:57:44 -0400
From: Yaniv Sapir <yaniv@...pteva.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: bcrypt
Katja,
Hm... Does that mean that e_load() puts zeroes in shared dram if variable
> is declared as static?
>
Definitely. Your mailbox is global, hence static, hence initialized with
zeros. You can verify this by looking at the SREC file. See the data in the
records going to ext. mem. 0x8F00****.
> If so, than my whole shared buffer is filled with zeroes. How can than I
> read garbage from that buffer?
>
Well, if you are reading from the wrong place, maybe? (see below).
> So I created one more really minimal code, it's attached. I load the
> program and than do only one write to shared memory.
> And I ran it many times. I have two scenarios - first one is when I use
> "while(result.core_done[0] == 0)". In that case there is some garbage
> (different from zero) in result.core_done[0] and data is read from the
> shared memory immediately. What I read in that case is some garbage for
> result.core_done array and start array has correct values for all the cores
> (in this example that's 16). If I use sleep(1) (or any longer or shorter
> (usleep) interval), I read only zeroes because all cores are in infinite
> loop - whole start array is filled with zeroes. The only explanation I have
> for this is that whole start array gets overwritten. But only e_load can
> overwrite those since I don't do any writes to start array except when host
> writes 16 to every array location. Cores do not write in that array. I
> checked all offsets, for the attached code, both cores and host return
> exactly the same number for every variable in the data structure.
>
> It seems like you actually ran into a bug situation in the eSDK release.
It happens that the mmap() function, used to map the physical memory in the
e-hal driver, expects to map buffer of sizes multiples of the Linux page
size. This is 4KB, or 0x1000 bytes. Once changed the e_alloc() size from
BufSize [ = sizeof(data) ] to 0x1000, you'll get the expected results, when
using the "sleep()" method. This bug is already fixed in the newest code
that will be released in a day or two.
As for the "while()" method - note that you are polling the core_done[0]
signal. There is no guarantee that by the time core #0 is done, all the
other cores are done too, which can explain why you see garbage results.
--
===========================================================
Yaniv Sapir
Adapteva Inc.
1666 Massachusetts Ave, Suite 14
Lexington, MA 02420
Phone: (781)-328-0513 (x104)
Email: yaniv@...pteva.com
Web: www.adapteva.com
============================================================
CONFIDENTIALITY NOTICE: This e-mail may contain information
that is confidential and proprietary to Adapteva, and Adapteva hereby
designates the information in this e-mail as confidential. The information
is
intended only for the use of the individual or entity named above. If you
are
not the intended recipient, you are hereby notified that any disclosure,
copying,
distribution or use of any of the information contained in this
transmission is
strictly prohibited and that you should immediately destroy this e-mail and
its
contents and notify Adapteva.
==============================================================
Content of type "text/html" skipped
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.
