Jake,
There is a bug in the released version of LogTM that might be causing
your error. Does your test program contain small transactions in a
tight loop? If so, this failure could be a result of the following problem:
* processor p0 runs transaction t1 storing block A
* A is in the cache, but the first line of p0's log (L) is not
* the store to A completes quickly, but the store to L stalls
* t1 commits before the log store completes **the bug**
* p0 begins transaction t2, resetting its log pointer
* p0 executes a second store, triggering a second store to L
* ruby crashes because there are now two outstanding stores to the same
address
We have a fix for this that we hope to release shortly (ruby will be
smart enough to stall transactional stores until the log entry is
available). The next release should include that fix and support for
simics 3. In the meantime, I don't think you'll run into this problem
running more substantial transactional programs. But, if you do, please
let me know and I'll try to get you a fix asap.
If you don't think this is the problem you're seeing, could you please
send me your test program and I'll try to recreate the crash here.
Thanks,
Kevin
|