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.
|
|
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}