Hi Tom,
I still didn't figure this out. I have turned on the iface debugging, but
I didn't see anything abnormal during the initialize state. I am not sure
what to check in those two initialization functionss. I am just sure that
the doInitialize() in InorderSimicsFeeder/InorderSimicsFeederImpl.cpp did go
through all the four processors.
Actually I have output:
17 <ExecuteImpl.cpp:285> (execute[0]) {0}- EX initalized
18 <ExecuteImpl.cpp:288> (execute[0]) {0}- Sequential Consistency Enabled
19 <ExecuteImpl.cpp:285> (execute[1]) {0}- EX initalized
20 <ExecuteImpl.cpp:288> (execute[1]) {0}- Sequential Consistency Enabled
21 <ExecuteImpl.cpp:285> (execute[2]) {0}- EX initalized
22 <ExecuteImpl.cpp:288> (execute[2]) {0}- Sequential Consistency Enabled
23 <ExecuteImpl.cpp:285> (execute[3]) {0}- EX initalized
24 <ExecuteImpl.cpp:288> (execute[3]) {0}- Sequential Consistency Enabled
Does this mean executors are correctly connected?
execute[0,1,3] never appears afterwards.
Actually, I also have " L1i[0,1,3]" in the trace during the first 100~200
step, but they disappear afterwards. Do you think maybe this is some
scheduling configuration wrong?
do you have some clue about this? Or do you have some suggestion, what type
of debugging information will can to diagnose this?
I also tried to run a multiple thread program after I comment that assertion
on flexus.cc line 330. it runs, but it seems that only one thread is
executing. Since this is a set-unset-flag application, the execution just
keeps going on and hasn't finished after tens of minutes (I am not sure this
is caused by slow simulating or because the 2nd thread never scheduled and
thus the flag is never set). Do you think this imply a scheduling
configuration problem?
Thanks very much
Shan
-----Original Message-----
From: Thomas Wenisch [mailto:[email protected]]
Sent: Friday, October 28, 2005 8:18 PM
To: shan
Cc: 'SimFlex software support'
Subject: Re: FW: [Simflex] x86 CMP configuration
On Thu, 27 Oct 2005, shan wrote:
>
> I am trying to run the x86 CMP module. I am not sure if what I did is
> correct.
>
> I used the simics enterprise-4p.simics macro and didn't change any
> configuration on the flexus side (should I change any configuration at the
> flexus side?)
>
> When I load the module, it shows:
>
> 1 <startup.cpp:107> {0}- Initializing Flexus.
...
> 4 <InorderSimicsFeederImpl.cpp:338> (feeder[<undefined>]) {0}- Connecting:
> cpu0
>
> 5 <InorderSimicsFeederImpl.cpp:338> (feeder[<undefined>]) {0}- Connecting:
> cpu1
>
> 6 <InorderSimicsFeederImpl.cpp:338> (feeder[<undefined>]) {0}- Connecting:
> cpu2
>
> 7 <InorderSimicsFeederImpl.cpp:338> (feeder[<undefined>]) {0}- Connecting:
> cpu3
>
> Why above feeder index is 'undefined', does it imply I made some mistake
in
> configuration?
The <undefined> notation is harmless. It indicates that this particular
debug message does not have a {FlexusIdx} field associated with it,
because it is in a piece of code that is not associated with a particular
node. All debug messages actually consist of a bunch of fields, like the
sequence number, file, line, source component, etc. You can filter,
redirect, and reformat debug output based on these fields. Take a look at
debug.cfg to get an idea of how this works.
>
>
> Then I type 'continue'. After a while, the screen shows:
>
> 25 <MemoryMapImpl.cpp:319> {0}- Assigned 0 pages.
>
> 26 <flexus.cpp:240> {0}- Timestamp: 2005-Oct-25 19:49:10
>
> 27 <flexus.cpp:326> {108288}- Watchdog timer expired. No progress by CPU
0
> for 100215cycles
>
> 28 <flexus.cpp:330> (<undefined>[<undefined>]) {108288}- Assertion failed:
> ((!(theWatchdogCounts[i] < theWatchdogTimeout + 10))) : Watchdog timer
> expired. No progress by CPU 0 for 100215cycles
>
> *** Simics getting shaky, switching to 'safe' mode.
>
> *** Simics (main thread) received an abort signal, probably an assertion.
>
> <Simics is running in 'safe' mode>
> I checked the assertion at flexus.cpp line 330. It seems that if the cpu
> idles for some time, the assertion would fail. Yes? I temporarily removed
> the assertion and continues. And get following debug output:
>
This assertion indicates that one of the CPUs has not issued an
instruction or completed a memory request for 100k cycles. This can only
come about if there is a deadlock in a Flexus coherence protocol (very
unlikely, as we have run trillions of cycles since we last found a
deadlock bug, but perhaps there is something x86 specific that we are
missing), or for some reason Flexus has not connected itself properly to
your 4 CPUs. Given that you only see output from execute[2], the latter
is very likely.
I suggest you turn up the debug output to confirm that none of the CPUs
are doing anything. Issue the command "flexus.set-debug-severity iface"
before starting the simulation. You should get lots more output, from
which you can figure out if any of the other nodes are active.
The relevant pieces of code to study to figure out this bug are
the init() method in InorderSimicsFeeder/SimicsTracer.hpp and
doInitialize() in InorderSimicsFeeder/InorderSimicsFeederImpl.cpp. If
there is a problem with hooking up to Simics, it will be in one of these
two places.
>
>
> 52 <ExecuteImpl.cpp:341> (execute[2]) {250546}- EX received Reply
> MemoryMessage[Store Reply]: Addr:0xp:00ff3ffac Size:8 Core: 0
>
> 53 <ExecuteImpl.cpp:1287> (execute[2]) {250548}- EX Issuing memory
request:
> MemoryMessage[Store Request]: Addr:0xp:00ff3ffa8 Size:8 Core: 0
>
>
>
> Again, I fear there is something wrong. The reason is, based on the debug
> output only execute[2] is doing work, however, all MemoroyMessage shows
> 'core 0'. Is this something abnormal?
Core 0 does not neccessarily indicate anything is wrong, because the core
field is not set in the execute component, and would still be zero at the
point this debug message is generated.
> :-) sorry for the whole bunch of questions :-).
>
> Thanks very much
>
> Shan
>
>
Regards,
-Tom Wenisch
Computer Architecture Lab
Carnegie Mellon University
