There's no ifdef around it, this is the normal setting/reading of the
address space number register for the purpose of page table entries. I
went ahead and changed it to use IPR_ITB_ASN in my own code for both
the itb and dtb translate functions, as well as initializing it to
m5_pid << 4. This seems to be working fine now, I've successfully done
> 128 processes. Not sure if it's the correct fix, but it's a
workaround.
-Nick
On Feb 15, 2008, at 2:16 PM, nathan binkert wrote:
I don't have time to look at the code right now, but all of this IPR
stuff is for Full system mode. Are you sure this code isn't inside an
#ifdef? If it is not, then we probably need to just create a
mechanism that will work for both. It should be pretty simple.
Nate
On Fri, Feb 15, 2008 at 9:33 AM, Nicolas Zea <[EMAIL PROTECTED]>
wrote:
I think I trace the problem down. The issue is that that core 129
(M5_pid = 128) is unable to get a correct TLBEntry object because the
asn value it reads from its misc register file is 0, while the pid
stored in the tlbentry is 128. This causes the translation request to
fault, which then leads to trying to advance directly to fault
handler, which faults, leading to an infinite loop between fetch()
and
advanceInst(fault) (lines 538 and 555 of timing.cc are where the loop
is formed).
The problem is that the IPR_DTB_ASN misc register for core 128 gets
set to pid << 57 (in arch/alpha/process.cc line 80), which overflows
for pids > 7 bits. I'm not all that familiar with the alpha isa, but
does it need to be shifted by 57 bits like that? Or maybe it should
be
using IPR_ITB_ASN instead of the DTB one (The ITB::translate function
uses the IPR_DTB_ASN) which can have 60 bits of accuracy?
-Nick
On Feb 14, 2008, at 2:53 PM, Steve Reinhardt wrote:
If it works in atomic mode but not timing, I suspect some sort of
cache deadlock (try cranking up the number of targets per MSHR, or
less likely the number of MSHRs), or maybe we're using a int8_t for
the bus ID somewhere (which would fail at 256 since we use -1 for
broadcast).
Steve
On Thu, Feb 14, 2008 at 12:46 PM, Nicolas Zea
<[EMAIL PROTECTED]> wrote:
Is it possible to run a multiprogram simulation with more than 128
cores? Using a slightly modified se.py and running in simple timing
mode, I've tried to run the hello world default benchmark on 129
cores, and it never gets past the "starting simulation" message.
For
128 cores it runs fine (including printing out the "warning:
increasing stack size by one page" message, but the moment I go
above
128 I never see that warning and it hangs.
On the other hand, running in atomic simple cpu mode it completes
for
even 256 cores.
This is using an unmodified m5 2.0b4 source. Does anyone know what
may
be causing this issue, and if there is a way to get around it? Or
how
I may go about tracing the problem down? I'm not sure what all
steps
occur between the "starting simulation" message and when the
programs
get loaded (which I assume causes the stack size increase), but
that's
when the simulator appears to get stuck.
Thanks,
Nick
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
