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 and I need to wait
for the lab to upgrade scons.

Polina

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

> 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 1000000000000 ticks per second
> info: No kernel set for full system simulation. Assuming you know what
> you're doing...
> Listening for t1000 connection on port 3456
>       0: system.t1000.htod: Real-time clock set to Thu Jan  1
> 00:00:00 2009
>
>       0: system.t1000.htod: Real-time clock set to 1230768000
> Listening for t1000 connection on port 3457
> 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7001
> 0: system.remote_gdb.listener: listening for remote gdb #1 on port 7000
> **** REAL SIMULATION ****
> info: Entering event queue @ 0.  Starting simulation...
> hack: Processor 2 is virtual processor 4. Swizzle the numbers(this
> will only work for <= 2 processors)
> hack: Processor 2 is virtual processor 4. Swizzle the numbers(this
> will only work for <= 2 processors)
> info: Ignoring write to SPARC ERROR regsiter
> info: Ignoring write to SPARC ERROR regsiter
> warn: Don't know what interrupt to clear for console.
> For more information see: http://www.m5sim.org/warn/7fe1004f
> info: Ignoring write to SPARC ERROR regsiter
> info: Ignoring write to SPARC ERROR regsiter
>
>
> and the console output looks like:
> cpu cpu
>
> Sun Fire T2000, No Keyboard
> Copyright 2006 Sun Microsystems, Inc.  All rights reserved.
> OpenBoot 4.23.0, 256 MB memory available, Serial #1122867.
> [saidi obp #30]
> Ethernet address 0:80:3:de:ad:3, Host ID: 80112233.
>
>
>
> Boot device: /virtual-devices/d...@0  File and args: -vV
> Loading ufs-file-system package 1.4 04 Aug 1995 13:02:54.
> FCode UFS Reader 1.12 00/07/17 15:48:16.
> Loading: /platform/SUNW,Sun-Fire-T2000/ufsboot
> Loading: /platform/sun4v/ufsboot
> device path '/virtual-devi...@100/d...@0:a'
> The boot filesystem is logging.
> The ufs log is empty and will not be used.
> standalone = `kernel/sparcv9/unix', args = `-v'
> Elf64 client
> Size: 0x76e40+0x1c872+0x3123a Bytes
> modpath: /platform/sun4v/kernel /kernel /usr/kernel
> module /platform/sun4v/kernel/sparcv9/unix: text at [0x1000000,
> 0x1076e3f] data at 0x1800000
> module misc/sparcv9/krtld: text at [0x1076e40, 0x108f737] data at
> 0x184dab0
> module /platform/sun4v/kernel/sparcv9/genunix: text at [0x108f738,
> 0x11dd437] data at 0x18531c0
> module /platform/sun4v/kernel/misc/sparcv9/platmod: text at
> [0x11dd438, 0x11dd43f] data at 0x18a4be0
> module /platform/sun4v/kernel/cpu/sparcv9/SUNW,UltraSPARC-T1: text at
> [0x11dd440, 0x11e06ff] data at 0x18a5300
> 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)
>
> At this point there is no futher output. I imagine that one cpu is
> waiting for another  one or something and whatever condition it's
> waiting for is not being reached. It is still interesting to know why
> it's crashing for you, since it might shed some light on the reason.
> The thing to do now is look through the solaris  source to see what is
> going on right after the cpuX: ... lines are printed and look at an
> exec trace and try to debug the problem.
>
> Ali
>
>
>
> On Mar 5, 2009, at 2:30 PM, Polina Dudnik wrote:
>
> > 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 <ste...@gmail.com>
> > wrote:
> > m5 or m5-stable?  The contextId change is in the former but not the
> > latter.
> >
> > 2009/3/5 Polina Dudnik <pdud...@gmail.com>:
> > > I am doing it in m5.
> > >
> > > Polina
> > >
> > > - Show quoted text -
> > > On Thu, Mar 5, 2009 at 1:04 PM, Steve Reinhardt <ste...@gmail.com>
> > wrote:
> > >>
> > >> - Show quoted text -
> > >> 2009/3/5 Polina Dudnik <pdud...@gmail.com>:
> > >> > 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 doing is
> > working
> > >> on SPARC functionality to do that based on the m5 tree.  I really
> > want
> > >> to have a do-over on the gem5 tree and make it such that Ruby vs.
> > the
> > >> classic M5 memory system is a compile-time option so that we don't
> > >> have to have a permanent fork like we do now.
> > >>
> > >> Steve
> > >> _______________________________________________
> > >> 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