I just pulled a fresh copy and ran the simulation and had no issues. My best guess is that your issue has to do with the image you're using.
On Fri, Sep 6, 2013 at 3:01 PM, Songchun Fan <[email protected]> wrote: > Hi Tyler, > > Yes, everything is stock. The error has a little bit different behaviour > after I switched back to the master branch. Please see below. > > $ git clone git://github.com/avadhpatel/marss.git > $ cd marss > $ git show --summary > commit 49fda4a45e5b29c7e05b9e456228a4d016831484 > Merge: 6cf2d32 4ce18f7 > Author: Brendan Fitzgerald <[email protected]> > Date: Tue Aug 20 10:30:37 2013 -0700 > > Merge pull request #34 from dramninjasUMD/master > > Build # of cores string with preprocessor > > lines 1-9/9 (END) > > $ scons c=1 debug=2 > $ ./qemu/qemu-system-x86_64 -version > QEMU emulator version 0.14.1, Copyright (c) 2003-2008 Fabrice Bellard > > And the way to reproduce the issue is as follows > > (1) $ ./qemu/qemu-system-x86_64 -m 4096 -hda ../qemu-disks/android-64.img > -usbdevice mouse -usbdevice keyboard > > I am using a customized Android-x86 image (I am willing to provide the > image file if necessary). After entering the debug mode (without graphics), > here is the kernel info of this image: > > # uname -a > Linux (none) 3.0.36-android-x86-eeepc+ #1 SMP PREEMPT Tue Aug 27 21:27:01 > EDT 2013 x86_64 GNU/Linux > > (2) I want to simulate this command: > > # am start -a android.intent.action.Main -n > com.android.calculator2/.Calculator > > If there is GUI, then after this command, the Calculator app would be > launched. Without graphics, nothing will happen. So now we add start_sim > before this command and try to simulate it. > > Switch to the qemu terminal (Ctrl+Alt+2), and type > (qemu) simconfig -machine single_core > > Then switch back to the Android terminal (Ctrl+Alt+1), type > # ./start_sim ; am start -a android.intent.action.Main > -com.android.calculator2/.Calculator ; ./kill_sim > > (I compiled start_sim/kill_sim statically from the source code provided on > Marss website. ) > > (3) The simulation starts: > Switching to simulation > > And in my original terminal I can see the Completed Cycles scrolling > down... > > After a while, the simulation gets stuck and my original terminal's output > stops on this line: > ... > Completed 24021000 cycles, 1774788 commits: 54459 Hz, > 51483 > Completed 24034000 cycles, 1786064 commits: 59305 Hz, > 51441 > Completed 24045000 cycles, 1797644 commits: 51526 Hz, > 54243insns/sec: rip ffffffff81026c57 > > And then after a while qemu exits: > ... > Completed 24021000 cycles, 1774788 commits: 54459 Hz, > 51483 > Completed 24034000 cycles, 1786064 commits: 59305 Hz, > 51441 > Completed 24045000 cycles, 1797644 commits: 51526 Hz, > 54243 > qemu-system-x86_64: ptlsim/build/core/ooo-core/ooo.cpp:929: bool > ooo::OooCore::runcycle(void*): Assertion `0' failed. > Aborted > > If we look at the code ooo.cpp:929, we can see that the issue is still > caused by "the pipeline could be deadlocked" but this information was not > printed out to the terminal. > > Should I just go ahead and post the above text on to github issues ( > https://github.com/avadhpatel/marss/issues?page=1&state=open) ? > > Thanks again for your help!! > > SF > > On Fri, Sep 6, 2013 at 1:45 PM, <[email protected]> wrote: > >> If it's still occuring for qemu-0.14, GUI if off, and *everything is >> stock*, then it's an issue that I'm probably not aware of. >> >> Assuming all of the above is true and you can get the issue into a >> reproducible form, I would be grateful if you filed a bug report on github >> w/ necessary steps to reproduce. >> >> Tyler >> >> > I switched back to Qemu 0.14 and found that I am able to run my disk. >> But >> > the pipeline issue is still there. I am working on that... >> > >> > >> > On Fri, Sep 6, 2013 at 12:58 PM, <[email protected]> wrote: >> > >> >> qemu 1.2 is not fully tested and has several known issues. This is the >> >> reason that it's on a development branch and not merged into the >> master. >> >> (Generally, anything off the MARSS master branch is >> >> use-at-your-own-risk). >> >> >> >> We have plans to start supporting more recent versions of qemu, but >> have >> >> not come up with something stable yet. >> >> >> >> Tyler >> >> >> >> > Hi Tyler, >> >> > >> >> > Thank you so much for your reply. >> >> > >> >> > Indeed I am using qemu 1.2. It's because my image (an Android-x86 >> >> > customized image) can only run on qemu 1.2 not 0.14. Do you know why >> >> 1.2 >> >> > is >> >> > causing the issues? >> >> > >> >> > I am new to Marss and I really appreciate the tools you pointed to >> me. >> >> I >> >> > will come back with some new debug results later. >> >> > >> >> > Thanks again! >> >> > >> >> > SF >> >> > >> >> > >> >> > >> >> > >> >> > On Thu, Sep 5, 2013 at 11:09 PM, <[email protected]> wrote: >> >> > >> >> >> Just checking, you're using qemu 0.14, right? The 1.2 branch is >> >> causing >> >> >> the issues if you're using it. >> >> >> >> >> >> The best way to debug is to study the log. You'll likely have to >> >> refer >> >> >> to >> >> >> the PTLsim user's manual to determine what the non-standard opcodes >> >> are. >> >> >> >> >> >> The other thing that I'll sometimes do is study the rip and look at >> >> >> where >> >> >> it's getting suck in the kernel/userspace based on the rips in >> >> >> /proc/kallsyms or using the coredump. >> >> >> >> >> >> Tyler >> >> >> >> >> >> > I tried with non-GUI but it still fails. Is there any suggestion >> on >> >> >> how >> >> >> to >> >> >> > debug this sort of errors? Thanks! >> >> >> > >> >> >> > SF >> >> >> > >> >> >> > >> >> >> > On Thu, Sep 5, 2013 at 2:54 PM, Songchun Fan <[email protected]> >> >> >> wrote: >> >> >> > >> >> >> >> Hi Tyler, >> >> >> >> >> >> >> >> Thanks for your reply! >> >> >> >> >> >> >> >> I didn't changed config or source code, but I am trying to run my >> >> >> image >> >> >> >> with GUI. Would this be the problem? >> >> >> >> >> >> >> >> SF >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Sep 5, 2013 at 11:22 AM, <[email protected]> >> >> wrote: >> >> >> >> >> >> >> >>> I haven't had the single core configuration deadlock in ages. >> >> >> >>> >> >> >> >>> Have you changed either the configuration, source, etc.? >> >> >> >>> >> >> >> >>> If not, you might want to try our image and see if you can >> narrow >> >> >> the >> >> >> >>> bug >> >> >> >>> down further. >> >> >> >>> >> >> >> >>> Tyler >> >> >> >>> >> >> >> >>> > Hi Brendan, >> >> >> >>> > >> >> >> >>> > Thank you for your reply! >> >> >> >>> > >> >> >> >>> > Not sure if my previous message was delivered so I will just >> >> reply >> >> >> >>> again >> >> >> >>> > through gmail. >> >> >> >>> > >> >> >> >>> > I just used the default configuration file to compile qemu. >> >> >> >>> > >> >> >> >>> > $ scons -Q debug=2 c=1 >> >> >> >>> > >> >> >> >>> > And I ran qemu like this: >> >> >> >>> > >> >> >> >>> > $ ./qemu/qemu-system-x86_64 -m 4096 -usbdevice mouse >> -usbdevice >> >> >> >>> keyboard >> >> >> >>> > -hda disk.img >> >> >> >>> > >> >> >> >>> > And in the qemu window I typed: >> >> >> >>> > >> >> >> >>> > simconfig -machine single_core -corefreq 2G >> >> >> >>> > simconfig -loglevel 99 -logfile test4.log >> >> >> >>> > >> >> >> >>> > Thanks! >> >> >> >>> > SF >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > On Wed, Sep 4, 2013 at 11:07 AM, Brendan Fitzgerald >> >> >> >>> > <[email protected] >> >> >> >>> >> wrote: >> >> >> >>> > >> >> >> >>> >> Could you send your configuration you used for the >> simulation? >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> On Wed, Sep 4, 2013 at 10:47 AM, SF <[email protected]> >> >> wrote: >> >> >> >>> >> >> >> >> >>> >>> [Sorry for duplicate posts -- my previous one was not well >> >> >> >>> formatted.] >> >> >> >>> >>> >> >> >> >>> >>> Hello all, >> >> >> >>> >>> >> >> >> >>> >>> I encountered a problem when running an application on my >> own >> >> >> image >> >> >> >>> >>> disk, >> >> >> >>> >>> as >> >> >> >>> >>> shown below. I am just using "qemu-system-x86_64 -m 4096 >> -hda >> >> >> >>> disk.img" >> >> >> >>> >>> with >> >> >> >>> >>> "simconfig -machine single_core". >> >> >> >>> >>> >> >> >> >>> >>> 00000000f6efab7d[vcpu 0] thread 0: WARNING: At cycle >> >> 30105278, >> >> >> >>> 31826571 >> >> >> >>> >>> user >> >> >> >>> >>> commits: no instructions have committed for 1048577 cycles; >> >> the >> >> >> >>> >>> pipeline >> >> >> >>> >>> could be deadlocked >> >> >> >>> >>> qemu-system-x86_64: ptlsim/build/core/ooo-core/ooo.cpp:876: >> >> bool >> >> >> >>> >>> ooo::OooCore::runcycle(void*): Assertion `0' failed. >> >> >> >>> >>> Aborted >> >> >> >>> >>> >> >> >> >>> >>> The simulation exits after this error happens. I'd like to >> >> >> figure >> >> >> >>> out >> >> >> >>> >>> why >> >> >> >>> >>> this error is happening, and if there is any way to solve it >> >> in >> >> >> >>> order >> >> >> >>> >>> to >> >> >> >>> >>> continue my simulation. I found a few people have reported >> >> the >> >> >> same >> >> >> >>> >>> error >> >> >> >>> >>> but there didn't seem to have a clear solution. In this post >> >> >> >>> >>> (http://comments.gmane.org/gmane.comp.emulators.marss86/448 >> ), >> >> >> Avadh >> >> >> >>> >>> suggested checking the ROB entry. >> >> >> >>> >>> >> >> >> >>> >>> Here is my log file: >> http://www.cs.duke.edu/~schfan/test4.log >> >> . >> >> >> >>> >>> >> >> >> >>> >>> In my log file I found this line: >> >> >> >>> >>> >> >> >> >>> >>> rob 2 uuid 12141238 rip 0x0000f6f46b7d ready-to-load-all >> >> <at> >> >> >> all >> >> >> >>> ldd >> >> >> >>> >>> r42 >> >> >> >>> >>> tr1 ld2 = r119 <at> int r0 <at> int r0 <at> int >> >> >> >>> >>> >> >> >> >>> >>> This load operation (load the value of r129 to r42?) seems >> >> never >> >> >> >>> >>> successes >> >> >> >>> >>> because quite a few following entries show "wait for rob 2". >> >> >> >>> >>> >> >> >> >>> >>> And below LSQ (Load-store queue) I found : >> >> >> >>> >>> >> >> >> >>> >>> ld2 uuid 12141238 rob 2 r42 <at> int < Data Invalid > <at> >> >> >> >>> >>> 0x00010999ed40 >> >> >> >>> >>> >> >> >> >>> >>> And also something like this: >> >> >> >>> >>> >> >> >> >>> >>> TH 0 rfid 0 r42 state int-waiting 0xdeadbeefdeadbeef| >> rob >> >> 2 >> >> >> >>> (uuid >> >> >> >>> >>> 12141238) refcount 3 >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> My understanding is that r42 keeps waiting for data from >> >> r129, >> >> >> >>> which >> >> >> >>> >>> leads >> >> >> >>> >>> to the "deadlock". But I still don't fully understand the >> >> whole >> >> >> >>> process >> >> >> >>> >>> and >> >> >> >>> >>> I don't know what instruction inside my application is >> >> causing >> >> >> this >> >> >> >>> >>> error. >> >> >> >>> >>> >> >> >> >>> >>> Any suggestion would be appreciated! >> >> >> >>> >>> >> >> >> >>> >>> Thanks in advance! >> >> >> >>> >>> SF >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> _______________________________________________ >> >> >> >>> >>> 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 > >
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
