Can you tell me where you see id 3?
Polina
On Fri, Mar 6, 2009 at 3:49 PM, Ali Saidi <sa...@umich.edu> 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 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 access the thread context like so
> > threadContexts[bits(data,12,8)]. So, I put in two lines which
> > checked that the bits read are within the range of available context
> > and if not I just put in break;. Here's the output I am getting
> > right now (below). I have also put in the change described by Gabe
> > into the m5-dev and right now it is seg-faulting for me, so I will
> > run that in gdb too and try to figure it out.
> >
> > Polina
> >
> > ==== m5 slave terminal: Terminal 0 ====
> > 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)
> >
> > panic[cpu0]/thread=180e000: cpu1 failed to start (2)
> >
> > 000000000180b8b0 unix:start_cpu+124 (1, 10166a0, 0, 181cc00, 2, 0)
> > %l0-3: 0000000000000000 0000000000000000 000000000181cc00
> > 0000000001072000
> > %l4-7: 0000030001385a20 000003000134a0f8 0000000000000004
> > 000000000181a800
> > 000000000180b960 unix:start_other_cpus+194 (1813000, 2, 1, 0,
> > 1836f28, 1839400)
> > %l0-3: 000000000183c5f0 0000000000000001 ffffffffffffffff
> > 0000000000000002
> > %l4-7: 0000000000000001 00000000018b1400 0000000001072000
> > 0000000001016400
> > 000000000180ba10 genunix:main+1d4 (18a9938, 18a5800, 1836340,
> > 1861c00, 0, 18abc00)
> > %l0-3: 0000000070002000 0000000000000001 00000000018abc00
> > 0000000000000002
> > %l4-7: 00000000018aca28 00000000018ac800 00000000018a9948
> > 00000000018a9800
> >
> > syncing file systems... done
> > skipping system dump - no dump device configured
> > rebooting...
> > panic - kernel: prom_reboot: reboot call returned!
> > Program terminated
> > {0} ok boot disk
> > ERROR: Last Trap: Fast Data Access MMU Miss
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 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
>
> _______________________________________________
> 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
