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
