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
