This is definitely a possibility. While the format might support any
valid combination, it's possible that the hypervisor code itself
assumes that there are four threads per core and so another CPU must
be id 4. You might try changing the numthreads to 2 and keep numcores
at 1.
Ali
On Mar
changeset a1e71f3576f8 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=a1e71f3576f8
description:
prefetch: don't panic on requests w/o contextID (e.g., writebacks).
diffstat:
3 files changed, 18 insertions(+), 2 deletions(-)
src/mem/cache/prefetch/ghb.cc|7 +
Yeah, I kinda though that too, more along the lines that other OpenSparc
binaries are dependent somehow on the hypervisor binary and should also be
recompiled. So, I did post to their forum, but they are not responding. So,
I will look through OpenSparc and see if maybe they are hardcoding this.
O
I was thinking about that the other day, and maybe OpenSparc is
configuring the first thread of each core? Those could be numerically
4 apart, one per thread, which I believe is what you said is happening.
Gabe
Quoting Polina Dudnik :
> So, just to keep everyone posted: I did what Gabe sugge
So, just to keep everyone posted: I did what Gabe suggests and returned
whenever a thread is unallocated and got the same seg fault I was getting in
stable release where the processor numbers had to be swizzled. Meanwhile, in
the stable release where I did swizzle the numbers I am getting an assert
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o
