Also, if I use the generated ruby.trace.gz file (of
that deadlock trace) instead of specifing -l length, the ruby tester actually
reports success. Why does this differ from running with -l? I'm really
confused.
Lei
----- Original Message -----
Sent: Thursday, February 15, 2007 10:10
PM
Subject: Re: [Gems-users] A question on
ruby tester
Thank you Mike. Did you mean
g_SEQUENCER_OUTSTANDING_REQUESTS? I made that 1 but still have the same
problem. I guess I don't understand in the first place why in cycle 10624 the request
address is 0xdc0 but the deadlock complains about 0xdee?
Thanks a lot!
Lei
----- Original
Message -----
Sent: Thursday, February 15, 2007 9:22
PM
Subject: RE: [Gems-users] A question on
ruby tester
A couple more
tips:
Take a look at the
PROTOCOL_DEBUG_TRACE. See if there is another block that has failed.
If too many requests are outstanding, the sequencer will start the
request but there are no available resources to handle it.
There is a section
on the Wiki on using the trace output.
When first
debugging a protocol, change g_OUTSTANDING_REQUESTS to 1 until that works.
--Mike
-----Original
Message----- From:
gems-users-bounces@xxxxxxxxxxx [mailto:gems-users-bounces@xxxxxxxxxxx]
On Behalf Of Lei
Yang Sent: Thursday,
February 15, 2007 4:18 PM To: Gems-users@xxxxxxxxxxx Subject: [Gems-users] A question on
ruby tester
I am using Ruby tester to verify
my cache coherence protocol and found a weird problem. Basically I got this
error message of possible deadlock:
Warning: in fn virtual void
Sequencer::wakeup() in system/Sequencer.C:121: Possible Deadlock
detected Warning: in fn virtual void Sequencer::wakeup() in
system/Sequencer.C:122: request is [CacheMsg: Address=[0xdee, line
0xdc0] Type=ATOMIC ProgramCounter=[0xf0, line 0xc0]
AccessMode=SupervisorMode Size=1 Prefetch=No Version=0 Aborted=0 Time=10624
] Warning: in fn virtual void Sequencer::wakeup() in
system/Sequencer.C:123: m_chip_ptr->getID() is 2 Warning: in fn
virtual void Sequencer::wakeup() in system/Sequencer.C:124: m_version is
0 Warning: in fn virtual void Sequencer::wakeup() in
system/Sequencer.C:125: current_time is 1000002 Warning: in fn virtual
void Sequencer::wakeup() in system/Sequencer.C:126: request.getTime() is
10624 Warning: in fn virtual void Sequencer::wakeup() in
system/Sequencer.C:127: current_time - request.getTime() is
989378 Warning: in fn virtual void Sequencer::wakeup() in
system/Sequencer.C:128: keys.size() is 16 Warning: in fn virtual void
Sequencer::wakeup() in system/Sequencer.C:129: *m_writeRequestTable_ptr is [
[0xdc0, line 0xdc0]=
I searched for address 0xdee and
it appears NO where in the output trace. Then I went to request time 10624
and saw this:
10624 2
-1
Seq
Begin
> [0xdc0, line
0xdc0]
After this line there is no
occurance of 0xdc0. It appears to me that after the request
on 0xdc0 is issued by the sequencer, nothing else was done. I
don't even know wheter it is instruction read or load/store. Then
somehow it leads to a deadlock. Could anyone please give me a hint on how
might I find out the problem?
_______________________________________________ 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.
|