I'd turn on the progress interval first and see if the simulation is not
progressing somewhere. If it is, then go the point of last committed
instructions and see what the simulator is working for.

Next, I'd look to see if the progress interval keeps showing a similar
amount of instructions at a certain point. If so, it's probably stuck in
some simulation loop waiting for a value. I'd print out that instruction
trace and look there to see where is the "looping point".

Lastly, I'd use the TimingSimpleCPU to run the same code and match up
instructon traces at that point. Figure out what value is not getting
updated and then at that point you can apply the patch.




On Fri, Apr 26, 2013 at 1:59 PM, Vinay <[email protected]> wrote:

>  Hi All,
>
> I am trying to simulate an inorder cpu using Alpha full system simulation.
> I am using parsec benchmarks.
>
> The kernel boots up initially and then it gets stuck at 'Calibrating delay
> loop'.
> I am using the latest disk image and kernel given in Parsec Utexas site.
> The O3 model, timing works fine even in smt mode. So, I dont think the
> problem is in the kernel.
>
> I also applied the 'hw_rei' patch by changing it to a control instruction.
> But still the inorder simulation gets stuck at this point - 'Calibrating
> delay loop'.
>
> Can anyone help me pointing out what might be the error? I know that many
> of them have a simulated inorder cpu successfully for ALPHA_FS mode after
> applying that hw_rei patch. But I am getting this weird error even after
> applying that patch.
>
> -------
> Below is the command I am using: (I have not attached the host terminal
> output because I was running in debug mode and had enabled the ExecAll
> flags which displays everything and would clutter the entire mail)
>
> *build/ALPHA/gem5.debug --debug-flags=ExecAll -d In_output/blackscholes
> configs/example/fs.py --script=configs/boot/runscript_black.rcS
> --cpu-type=inorder  --num-cpus=4 --caches --l2cache*
>
> --------
> Below is the m5term terminal output:
>
> vinay@vinay-VPCEB46FG:~$ m5term localhost 3456
> ==== m5 slave terminal: Terminal 0 ====
> M5 console: m5AlphaAccess @ 0xFFFFFD0200000000
> Got Configuration 623
> memsize 20000000 pages 10000
> 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 = 0x4
> CPU Clock at 2000 MHz IntrClockFrequency=1024
> Booting with 4 processor(s)
> KSP: 0x20043FE8 PTBR 0x20
> KSP: 0x20043FE8 PTBR 0x20
> KSP: 0x20043FE8 PTBR 0x20
> KSP: 0x20043FE8 PTBR 0x20
> Console Callback at 0x0, fixup at 0x0, crb offset: 0xC90
> Memory cluster 0 [0 - 392]
> Memory cluster 1 [392 - 65144]
> Initalizing mdt_bitmap addr 0xFFFFFC0000038000 mem_pages 10000
> ConsoleDispatch at virt 10000DD8 phys 18DD8 val FFFFFC00000100A8
> Bootstraping CPU 1 with sp=0xFFFFFC0000076000
> Bootstraping CPU 2 with sp=0xFFFFFC0000078000
> Bootstraping CPU 3 with sp=0xFFFFFC000007A000
> unix_boot_mem ends at FFFFFC000007C000
> k_argc = 0
> jumping to kernel at 0xFFFFFC0000310000, (PCBB 0xFFFFFC0000018180 pfn 1101)
> CallbackFixup 0 18000, t7=FFFFFC0000814000
> Entering slaveloop for cpu 1 my_rpb=FFFFFC0000018400
> Entering slaveloop for cpu 3 my_rpb=FFFFFC0000018900
> Entering slaveloop for cpu 2 my_rpb=FFFFFC0000018680
> 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    65536
> freeing pages 1103:65536
> reserving pages 1103:1104
> 2048K Bcache detected; load hit latency 32 cycles, load miss latency 97
> cycles
> SMP: 4 CPUs probed -- cpu_present_map = f
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65088
> Kernel command line: root=/dev/hda1 console=ttyS0
> PID hash table entries: 2048 (order: 11, 16384 bytes)
> Using epoch = 1900
> Console: colour dummy device 80x25
> console [ttyS0] enabled
> Dentry cache hash table entries: 65536 (order: 6, 524288 bytes)
> Inode-cache hash table entries: 32768 (order: 5, 262144 bytes)
> Memory: 509800k/524288k available (3757k kernel code, 10704k reserved,
> 261k data, 208k init)
> Calibrating delay loop...
>
> ------
>
> It gets stuck for hours together after this point.
> Any help would be appreciated.
> Thank you.
>
> --
>  Thanks and Regards,
>
> *Vinay Gangadhar*
> First Year Masters Student,
> Computer Architecture,
> Department of Electrical and Computer Engineering
> [email protected]
> [email protected]
>
> _______________________________________________
> gem5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>



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

Reply via email to