Yes, I am aware that this is a unique problem that is caused by me running a peculiar program on my own disk. I'd like to figure out why my disk image doesn't work and then then fix my image.
I opened an issue here: https://github.com/avadhpatel/marss/issues/35 with a download link for accessing my image. Thank you all for helping me!! On Fri, Sep 6, 2013 at 3:25 PM, Brendan Fitzgerald <[email protected]>wrote: > 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
