Hi, Nilay, I try to extract the particular revision you did, which is 8930,
but seems this is an unknown revision. Is that anything wrong I did? My
command is simply *hg update -r 8930*. Thank you.


Best,
Veydan

On Thu, May 3, 2012 at 12:57 PM, Nilay Vaish <[email protected]> wrote:

> I am guessing you cloned the gem5 repository using hg. You can use 'hg
> update -r <revision number>' to move to that particular revision.
>
>
> --
> Nilay
>
> On Thu, 3 May 2012, Dibakar Gope wrote:
>
>  Thanks Nilay. Let me try it on that version. by the way, how do yo
>> extract a specific revision from the repository?
>>
>> Dibakar
>>
>> On 05/03/12, Nilay Vaish  wrote:
>>
>>> I am facing the same problem as you are. So, I rolled back to revision
>>> 8930. That version works.
>>>
>>> --
>>> Nilay
>>>
>>> On Thu, 3 May 2012, Dibakar Gope wrote:
>>>
>>>  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<http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users>
>>>>>>>>
>>>>>>>>
>>>>>>> ______________________________**_________________
>>>>>>> gem5-users mailing list
>>>>>>> [email protected]
>>>>>>> http://m5sim.org/cgi-bin/**mailman/listinfo/gem5-users<http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users>
>>>>>>>
>>>>>> ______________________________**_________________
>>>>>> gem5-users mailing list
>>>>>> [email protected]
>>>>>> http://m5sim.org/cgi-bin/**mailman/listinfo/gem5-users<http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users>
>>>>>>
>>>>>>
>>>>> ______________________________**_________________
>>>>> gem5-users mailing list
>>>>> [email protected]
>>>>> http://m5sim.org/cgi-bin/**mailman/listinfo/gem5-users<http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users>
>>>>>
>>>> ______________________________**_________________
>>>> gem5-users mailing list
>>>> [email protected]
>>>> http://m5sim.org/cgi-bin/**mailman/listinfo/gem5-users<http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users>
>>>>
>>>>
>>> ______________________________**_________________
>>> gem5-users mailing list
>>> [email protected]
>>> http://m5sim.org/cgi-bin/**mailman/listinfo/gem5-users<http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users>
>>>
>> ______________________________**_________________
>> gem5-users mailing list
>> [email protected]
>> http://m5sim.org/cgi-bin/**mailman/listinfo/gem5-users<http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users>
>>
>
> _______________________________________________
> gem5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>



-- 
Regards,

Veydan
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to