On Thu, Mar 5, 2009 at 3:38 PM, Gabriel Michael Black <gbl...@eecs.umich.edu > 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 using to work around the problem, but we > need to come up with a full solution. I don't know if this is what the > problem is, but it sounds like it could be. > > Gabe Are you talking about the seg fault in m5-stable that I get? Or the CPU ids? Polina > > > Quoting Ali Saidi <sa...@umich.edu>: > > > 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
