That sounds reasonable. But in this
line,
12689 0
-1
Seq
Done
> [0x34ea, line 0x34c0] 1867 cycles NULL
No
it shows first the actual address, then the aligned block address. So
the traces does print word address too. It doesn't seem to me that this is a
code consistency problem. Is it possible that there is a bug in the sequencer?
I'm just curious.
Thanks, Lei
----- Original Message ----- From:
"Mike Marty" <mikem@xxxxxxxxxxx> To: "Lei Yang"
<lya755@xxxxxxxxxxxxxxxxxxxx> Sent: Thursday, February 15, 2007 10:21 PM Subject: Re:
[Gems-users] A question on ruby tester
> It is the same block
cache block. It is probably just inconsistent code > that prints
the word address in one spot and the block address in another. > >
--Mike > > Lei Yang wrote: >> 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
----- >> >> *From:* Mike Marty
<mailto:mikem@xxxxxxxxxxx> >> *To:* 'Lei Yang' <mailto:lya755@xxxxxxxxxxxxxxxxxxxx> ; 'Gems >> Users' <mailto:gems-users@xxxxxxxxxxx> >> *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 >> >> >> Hello
everyone, >> >> >> 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? >> >> >> Thank you
very much! >> >> >>
Lei >> >> > >
|
|