Mark,
When I see this error running LogTM programs, the cause is
usually that one thread has been swapped out in the middle
of a transaction. To see if this is the case in your run,
set PROFILE_XACT and PROFILE_EXCEPTIONS to true. Look to
see if one or more transactions are being nacked by a
processor that is not making any transactional loads or
stores, or only making transactional loads/stores in
exceptions. If that's the case, your transaction has likely
been swapped out.
The current (released) version of LogTM has a simple, fixed
conflict resolution policy that favors older transactions
and does not take special action when a thread is swapped
out. Although we're working to develop a more robust
mechanism for resolving conflicts, this case usually is a
sign that an error has occurred. I recommend binding
threads to processors to prevent the OS from shuffuling
threads and installing signal handlers to catch segmentation
faults and bus errors, since waiting for a core dump can
take a very long time in simulation. Good luck,
Kevin
Dan Gibson wrote:
That error will arise if Ruby stalls a processor and never delivers a
hit callback:
To stall a processor "indefinately," Ruby stalls it for a large number
of cycles (I think 2,000,000, but it could be 2,000,000,000).
Eventually, if Ruby fails to unstall a processor, the 2e6 cycles elapses
and Simics resumes execution-- ergo "Simics get(s) unstalled without
Ruby asking".
I have no idea how this might arise in the LogTM code...
Regards,
Dan
Mark Gebhart wrote:
Hi,
Sorry for a duplicate question but I originally asked in an unrelated thread
and thought it would be better to break this out into a separate thread and
I added some other thoughts.
I am seeing the following error on a program with long running transactions:
Fatal Error: in fn MemoryTransactionResult
SimicsProcessor::makeRequest(memory_transaction_t*) in
simics/SimicsProcessor.C:365: Error: Simics get unstalled without ruby
asking?
Has anyone seen this before / have any advice to avoid it? This error
message is thrown inside of SimicsProcessor::makeRequest, would it be safe
to just throw a warning instead of an error? Or is there some timeout value
that I need to increase to prevent Simics from getting unstalled since I am
dealing with long running transactions?
Here are all of the messages I see:
Warning: in fn void RegisterState::enableInterrupts(int) in
log_tm/RegisterStateWindowed.C:336: "WARNING: in enable interrupts" is
WARNING: in enable interrupts
Warning: in fn void RegisterState::enableInterrupts(int) in
log_tm/RegisterStateWindowed.C:336: "WARNING: in enable interrupts" is
WARNING: in enable interrupts
Warning: in fn void RegisterState::enableInterrupts(int) in
log_tm/RegisterStateWindowed.C:337: pil is 0
Warning: in fn void RegisterState::enableInterrupts(int) in
log_tm/RegisterStateWindowed.C:337: pil is 0
Fatal Error: in fn MemoryTransactionResult
SimicsProcessor::makeRequest(memory_transaction_t*) in
simics/SimicsProcessor.C:365: Error: Simics get unstalled without ruby
asking?
Fatal Error: in fn MemoryTransactionResult
SimicsProcessor::makeRequest(memory_transaction_t*) in
simics/SimicsProcessor.C:365: Error: Simics get unstalled without ruby
asking?
Thanks for any help anyone can provide,
Mark
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.
|