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
