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
