If the trace indicates the Sequencer started a request, but then nothing
else happens, you need to figure out why the "mandatoryQueue" of the L1
Cache Controller is stalled. Some previous request might not be
failing, but it may have not released resources before completing. For
example, a request may force a replacement. As soon as the data is
moved to an allocated TBE buffer, the request proceeds. But if the
replacement doesn't succeed, you have a TBE still allocated but this
won't be detected as a deadlock in the Sequencer. There may be other
examples.
Also the deadlock detector checks read requests before write requests.
See Sequencer::wakeup()
--Mike
Lei Yang wrote:
Thanks Mike for the prompt reply. What I don't understand is, if some
previous request fails, why doesn't the tester report error on that
request instead of this one?
Lei
----- Original Message ----- From: "Mike Marty" <mikem@xxxxxxxxxxx>
To: "Lei Yang" <lya755@xxxxxxxxxxxxxxxxxxxx>
Sent: Thursday, February 22, 2007 11:13 PM
Subject: Re: [Gems-users] A question on ruby tester
Lei Yang wrote:
Hello Mike,
I'm getting the same deadlock error again. For the one posted in
last email, I somehow solved it by changing one of my latencies from
0 to 1. However, I don't know why that helped. Now when I increase
the tester length, I got similar deadlock again. The sequencer
starts a request and next thing I know is this request is a
deadlock. Could you please be a bit more specific on "not enough
resource to handle it"? And, how do I tell if there are requests
before that which have failed?
I'm looking at the protocol debug trace by checking the result of
'x86-linux/generated/MSI_MOSI_CMP_directory/bin/tester.exec -p 4 -a
1 -l 900 -s 1' . Is this what you meant by "look at the
PROTOCOL_DEBUG_TRACE"?
Yes, you'll need to dig through the trace and see what is going on.
Some other previous request or writeback is likely failing. "-s 1"
enables the trace. Make sure RUBY_DEBUG=true in Makefile.
Please use gems-users@xxxxxxxxxxx so that everyone can benefit from
the discussion
--Mike
|