Nilay, I am using MESI_CMP_directory. Ok, let me try out with that kernel and
see.
Thanks,
Dibakar
On 05/02/12, Nilay Vaish wrote:
> Dibakar, which protocol are you using? Also try with the kernel that is
> available on gem5's website. The kernel that I compiled was for enabling more
> than 8 CPUs. It works well with timing simple cpu, but I have seen it fail
> with the o3 cpu. In your case, the error appears very early, it should not be
> too hard to debug this. I'll take a look.
>
> --
> Nilay
>
> On Wed, 2 May 2012, Dibakar Gope wrote:
>
> >Hi Nilay,
> >
> >As per your suggestion, I was trying to run the o3cpu with x86 in FS mode on
> >the latest dev repository. However I am still getting assertion failure.
> >here is the output:
> >
> >
> >command line: ./build/X86/gem5.opt configs/example/ruby_fs.py --num-cpus=2
> >--kernel x86_64-vmlinux-2.6.22.9.smp --cpu-type=detailed
> >warning: add_child('terminal'): child 'terminal' already has parent
> >Global frequency set at 1000000000000 ticks per second
> >info: kernel located at:
> >/home/dibakar/disk-image-x86-05-02/binaries/x86_64-vmlinux-2.6.22.9.smp
> >0: rtc: Real-time clock set to Sun Jan 1 00:00:00 2012
> >Listening for com_1 connection on port 3456
> >warn: Reading current count from inactive timer.
> >0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000
> >0: system.remote_gdb.listener: listening for remote gdb #1 on port 7001
> >**** REAL SIMULATION ****
> >info: Entering event queue @ 0. Starting simulation...
> >gem5.opt: build/X86/mem/packet_queue.cc:234: virtual bool
> >SlavePacketQueue::sendTiming(Packet*, bool): Assertion `!send_as_snoop'
> >failed.
> >Program aborted at cycle 7985500
> >Aborted
> >
> >
> >
> >
> >I tried the timingcpu with the same kernel (I guess you compiled this
> >kernel, which we subsequently used for 757, Linux version 2.6.22
> >([email protected]) (gcc version 4.5.2 (GCC) ) #1 SMP Mon Feb 13
> >10:59:02 CST 2012) and it can bootup the cpu successfully.
> >
> >
> >Regards,
> >Dibakar
> >
> >
> >
> >
> >
> >On 04/20/12, Nilay Vaish wrote:
> >>Dibakar, I have only tested o3cpu and ruby with the X86 architecture. I
> >>don't know if the combination ever worked with Alpha architecture. But I
> >>would expect it work, because there was nothing architecture specific
> >>involved in making the o3cpu and ruby work together.
> >>
> >>I also noticed that I marked Alpha + o3 cpu + ruby as 'should work'. That's
> >>incorrect, it should be marked 'might work'.
> >>
> >>--
> >>Nilay
> >>
> >>On Fri, 20 Apr 2012, Dibakar Gope wrote:
> >>
> >>>Hi,
> >>>
> >>>I was trying to run the O3CPU version in FS mode with Ruby model and alpha
> >>>isa. The prior threads in the mailing list on this topic and the status
> >>>matrix claim that the o3cpu might work with ruby and the ruby_fs.py also
> >>>excepts cpu-type as TimingSimple or detailed only. However, with the
> >>>latest development version, we are getting the following bus error. I
> >>>guess there was an intermediate version of gem5 that was able to run the
> >>>o3cpu with ruby successfully. Could someone please point me to that
> >>>working version, if there exists one?or suggest me to sort out that?
> >>>
> >>>
> >>>command line: ./build/ALPHA_MESI_CMP_directory/gem5.opt
> >>>./configs/example/ruby_fs.py --num-cpus=2 --cpu-type=detailed
> >>>--script=./configs/boot/blackscholes_2c_simmedium.rcS
> >>>Global frequency set at 1000000000000 ticks per second
> >>>info: kernel located at:
> >>>/home/dibakar/disk-image-08-01-12th/binaries/vmlinux
> >>>Listening for system connection on port 3456
> >>>0: system.tsunami.io.rtc: Real-time clock set to Thu Jan 1 00:00:00 2009
> >>>0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000
> >>>0: system.remote_gdb.listener: listening for remote gdb #1 on port 7001
> >>>**** REAL SIMULATION ****
> >>>info: Entering event queue @ 0. Starting simulation...
> >>>72684851: system.terminal: attach terminal 0
> >>>info: Launching CPU 1 @ 381850000
> >>>warn: Prefetch instructions in Alpha do not do anything
> >>>warn: Prefetch instructions in Alpha do not do anything
> >>>fatal: Unable to find destination for addr 0x40700596c on bus system.piobus
> >>> @ cycle 19525020000
> >>>[findPort:build/ALPHA_MESI_CMP_directory/mem/bus.cc, line 525]
> >>>Memory Usage: 383292 KBytes
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>The m5term outputs were as follows:
> >>>==== m5 slave terminal: Terminal 0 ====
> >>>M5 console: m5AlphaAccess @ 0xFFFFFD0200000000
> >>>Got Configuration 623
> >>>memsize 8000000 pages 4000
> >>>First free page after ROM 0xFFFFFC0000018000
> >>>HWRPB 0xFFFFFC0000018000 l1pt 0xFFFFFC0000040000 l2pt 0xFFFFFC0000042000
> >>>l3pt_rpb 0xFFFFFC0000044000 l3pt_kernel 0xFFFFFC0000048000 l2reserv
> >>>0xFFFFFC0000046000
> >>>kstart = 0xFFFFFC0000310000, kend = 0xFFFFFC0000899860, kentry =
> >>>0xFFFFFC0000310000, numCPUs = 0x2
> >>>CPU Clock at 2000 MHz IntrClockFrequency=1024
> >>>Booting with 2 processor(s)
> >>>KSP: 0x20043FE8 PTBR 0x20
> >>>KSP: 0x20043FE8 PTBR 0x20
> >>>Console Callback at 0x0, fixup at 0x0, crb offset: 0x790
> >>>Memory cluster 0 [0 - 392]
> >>>Memory cluster 1 [392 - 15992]
> >>>Initalizing mdt_bitmap addr 0xFFFFFC0000038000 mem_pages 4000
> >>>ConsoleDispatch at virt 100008D8 phys 188D8 val FFFFFC00000100A8
> >>>Bootstraping CPU 1 with sp=0xFFFFFC0000076000
> >>>unix_boot_mem ends at FFFFFC0000078000
> >>>k_argc = 0
> >>>jumping to kernel at 0xFFFFFC0000310000, (PCBB 0xFFFFFC0000018180 pfn 1101)
> >>>Entering slaveloop for cpu 1 my_rpb=FFFFFC0000018400
> >>>CallbackFixup 0 18000, t7=FFFFFC0000814000
> >>>Linux version 2.6.27.6-dirty (joel@capillary) (gcc version 4.3.4
> >>>(crosstool-NG-1.5.2) ) #1 SMP Sat Mar 6 19:10:44 CST 2010
> >>>Booting GENERIC on Tsunami variation DP264 using machine vector DP264 from
> >>>SRM
> >>>Major Options: SMP LEGACY_START VERBOSE_MCHECK
> >>>Command line: root=/dev/hda1 console=ttyS0
> >>>memcluster 0, usage 1, start 0, end 392
> >>>memcluster 1, usage 0, start 392, end 16384
> >>>freeing pages 1103:16384
> >>>reserving pages 1103:1104
> >>>2048K Bcache detected; load hit latency 25 cycles, load miss latency 157
> >>>cycles
> >>>SMP: 2 CPUs probed -- cpu_present_map = 3
> >>>Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16272
> >>>Kernel command line: root=/dev/hda1 console=ttyS0
> >>>PID hash table entries: 512 (order: 9, 4096 bytes)
> >>>Using epoch = 1900
> >>>Console: colour dummy device 80x25
> >>>console [ttyS0] enabled
> >>>Dentry cache hash table entries: 16384 (order: 4, 131072 bytes)
> >>>Inode-cache hash table entries: 8192 (order: 3, 65536 bytes)
> >>>Memory: 120816k/131072k available (3757k kernel code, 7000k reserved, 261k
> >>>data, 208k init)
> >>>
> >>>
> >>>Thanks,
> >>>Dibakar
> >>>_______________________________________________
> >>>gem5-users mailing list
> >>>[email protected]
> >>>http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
> >>>
> >>
> >>_______________________________________________
> >>gem5-users mailing list
> >>[email protected]
> >>http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
> >_______________________________________________
> >gem5-users mailing list
> >[email protected]
> >http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
> >
>
> _______________________________________________
> gem5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
