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
