[m5-users] halt not implemented in PARSEC
HI , During simulation of PARSEC benchmarks, i am getting this error. Any idea how to resolve it. *panic: Halt not implemented! * -- *thanksregards * *BISWABANDAN PANDA* *M.S.(RESEARCH SCHOLAR)* *RISE LAB* *IIT MADRAS* http://www.cse.iitm.ac.in/~biswa/ ___ m5-users mailing list m5-users@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
Re: [m5-users] Creating ruby checkpoints
There is one known problem with unserializing into a system with switch_cpus defined, that I have an uncommitted patch for here: http://reviews.m5sim.org/r/608 Based on your description I don't think this is what you're seeing, but I thought I'd throw it out there in case I'm wrong, or you're actually running into a different manifestation of the same bug, or perhaps it will jog Brad's memory to think of a related cause. Steve On Fri, May 6, 2011 at 2:00 AM, Timothy M Jones timothy.jo...@cl.cam.ac.ukwrote: Hi Brad, Thanks for the reply and the explanation about Ruby. I've attached the runscript.rcS file that I was using. I'm using the kernel from the M5 website and disk image from UTexas ( http://www.cs.utexas.edu/~parsec_m5/linux-parsec-2-1-m5-with-test-inputs.img.bz2) I looked at the config file and checkpoint files. The CPUs do have the same names and I don't get any unserialization warnings at all when running from the checkpoint. I did notice that the CPU types were different (since I was creating checkpoints with AtomicSimpleCPU) but adding the '-t' switch to the creation command didn't make the error go away. I also tried using the ruby_fs.py script to create checkpoints too by adding support for '--script' within it using the attached patch. This created a checkpoint without problems. Loading from it caused a segmentation fault in the simulated program though. These were the commands I used for that: ./build/ALPHA_FS/m5.fast -d ../outputs --remote-gdb-port 0 ./configs/example/ruby_fs.py -n 2 --script=../scripts/runscript.rcS --max-checkpoints=1 ./build/ALPHA_FS/m5.fast -d ../outputs --remote-gdb-port 0 ./configs/example/ruby_fs.py -n 2 -r 0 Thanks again Tim Beckmann, Brad wrote: Hi Tim, Before I try to help you with your specific problem, I want to point out that is Ruby's current support for checkpointing is a little confusing and that is one area that we are actively improving. In particular Ruby currently uses physmem as a functional memory image and thus messages within Ruby only impact the timing of memory accesses. Thus, loading a checkpoint with Ruby is nothing more than loading Ruby's backing image of physmem with the checkpointed memory image. Also there is no current support for cache warmup. We are in the process of changing that, but that code is not yet ready. Having said that, I suspect that your problem is something different. In general, your sequence of commands should work and I can't reproduce your specific error since I don't have your particular rcS script. I'd be curious to know if you see any unserialzation warnings complaining that certain simobjects aren't in the loaded checkpoint. In particular, do the cpus have the exact same name between the config.ini file with ruby and the m5.cpt file in your checkpoint? Sorry I can't be more help, but if you send me your rcS script, I'd be happy to investigate further. Brad -Original Message- From: m5-users-boun...@m5sim.org [mailto:m5-users- boun...@m5sim.org] On Behalf Of Timothy M Jones Sent: Wednesday, May 04, 2011 5:49 AM To: M5 users mailing list Subject: [m5-users] Creating ruby checkpoints Hello, I'm trying to create checkpoints for use with ruby using ALPHA_FS. It takes ages to boot linux with ruby enabled, and since I want several checkpoints for different numbers of cores, I was hoping I'd be able to create checkpoints without ruby, then run from the checkpoints with. This doesn't appear to work. If I create a checkpoint with this command: ./build/ALPHA_FS/m5.fast -d ../outputs --remote-gdb-port 0 ./configs/example/fs.py -n 2 --max-checkpoints=1 -- script=../scripts/runscript.rcS Then I can run it fine with this command: ./build/ALPHA_FS/m5.fast -d ../outputs --remote-gdb-port 0 ./configs/example/fs.py -n 2 -r 0 But switching to ruby causes errors: /build/ALPHA_FS/m5.fast -d ../outputs --remote-gdb-port 0 ./configs/example/ruby_fs.py -n 2 -r 0 In the system.terminal file I get this error output: script(759): unhandled unaligned exception pc = [fc6b83c0] ra = [fc6b83bc] ps = 0007 r0 = 1f6c8000 r1 = fc3111a0 r2 = fc018000 r3 = 002b r4 = 0720 r5 = fc85ecb8 r6 = 0059 r7 = 0040 r8 = 3fff r9 = fc001f5c5580 r10= fc001f3eec00 r11= fcd09b80 r12= fc001f6b0740 r13= 0001 r14= 0008 r15= fc001f657e48 r16= 1f654000 r17= fc001f3eec00 r18= fc001f6b0740 r19= 0001 r20= r21= fc860640 r22= r23= 00200618a0cf r24= 4000 r25= 03ff r27= fc311190 r28= fc001f5c5580 This seems to happen no matter which protocol I compile into the binary, although this was with MESI_CMP_directory. Does anyone have any suggestions as to how I can go
[m5-users] Are dependencies between the pipelinestages?
Hello, I am currently trying to parallelize the m5 sim ( o3/cpu.cc ) with pthreads. In a first stage I am trying to have the various stages of the pipeline run in parallel, ( decode.tick() fetch.tick() ). Currently I have 5 pthreads each executing one of the stages. However ( yes you saw it comming ), It seems to be crashing relatively randomly when cleaning up cleanUpRemovedInsts(); and in that on: InstList.erase(removeList.front()); because of an invalid free. Or an assertion in the commit stage build/ALPHA_SE/cpu/o3/commit_impl.hh:1139: bool DefaultCommitImpl::commitHead(typename Impl::DynInstPtr, unsigned int) [with Impl = O3CPUImpl]: Assertion `!thread[tid]-inSyscall' failed. So I am wondering if there are some dependencies between stages that I am unaware of . Greetings, Jos Ewert ___ m5-users mailing list m5-users@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
Re: [m5-users] Tracing does not work
Hey Nilay, It looks like the tracing (debug) functionality is now working again, but the M5 help message is still incorrect (and extremely misleading). For instance, trace-flags, and trace-file are still accepted, but they don't do anything now. They should be eliminated from the message. We're also missing the equivalent of trace-start and trace-file. Do you mind cleaning that up? Thanks, Joel PS. I haven't followed the tracing/debugging thread closely enough, but it seems like trace and debug should be different things (though they are currently implemented as the same thing). Is there a reason why we moved over to debug? On Fri, Apr 29, 2011 at 8:28 AM, Nilay Vaish ni...@cs.wisc.edu wrote: On Fri, 29 Apr 2011, Korey Sewell wrote: Is it not now debug-help and debug-flags instead of trace-help and trace-flags??? On Fri, Apr 29, 2011 at 9:18 AM, Nilay Vaish ni...@cs.wisc.edu wrote: On Thu, 28 Apr 2011, Nilay wrote: On Thu, April 28, 2011 7:55 pm, Andrea Pellegrini wrote: Hi all, I just downloaded the latest repo from: http://repo.m5sim.org/m5 When I activate the trace functionalities through the flags nothing shows up in the output. The same command for older versions of m5 (few weeks ago) worked flawlessly. Can anybody help? Thanks -Andrea Andrea, we are aware of the problem. The solution is almost ready, and hopefully by tomorrow trace would start functioning again. -- Nilay Andrea, trace facility is working now. In fact it was fixed yesterday itself. -- Nilay ___ m5-users mailing list m5-users@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/m5-users -- - Korey That's right, the option names have been changed. But there was some error in the trace facility it self that Nate corrected yesterday. Nilay ___ m5-users mailing list m5-users@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/m5-users -- Joel Hestness PhD Student, Computer Architecture Dept. of Computer Science, University of Texas - Austin http://www.cs.utexas.edu/~hestness ___ m5-users mailing list m5-users@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
