Thanks for the quick response. I checked out the version from the
repository and rebuilt, and both errors went away.
I am still working through some bugs to get a full run completed, but we'll
save them for another thread. :P
Thanks again,
Joel
On Wed, Jul 9, 2008 at 9:11 AM, Ali Saidi [EMAIL PROTECTED] wrote:
Some quick guesses:
* What version of M5 are you running? There were several cache bug
fixes to b5, not just the one your pointed out. You really should be
running the version in the repository.
* Are you using the tsb_osfpal from the website (or one you compiled
yourself) as opposed to ts_osfpal?
* Is there a reason your switching to a detailed CPU in the middle of
booting?
If I run your command line I get a lot further in the booting process
before switching CPUs. With an atomic cpu (with or without caches) I
can boot 64 processors to the prompt. I would try M5 in the repository
and see if that solves the problem. If not comparing the atomic trace
to the detailed timing trace would probably give you an idea about
where it's going wrong.
Ali
On Jul 9, 2008, at 2:23 AM, Joel Hestness wrote:
Hi,
I have built a couple of the PARSEC benchmarks to run under alpha-
linux and have a disk image set up with these binaries and input
files to run in M5 ALPHA_FS. I have run the complete blackscholes
benchmark using 4 cores/4 threads with no problems. Currently, I am
trying scale up the number of processors to 64. Here is my command
line:
build/ALPHA_FS/m5.opt --outdir=$OUTDIR --trace-flags=Bus --
trace-start=17000 --trace-file=$OUTDIR/tracelog.txt configs/
joel/fs.py --detailed --caches --l2cache --num-cpus=64 --fast-
forward=8000 --script=./configs/joel/parsec/blackscholes.rcS
The first shot at running this resulted in an assertion failure
that is documented in the mailing list thread:
http://www.mail-archive.com/m5-users@m5sim.org/msg00107.html
. Based on the recommendation from this thread, I commented the
assertion, rebuilt M5 and reran the benchmark (I am not sure if this
is related to the next problem that I am having). Now, the
benchmark fails with the following output:
Switched CPUS @ cycle = 28289857500
warn: Entering event queue @ 28289857500. Starting simulation...
Changing memory mode to timing
switching cpus
REAL SIMULATION
warn: Entering event queue @ 28289858000. Starting simulation...
panic: Halt not implemented!
@ cycle 28289931750
[halt:build/ALPHA_FS/cpu/o3/alpha/cpu.hh, line 108]
Program aborted at cycle 28289931750
Abort
Seems this is a result of a kernel panic. Here are the last few
lines of console.system.sim_console (the whole file can be found @
http://www.cs.utexas.edu/~hestness/links/console.system.sim_console)
:
[fc311c60] ret_from_fork+0x0/0x10
[fc33be34] fork_idle+0x54/0xb0
[fc345948] cpu_callback+0xa8/0x1b0
[fc33be08] fork_idle+0x28/0xb0
[fc31d858] __cpu_up+0x38/0x360
[fc310020] __smp_callin+0x0/0x28
[fc310020] __smp_callin+0x0/0x28
Code: a4850018 20650018 408305a1 f428 a4430008 a43e0050
b5a40008 b49e0050
Kernel panic - not syncing: Aiee, killing interrupt handler!
I have encountered this problem with both the kernel distributed
with M5, and the kernel that I have built (linux-2.6.16.53 using
gcc-4.0.2). If anyone has encountered this or something similar, I
would really appreciate any help you can offer.
Thanks,
Joel
___
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
