Hi Phil,
Thanks for a quick response. I was using FeS2 + ruby.
FeS2 is a timing simulator for X86, and in the port, it
replaced opal's role. Below is the crash error I got
while running a test benchmark on FeS2 + ruby.
Event Log:
SWITCH TO TIMING
simics-common: pyrite/RubyMemoryInterface.cpp:69:
virtual void RubyMemoryInterface::request(int, Waddr,
Waddr, int, RequestType, Waddr, int, int, Waiter*):
Assertion `(*g_ruby_api->isReady)(cpuNumber,
logicalAddr, physicalAddr,
((type==REQUEST_READ)?OPAL_LOAD:OPAL_STORE), thread)'
failed.
Abort (SIGABRT) in main thread
The simulation state has been corrupted. Simulation
cannot continue.
Please restart Simics.
Basically, g_ruby_api is linked to opal-interface in
FeS2:
g_ruby_api = g_ruby_api = (mf_ruby_api_t*)
SIM_get_interface(ruby, "mf-ruby-api");
opal_interface = MM_ZALLOC(1, mf_ruby_api_t);
SIM_register_interface(ruby_class, "mf-ruby-api",
opal_interface);
init_opal_interface( opal_interface );
The backtrace calls that lead to the error above is as
following:
1. When a load/store instruction gets executed, FeS2
makes a call to cacheAccess().
2. Inside that function cacheAccess(),
RubyMemoryInterface::request is called.
3. Inside RubyMemoryInterface::request,
assert((*g_ruby_api->isReady)(cpuNumber, logicalAddr,
physicalAddr,
((type==REQUEST_READ)?OPAL_LOAD:OPAL_STORE), thread)) is
called
4. Inside *g_ruby_api->isReady, Sequencer::isReady is
called --> it returns false because for some reason,
there is more than one outstanding request for the
current address. As a result, the assert statement
mentioned in step 3 failed, and the whole simulation
crashed!
Currently, I temporarily commented that code out, and
the simulation went through without being crashed.
However, I am afraid I would be missing something
fundamental here. Therefore, I would like to know the
reason why there is such restriction about the number of
requests per address.
Thanks again for your time and help,
Binh
On 03/31/2011 06:42 PM, Philip Garcia wrote:
Do you know what the crash is? I recently
experienced some issues with the isReady code when
using an SMT setup where I could end up in a case were
one of the SMT threads starves the other, and a lack
of forward progress is made. However, this was for
GEMS with ruby/opal loaded. If you could give details
of the system you were simulating, and what the error
was I might be able to offer some advice on it.
I'm not 100% sure about the invariant thrown in
there either, I didn't end up changing that at all.
Phil
On Mar 31, 2011, at 3:14 PM, Binh Q. Pham
wrote:
Hi
everyone,
I am using GEMS for x86, and my simulation
crashed in Sequencer::isReady:
// LUKE - disallow more than one request
type per address
// INVARIANT: at most one request
type per address, per processor
int smt_threads =
RubyConfig::numberofSMTThreads();
for(int p=0; p < smt_threads; ++p){
if(
m_writeRequestTable_ptr[p]->exist(line_address(request.getAddress()))
||
m_readRequestTable_ptr[p]->exist(line_address(request.getAddress()))
){
cout << "OUTSTANDING
REQUEST EXISTS " << p << " VER "
<< m_version << endl; //binh:
bug is here
//printProgress(cout);
return false;
}
}
Is there any reason why we have to keep the
invariant: one request type per address above?
To me, it is possible to have multiple
requests per address in the cache...
Thank you in advance for your time and help,
Binh
_______________________________________________
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.
_______________________________________________