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 yours is running fine and mine segfaults.


Also, I think that you were right to try to change CPU in 1g2p.pdesc but the
thing is that guest is assigned pid 0x1, so I am not sure if this could be a
problem or not if guest pid is the same as CPU pid. I'm trying it out now.

Polina


On Thu, Mar 5, 2009 at 12:52 PM, Ali Saidi <sa...@umich.edu> wrote:

> 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, 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 what interrupt to clear for console.
> > warn: Ignoring write to SPARC ERROR regsiter
> > warn: Ignoring write to SPARC ERROR regsiter
> > Segmentation fault
> >
> >
> > and on the console:
> >
> >
> > SunOS Release 5.10 Version Generic_118822-23 64-bit
> > Copyright 1983-2005 Sun Microsystems, Inc.  All rights reserved.
> > Use is subject to license terms.
> > Ethernet address = 0:80:3:de:ad:3
> > mem = 262144K (0x10000000)
> > avail mem = 237879296
> > root nexus = Sun Fire T2000
> > pseudo0 at root
> > pseudo0 is /pseudo
> > scsi_vhci0 at root
> > scsi_vhci0 is /scsi_vhci
> > virtual-device: hsimd0
> > hsimd0 is /virtual-devi...@100/d...@0
> > root on /virtual-devi...@100/d...@0:a fstype ufs
> > pseudo-device: dld0
> > dld0 is /pseudo/d...@0
> > cpu0: UltraSPARC-T1 (cpuid 0 clock 5 MHz)
> > cpu1: UltraSPARC-T1 (cpuid 1 clock 5 MHz)
> >
> > On Tue, Mar 3, 2009 at 11:35 PM, Ali Saidi <sa...@umich.edu> wrote:
> >
> > 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 creating checkpoints and copying stuff into the booted
> > > sparc?
> > Not for creating a checkpoint, that needs to be done within M5, but
> > the instructions for putting stuff on the disk image should be about
> > the same. Mount the image on a solaris machine, copy files in there,
> > done.
> >
> >
> > >
> > > Also, did you have any problems compiling things like hypervisor? I
> > > keep
> > > getting all kinds of errors, like
> > >
> > >
> > > ../../..//hypervisor-tools/bin/qas:
> > > "../../..//greatlakes/common/src/version.s", line 62: error:
> > > redefinition of symbol "qversion"
> > > ../../..//hypervisor-tools/bin/qas:
> > > "../../..//greatlakes/common/src/version.s", line 67: error:
> > > redefinition of symbol "eqversion"
> > > ../../..//hypervisor-tools/bin/qas:
> > > "../../..//greatlakes/common/src/version.s", line 69: error:
> > > redefinition of symbol "printversion"
> > > ../../..//hypervisor-tools/bin/qas:
> > > "../../..//greatlakes/common/src/version.s", line 78: warning:
> > size of
> > > "printversion" redefined
> > > What could be causing them?
> >
> > You need to compile it on a Solaris machine. You don't really need to
> > compile the hypervisor unless you want to modify it. The files you
> > care about are in legion/src/config/niagara/*.conf and the associated
> > make files in there. These too need to be "compiled" on a solaris
> > machine. If you look at 1g2p.hdesc you'll see:
> >
> > CPU(0,guest0,0)
> > CPU(4,guest0,1)
> >
> > I tried changing that 4 to 1 (e.g. CPU id 4 -> 1) and it didn't
> > convince the hypervisor that I was interested in CPU1 not 4. Perhaps
> > there is another place that it is used or something else.
> >
> > Ali
> >
> >
> > >
> > > Thank you.
> > >
> > > Polina
> > >
> > >
> > >
> > > Ali Saidi wrote:
> > >> 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 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
> > >>>> be id 1 and not 4. However, my attempt at doing so didn't seem to
> > >>>> work. The files required to build the hv.bin and md.bin files are
> > >>>> available as part of the OpenSPARC Architecture toolkit that is
> > >>>> available from Sun's website. The packets are generated by
> > uncached
> > >>>> writes to the IOB device registers that the hypervisor code
> > does to
> > >>>> get things going.
> > >>>>
> > >>>> Ali
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Mar 2, 2009, at 5:29 PM, Polina Dudnik wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>>> 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 where bits(12, 8) get
> > >>>>> generated.
> > >>>>> So, I guess my question is: where are the packets generated?
> > >>>>>
> > >>>>> Polina
> > >>>>>
> > >>>>>
> > >>>>> On Mon, Mar 2, 2009 at 3:26 PM, Polina Dudnik
> > <pdud...@gmail.com>
> > >>>>> wrote:
> > >>>>> 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 didn't seem to change the id.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> What makes you think that hypervisor assigns #4 to processor
> > #1? I
> > >>>>> removed this hack and everything works fine.
> > >>>>>
> > >>>>> Polina
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> m5-dev mailing list
> > >>>>> m5-dev@m5sim.org
> > >>>>> http://m5sim.org/mailman/listinfo/m5-dev
> > >>>>>
> > >>>>>
> > >>>> _______________________________________________
> > >>>> m5-dev mailing list
> > >>>> m5-dev@m5sim.org
> > >>>> http://m5sim.org/mailman/listinfo/m5-dev
> > >>>>
> > >>>>
> > >>> _______________________________________________
> > >>> m5-dev mailing list
> > >>> m5-dev@m5sim.org
> > >>> http://m5sim.org/mailman/listinfo/m5-dev
> > >>>
> > >>>
> > >>
> > >> _______________________________________________
> > >> m5-dev mailing list
> > >> m5-dev@m5sim.org
> > >> http://m5sim.org/mailman/listinfo/m5-dev
> > >>
> > >
> > > _______________________________________________
> > > m5-dev mailing list
> > > m5-dev@m5sim.org
> > > http://m5sim.org/mailman/listinfo/m5-dev
> > >
> >
> > _______________________________________________
> > m5-dev mailing list
> > m5-dev@m5sim.org
> > http://m5sim.org/mailman/listinfo/m5-dev
> >
> > _______________________________________________
> > m5-dev mailing list
> > m5-dev@m5sim.org
> > http://m5sim.org/mailman/listinfo/m5-dev
>
> _______________________________________________
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev
>
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to