If you can include a link to the image so I can reproduce the image and just copy/paste the link + that description into the GitHub issue link you provided, that would be great!
Thanks! Tyler > 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
