Karthik, Wait for the VM to boot up. MARSS is prone to crash if you try to simulate before init finishes booting services.
I just checked out a clean copy of MARSS. After passing rootdelay=200 (as documented: http://marss86.org/~marss86/index.php/QEMU_Tips), I passed "simconfig -machine private_L2" as the VM was booting. When the VM got to the shell, I did ./start_sim; ls; ./stop_sim And it worked fine... 1037eeaPTLCALL type PTLCALL_ENQUEUE MARSSx86::Command received : -stop Stopped after 5854991 cycles, 7428498 instructions and 63 seconds of sim time (cycle/sec: 92936 Hz, insns/sec: 117912, insns/cyc: 1.2687462713435427) Tyler > Hi Tyler, > > Actually this error occurs very soon after I start the simulation from > the QEMU monitor. The error occurs even before I get to the guest OS > window. For both the machines (shared_l2 &private_L2) I get this > error. More specifically I get the error message when I give the > command "simconfig -run -machine MACHINE_NAME" in the QEMU monitor and > when I press Ctrl+Alt+Shift-1 to switch to the guest OS. Hence I could > not start any benchmarks too. > > Also please find the error message I while simulating both the > "shared_l2" & "private_L2" machines provided in the 'default.conf' > configuration file. I am using the disk images provided in the > marss86.org website. Both the machines provide the same error message: > > shared_l2: > ERROR: guest physical address 0xfffffff0 is out of bounds > ERROR: guest physical address 0xfffffff0 is out of bounds > ERROR: guest physical address 0xfffffff0 is out of bounds > ERROR: guest physical address 0xfffffff0 is out of bounds > ERROR: guest physical address 0xfffffff0 is out of bounds > ERROR: guest physical address 0xfffffff0 is out of bounds > ERROR: guest physical address 0xfffffff0 is out of bounds > qemu-system-x86_64: ptlsim/build/core/ooo-core/ooo-pipe.cpp:2054: int > ooo::ReorderBufferEntry::commit(): Assertion `ctx.get_cs_eip() == > uop.rip' failed. > > private_L2: > ERROR: guest physical address 0xfffffff0 is out of bounds > ERROR: guest physical address 0xfffffff0 is out of bounds > ERROR: guest physical address 0xfffffff0 is out of bounds > ERROR: guest physical address 0xfffffff0 is out of bounds > ERROR: guest physical address 0xfffffff0 is out of bounds > ERROR: guest physical address 0xfffffff0 is out of bounds > ERROR: guest physical address 0xfffffff0 is out of bounds > qemu-system-x86_64: ptlsim/build/core/ooo-core/ooo-pipe.cpp:2054: int > ooo::ReorderBufferEntry::commit(): Assertion `ctx.get_cs_eip() == > uop.rip' failed. > > Your comments are more welcome. > > Thanks, > karthik > > Note: In my previous mail there were differences in error messages for > these same machines as I was using my own disk image instead of the > disk image available for download from www.marss86.org website. > > On Wed, Jul 23, 2014 at 8:24 AM, <[email protected]> wrote: >> Karthik, >> >> Which benchmark(s) are you running? Kernel version? Are you using one of >> the stock images? This shouldn't happen in a stock configuration like >> this... >> >> Tyler >> >>> Hi, >>> >>> Thanks a lot for taking your time to help me out amidst your busy >>> schedule. Do you need any more data from my side? Kindly let me know. >>> >>> Regards, >>> karthik >>> >>> On Mon, Jul 14, 2014 at 5:38 PM, karthik vm <[email protected]> wrote: >>>> Hi Brendan &Tyler, >>>> >>>> I have compiled MARSS with C=32 and ran both shared_l2 and private_L2. >>>> Unfortunately both of them crashed. Please find below the assertions I >>>> got with the simulation of each of them: >>>> >>>> shared_l2: >>>> ERROR: guest physical address 0xfffffff0 is out of bounds >>>> qemu-system-x86_64: ptlsim/build/core/ooo-core/ooo-pipe.cpp:2054: int >>>> ooo::ReorderBufferEntry::commit(): Assertion `ctx.get_cs_eip() == >>>> uop.rip' failed. >>>> >>>> private_L2: >>>> qemu-system-x86_64: ptlsim/build/core/ooo-core/ooo-pipe.cpp:2054: int >>>> ooo::ReorderBufferEntry::commit(): Assertion `ctx.get_cs_eip() == >>>> uop.rip' failed. >>>> >>>> I got the above assertions for the simulated machines consistently. I >>>> tried to simulate each one thrice. >>>> Kindly let me know if you need any other data. >>>> >>>> Thanks, >>>> karthik >>>> >>>> On Sun, Jul 13, 2014 at 10:51 PM, Brendan Fitzgerald >>>> <[email protected]> wrote: >>>>> Compile with c=32 then run either shared_l2 or private_L2 since they >>>>> are >>>>> configured with OoO cores. >>>>> >>>>> By sample he means it's the one we provide. The core doesn't reflect >>>>> an >>>>> actual machine, but it's close. >>>>> >>>>> >>>>> On Sun, Jul 13, 2014 at 9:25 PM, karthik vm <[email protected]> wrote: >>>>>> >>>>>> Hi Tyler, >>>>>> >>>>>> I am not quite clear what you mean by sample OoO configurations. >>>>>> Currently the 'shared_l2' or 'private_L2' machine configurations are >>>>>> configured as OoO cores. So you want me to compile MARRS for 32 >>>>>> cores >>>>>> and simulate one of these machines? Can you clarify? Thanks. >>>>>> >>>>>> Regards, >>>>>> karthik >>>>>> >>>>>> On Sat, Jul 12, 2014 at 2:12 PM, <[email protected]> >>>>>> wrote: >>>>>> > Karthik, >>>>>> > >>>>>> > Can you try one of the sample OoO configurations? The >>>>>> configuration >>>>>> > files >>>>>> > are sensitive and currently not fully checked for validity. >>>>>> > >>>>>> > Compile with: >>>>>> > scons c=32 >>>>>> > >>>>>> > Then use the 'shared_l2" or 'private_L2' machine configuration (be >>>>>> aware >>>>>> > of the capitalization differences...) >>>>>> > >>>>>> > That should give you a 32-core non-SMT configuration. >>>>>> > >>>>>> > Tyler >>>>>> > >>>>>> >> Hi Tyler, >>>>>> >> >>>>>> >> Thanks for your immediate reply. Great to know that MARSS is >>>>>> suited >>>>>> >> for analyzing lock contention. >>>>>> >> >>>>>> >> Basically I was trying to simulate the 'private_L2' machine from >>>>>> the >>>>>> >> 'default' configuration file with enable-kvm switch in qemu. The >>>>>> >> configuration of 'cores' in private_L2 is below: >>>>>> >> >>>>>> >> cores: >>>>>> >> - type: ooo >>>>>> >> name_prefix: ooo_ >>>>>> >> >>>>>> >> Since there are no option for # of threads. I guess the cores are >>>>>> >> single threaded or non SMT. Anyway to enforce this I added the >>>>>> threads >>>>>> >> option as below: >>>>>> >> >>>>>> >> cores: >>>>>> >> - type: ooo >>>>>> >> name_prefix: ooo_ >>>>>> >> option: >>>>>> >> threads: 1 >>>>>> >> >>>>>> >> When I ran the simulation I get the same error again: >>>>>> >> qemu-system-x86_64: ptlsim/build/core/ooo-core/ooo-pipe.cpp:2054: >>>>>> int >>>>>> >> ooo::ReorderBufferEntry::commit(): Assertion `ctx.get_cs_eip() == >>>>>> >> uop.rip' failed. >>>>>> >> >>>>>> >> Then I tried to change the core type from 'ooo' to 'atom' which >>>>>> is >>>>>> non >>>>>> >> SMT in the machine. Please find the configuration below: >>>>>> >> >>>>>> >> cores: >>>>>> >> - type: atom >>>>>> >> name_prefix: atom_ >>>>>> >> option: >>>>>> >> threads: 1 >>>>>> >> >>>>>> >> Now also I see that the simulation stops with the following error >>>>>> >> shortly after it started: >>>>>> >> qemu-system-x86_64: >>>>>> ptlsim/build/core/atom-core/atomcore.cpp:2128: >>>>>> >> void atom::AtomThread::dtlb_walk(): Assertion `dtlb_miss_addr' >>>>>> failed. >>>>>> >> >>>>>> >> Kindly let me know your comments. >>>>>> >> >>>>>> >> Thanks, >>>>>> >> karthik >>>>>> >> >>>>>> >> On Thu, Jul 10, 2014 at 11:50 AM, <[email protected]> >>>>>> wrote: >>>>>> >>> Karthik, >>>>>> >>> >>>>>> >>> This assertion: >>>>>> >>> ooo::ReorderBufferEntry::commit(): Assertion `ctx.get_cs_eip() >>>>>> == >>>>>> >>> uop.rip' >>>>>> >>> failed. >>>>>> >>> >>>>>> >>> is a long-living bug in the current MARSS code. I believe it may >>>>>> been >>>>>> >>> linked to SMT-based configurations, but I have not had the time >>>>>> to >>>>>> >>> look >>>>>> >>> into it. If your simulated machine uses SMT, can you try >>>>>> disabling >>>>>> SMT >>>>>> >>> and >>>>>> >>> please regenerate checkpoints and try again? >>>>>> >>> >>>>>> >>> As for your second question, MARSS is definitely suited to >>>>>> giving >>>>>> your >>>>>> >>> more statistics than other options (i.e., instrumenting the >>>>>> kernel, >>>>>> >>> using >>>>>> >>> hardware/machine counters, etc.). If you need detailed, >>>>>> hardware-level >>>>>> >>> statistics relating to lock contention, you can easily >>>>>> instrument >>>>>> the >>>>>> >>> MARSS code base with some heuristics/counters that suit your >>>>>> research. >>>>>> >>> >>>>>> >>> Tyler >>>>>> >>> >>>>>> >>>> Hi, >>>>>> >>>> >>>>>> >>>> I am trying to use MARlSS for analyzing lock contention in >>>>>> >>>> multi-threaded apps and in linux OS code. I have successfully >>>>>> built >>>>>> >>>> the simulator and able to simulate the cores. Some of the >>>>>> questions I >>>>>> >>>> have are: >>>>>> >>>> >>>>>> >>>> 1) When I try to run MARSS configured with large number of >>>>>> cores(e.g >>>>>> >>>> 32), the simulation is very slow. From the discussion here >>>>>> >>>> >>>>>> >>>> "http://article.gmane.org/gmane.comp.emulators.marss86/112/match=enable+kvm"; >>>>>> >>>> I get that atleast for creating checkpoints we can use KVM >>>>>> which >>>>>> will >>>>>> >>>> be much faster. But I do not understand where should we enable >>>>>> the >>>>>> >>>> KVM? I tried the following: >>>>>> >>>> >>>>>> >>>> $ qemu/qemu-system-x86_64 -enable-kvm -m [memory_size] -hda >>>>>> >>>> [path-to-qemu-disk-image] >>>>>> >>>> >>>>>> >>>> Then in qemu monitor mode I configured the simulator as >>>>>> follows: >>>>>> >>>> simconfig -run -machine private_L2 >>>>>> >>>> >>>>>> >>>> But shortly after the simulator starts I get the following >>>>>> error: >>>>>> >>>> qemu-system-x86_64: >>>>>> ptlsim/build/core/ooo-core/ooo-pipe.cpp:2054: >>>>>> int >>>>>> >>>> ooo::ReorderBufferEntry::commit(): Assertion `ctx.get_cs_eip() >>>>>> == >>>>>> >>>> uop.rip' failed. >>>>>> >>>> >>>>>> >>>> Can someone point me what I miss here and what Avadh was >>>>>> talking >>>>>> >>>> about >>>>>> >>>> enabling KVM? >>>>>> >>>> >>>>>> >>>> 2) From the mailing list discussion >>>>>> >>>> >>>>>> >>>> (http://www.mail-archive.com/marss86-devel%40cs.binghamton.edu/msg01882.html) >>>>>> >>>> I see that MARSS runs the cores concurrently. Hence I believe >>>>>> MARSS >>>>>> >>>> can simulate the lock contentions in both application & OS code >>>>>> >>>> needed >>>>>> >>>> for my research. Kindly let me know your comments for >>>>>> confirmation. >>>>>> >>>> >>>>>> >>>> Thanks for your time, >>>>>> >>>> karthik >>>>>> >>>> >>>>>> >>>> _______________________________________________ >>>>>> >>>> http://www.marss86.org >>>>>> >>>> Marss86-Devel mailing list >>>>>> >>>> [email protected] >>>>>> >>>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >>>>>> >>>> >>>>>> >>> >>>>>> >>> >>>>>> >> >>>>>> > >>>>>> > >>>>>> >>>>>> _______________________________________________ >>>>>> http://www.marss86.org >>>>>> Marss86-Devel mailing list >>>>>> [email protected] >>>>>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >>>>> >>>>> >>> >> >> > _______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
