scons: *** [build/ALPHA_FS/mem/cache/builder.fo] Error 1
scons: *** [build/MIPS_SE/cpu/simple/base.fo] Error 1
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic
passed.
* build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp
passed.
*
This is the mail system at host daystrom.m5sim.org.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete
It looks like Alpha turns on all the CPUs to start with where x86 only
turns on the BP and brings up the APs with IPIs. I think SPARC is
actually more similar, but it looks like I'm already doing what it's
doing. I remember Ali fixed some of the SPARC SMP boot issues recently,
but I looking at
I'm going to go with the theory that the wake up function needs to wake
up unallocated CPUs too.
Gabe
Gabe Black wrote:
It looks like Alpha turns on all the CPUs to start with where x86 only
turns on the BP and brings up the APs with IPIs. I think SPARC is
actually more similar, but it
On Fri, Feb 27, 2009 at 9:34 AM, Gabe Black gbl...@eecs.umich.edu wrote:
changeset d35d2b28df38 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=d35d2b28df38
description:
X86: Add a class to support 32 bit x86 linux process.
diff -r 2b989b925c9c -r d35d2b28df38
-X86LinuxProcess::X86LinuxProcess(LiveProcessParams * params,
+X86_64LinuxProcess::X86_64LinuxProcess(LiveProcessParams * params,
ObjectFile *objFile)
-: X86LiveProcess(params, objFile),
-Num_Syscall_Descs(273)
+: X86LinuxProcess(params, objFile, syscallDescs, 273)
I agree that this stuff is all messed up. There's threads and cpus
each which have various states that don't necessarily work with each
other. Some of the states have to do with indicating that a CPU has
nothing to do at the moment so we don't need to schedule a tick, and
some indicate the type
Nate,
are you referring to the CPU's state vs. the actual thread-object's state?
That connection between the two in my opinion has been ad-hoc for
awhile or at least beyond my complete understanding.
Changing things for FS breaks SE and vice-versa.
Needless to say, we should probably get this
Yep.
On Sat, Feb 28, 2009 at 6:40 PM, Korey Sewell ksew...@umich.edu wrote:
Nate,
are you referring to the CPU's state vs. the actual thread-object's state?
That connection between the two in my opinion has been ad-hoc for
awhile or at least beyond my complete understanding.
Changing
I think that Steve is the only one who both pays attention to the list
and might understand what's going on here.
Nate
On Mon, Feb 23, 2009 at 2:30 AM, Gabe Black gbl...@eecs.umich.edu wrote:
I was working on getting the X86_FS working with the timing simple
CPU as well as it does with
My guess is that you might be checking on it before it's set up. In
the constructor is probably too early. If you grep for MemoryMode
you'll see where/how it gets changed.
Ali
On Feb 28, 2009, at 10:49 PM, nathan binkert wrote:
I think that Steve is the only one who both pays attention to
11 matches
Mail list logo
