Interrupt types and interrupt/exception vectors are different things.
There are only 7 interrupt types, while there are a couple hundred
interrupt vectors. If you're hitting an assert, there is normally a
reason for that. A backtrace would be helpful to figure out why.
Ali
On Mar 12, 2009
And actually,
Looking at the output, there is definitely somethign in the hypervisor that
relies on cpu numbers. Because it is the hypervisor that prints out "cpu1
failed to start", BUT the hardware description file says it should be 'cpu4'
which is why we swizzle 4 to 1. So, clearly switching the
Ali,
I am a little worried that NumInterruptTypes is set to seven. I ran into an
assert which was indicating that the received interrupt was beyond
NumInterruptTypes, and I ignored it to see what happens. But, I looked
through catchexc.fth in OpenSparc and there are many more exceptions than 7.
So
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
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
Oh, never mind, I understand what you are saying. I will do that.
On Fri, Mar 6, 2009 at 3:49 PM, Ali Saidi wrote:
> You probably need to swizzle those bits as well.. turn id 3 into id 1.
> Perhaps then it will work.
>
> Ali
>
> On Mar 6, 2009, at 4:44 PM, Polina Dudnik wrote:
>
> > Hi Ali!
> >
Can you tell me where you see id 3?
Polina
On Fri, Mar 6, 2009 at 3:49 PM, Ali Saidi wrote:
> You probably need to swizzle those bits as well.. turn id 3 into id 1.
> Perhaps then it will work.
>
> Ali
>
> On Mar 6, 2009, at 4:44 PM, Polina Dudnik wrote:
>
> > Hi Ali!
> >
> > So, I did run the
You probably need to swizzle those bits as well.. turn id 3 into id 1.
Perhaps then it will work.
Ali
On Mar 6, 2009, at 4:44 PM, Polina Dudnik wrote:
> Hi Ali!
>
> So, I did run the seg-faulting boot in gdb and realized that in ./
> build/SPARC_FS/arch/sparc/tlb.cc line 1264 was seg-faulting
Hi Ali!
So, I did run the seg-faulting boot in gdb and realized that in
./build/SPARC_FS/arch/sparc/tlb.cc line 1264 was seg-faulting because it was
reading bits(data,12,8) and not checking to see that they are within the
range of the total thread contexts available and then it was trying to
acces
On Thu, Mar 5, 2009 at 5:10 PM, Gabriel Michael Black wrote:
> The change is simple enough that I'll just describe it. This deals
> solely with the simple CPU, so if your trying to use O3, for example,
> it won't help you directly. The code here:
> http://repo.m5sim.org/m5/file/886da6fa6d4a/src/c
I know why it wouldn't compile now. For some reason it just wasn't happy
with SUNW,Sun-Fire-880 but once I moved to SUNW,Sun-Fire-T200 it worked like
a charm!
On Tue, Mar 3, 2009 at 11:35 PM, Ali Saidi wrote:
> SUNW,Sun-Fire-T200
> On Mar 3, 2009, at 9:48 PM, Polina wrote:
>
> > Hi Ali,
> >
> >
OK. Thanks. I will try that.
On Thu, Mar 5, 2009 at 5:10 PM, Gabriel Michael Black wrote:
> The change is simple enough that I'll just describe it. This deals
> solely with the simple CPU, so if your trying to use O3, for example,
> it won't help you directly. The code here:
> http://repo.m5sim.
The change is simple enough that I'll just describe it. This deals
solely with the simple CPU, so if your trying to use O3, for example,
it won't help you directly. The code here:
http://repo.m5sim.org/m5/file/886da6fa6d4a/src/cpu/simple/base.cc#l307
should return if the thread is suspended
Oh, I see. Do you think you can distribute the partial patch you have?
Thank you.
Polina
On Thu, Mar 5, 2009 at 4:48 PM, Gabriel Michael Black wrote:
> Quoting Polina Dudnik :
>
> > On Thu, Mar 5, 2009 at 3:38 PM, Gabriel Michael Black <
> gbl...@eecs.umich.edu
> >> wrote:
> >
> >> There's act
Quoting Polina Dudnik :
> On Thu, Mar 5, 2009 at 3:38 PM, Gabriel Michael Black > wrote:
>
>> There's actually a bug in the CPU wakeup code which prevents any CPU
>> that isn't activated and then suspended, like SPARCs APs which are
>> suspended directly, from waking up on interrupts, etc. I have
On Thu, Mar 5, 2009 at 3:38 PM, Gabriel Michael Black wrote:
> There's actually a bug in the CPU wakeup code which prevents any CPU
> that isn't activated and then suspended, like SPARCs APs which are
> suspended directly, from waking up on interrupts, etc. I have a
> partial fix which I've been
There's actually a bug in the CPU wakeup code which prevents any CPU
that isn't activated and then suspended, like SPARCs APs which are
suspended directly, from waking up on interrupts, etc. I have a
partial fix which I've been using to work around the problem, but we
need to come up with a
Oh, turns out we have the most recent version, the lab just had to fix the
pointer to it.
On Thu, Mar 5, 2009 at 2:57 PM, nathan binkert wrote:
> If you want to get going quickly, you can download the scons-local
> package and just stick it somewhere.
>
> Nate
>
> 2009/3/5 Polina Dudnik :
> > Y
If you want to get going quickly, you can download the scons-local
package and just stick it somewhere.
Nate
2009/3/5 Polina Dudnik :
> Yes, I am trying to figure it out right now by running it withing gdb. It is
> pretty interesting that my output only differs from yours by one line which
> is
Yes, I am trying to figure it out right now by running it withing gdb. It is
pretty interesting that my output only differs from yours by one line which
is segfault.
It will be a little bit before I can install the most recent m5-dev because
the scons was upgraded to 0.98 and we are still on 0.97
My output looks like this:
M5 compiled Mar 5 2009 13:51:37
M5 revision 632115b48346 5955 default qtip tip start_sparc_2cpu.diff
qbase
M5 started Mar 5 2009 14:03:22
M5 executing on zeep
command line: ./build/SPARC_FS/m5.opt configs/example/fs.py -n 2
Global frequency set at 1 ticks
It is m5-stable. Maybe I should change to m5. I can do that.
Also, are any of the binaries dependent on 1g2p-md.bin or 1g2p-hv.bin by any
chance?
Polina
On Thu, Mar 5, 2009 at 1:24 PM, Steve Reinhardt wrote:
> m5 or m5-stable? The contextId change is in the former but not the latter.
>
> 20
m5 or m5-stable? The contextId change is in the former but not the latter.
2009/3/5 Polina Dudnik :
> I am doing it in m5.
>
> Polina
>
> - Show quoted text -
> On Thu, Mar 5, 2009 at 1:04 PM, Steve Reinhardt wrote:
>>
>> - Show quoted text -
>> 2009/3/5 Polina Dudnik :
>> > I am not sure why ou
I am doing it in m5.
Polina
On Thu, Mar 5, 2009 at 1:04 PM, Steve Reinhardt wrote:
> 2009/3/5 Polina Dudnik :
> > I am not sure why our code base would be different and by how much, but
> that
> > could be why yours is running fine and mine segfaults.
>
> Hi Polina,
>
> If you're doing this in
2009/3/5 Polina Dudnik :
> I am not sure why our code base would be different and by how much, but that
> could be why yours is running fine and mine segfaults.
Hi Polina,
If you're doing this in the gem5 repository then that is getting stale
wrt the main m5 tree. It might be best if all you're
Sure, I will. I didn't make any changes really, but I think my code must be
different from yours by a little because for example I don't have function
tc->contextId()), instead I had to use tc->readCpuId()
I am not sure why our code base would be different and by how much, but that
could be why yo
Could you run m5 in gdb and give us a backtrace? That would probably
identify the problem. What additional changes did you make?
Ali
On Mar 5, 2009, at 11:57 AM, Polina Dudnik wrote:
> Hi Ali,
>
> Would you mind sending me the console output you are getting for
> booting 2 processors, beca
Hi Ali,
Would you mind sending me the console output you are getting for booting 2
processors, because I am getting the seg fault right now and I am trying to
locate it.
Here's what I get:
warn: Ignoring write to SPARC ERROR regsiter
warn: Ignoring write to SPARC ERROR regsiter
warn: Don't know
On Mar 3, 2009, at 9:48 PM, Polina wrote:
> Hi Ali,
>
> Thanks for your help. I hate to keep asking things, but there's little
> documentation. I appreciate you taking the time to respond to my
> emails.
>
> Oh, I see now. Would I follow the procedure outline in OpenSPARC
> readme
> files for
Hi Ali,
Thanks for your help. I hate to keep asking things, but there's little
documentation. I appreciate you taking the time to respond to my emails.
Oh, I see now. Would I follow the procedure outline in OpenSPARC readme
files for creating checkpoints and copying stuff into the booted sparc?
T1 The hv and md description files need to match the configuration
you're running. If you're only running 1 processor you need to change
the hv and md files to the 1up configuration (as opposed to the 1g2p
versions).
Ali
On Mar 3, 2009, at 9:10 PM, Polina wrote:
>
> Ali,
>
> Just to be
Ali,
Just to be sure, are you using T1 or T2 release of OpenSparc? Thanks.
Polina
> Well, it's probably best to actually make 2 CPUs work and then go back
> and fix things for N CPUs. It should be possible to make the
> hypervisor description file (1g2p-hv.bin) understand that CPU 1 should
Hi,
I am now trying to boot SPARC_FS with just one processor and in the attached
terminal I see:
cpu
ERROR: 1 CPUs in PD did not start
Could this be because of the patch I applied? Thank you.
The reason I want to boot SPARC_FS with one processor is because I want to
create a checkpoint. Is it
Ali Saidi wrote:
> Well, it's probably best to actually make 2 CPUs work and then go back
> and fix things for N CPUs. It should be possible to make the
> hypervisor description file (1g2p-hv.bin) understand that CPU 1 should
> be id 1 and not 4. However, my attempt at doing so didn't seem to
Well, it's probably best to actually make 2 CPUs work and then go back
and fix things for N CPUs. It should be possible to make the
hypervisor description file (1g2p-hv.bin) understand that CPU 1 should
be id 1 and not 4. However, my attempt at doing so didn't seem to
work. The files requir
Never mind, I started the console and got ERROR: 1 CPUs in PD did not start
without the hack. So, you are right, there is something wrong with the cpu
numbers. But I want to fix it for arbitrary numCpus. SO, to do that I want
to find a place where the requests generate their data. So, the place whe
Hi Ali,
Why do you say:
Additionally, I had to put two hacks in to swizzle the CPU id numbers. For
whatever reason the hypervisor insists that the second CPU should be id 4
while m5 would like it to be id 1. I tried changing the hypervisor
description file and changing cpu4 to cpu1, however that
39 matches
Mail list logo
