Thanks the patch does fix the bug I was seeing.
On Mon, Feb 25, 2013 at 2:49 PM, Ali Saidi <[email protected]> wrote: > Hi Gedare, > > > > The right place is bugs is http://flyspray.gem5.org however this bug should > be fixed with this patch: http://reviews.gem5.org/r/1741/ > > > > Ali > > > > On 25.02.2013 14:20, Gedare Bloom wrote: > > Hi, > > Is this the right place to submit bug reports? > > When I restore with the detailed cpu after booting X86 Linux > (2.6.28.4) and checkpointing, gem5 is aborting. I have reproduced this > issue using the gem5 tip, and with the pre-packaged > x86_64-vmlinux-2.6.22.9. > > I was able to checkpoint and restore in detailed mode with ARM using > vmlinux.arm.smp.fb.2.6.38.8 and linux-arm-ael.img. > > $ build/X86/gem5.debug --debug-flags=Drain configs/example/fs.py -r 1 > --restore-with-cpu=detailed >debug.txt > warn: add_child('terminal'): child 'terminal' already has parent > Listening for com_1 connection on port 3456 > warn: Reading current count from inactive timer. > 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 > hack: be nice to actually delete the event here > ... > gem5.debug: build/X86/cpu/o3/fetch_impl.hh:432: void > DefaultFetch<Impl>::drainSanityCheck() const [with Impl = O3CPUImpl]: > Assertion `!memReq[i]' failed. > Program aborted at cycle 17350227428500 > > > The output from Drain flags: > Switched CPUS @ tick 17346781476000 > switching cpus > 17346781476000: system.physmem: DRAM controller not drained, write: 0, > read: 0, resp: 1 > 17346781476000: system.cpu: Draining... > 17346781476000: system.cpu: Fetch not drained. > 17346781476000: system.cpu: CPU not drained > info: Entering event queue @ 17346781476000. Starting simulation... > 17346781476500: system.cpu: Fetch not drained. > 17346781477000: system.cpu: Fetch not drained. > 17346781477500: system.cpu: Fetch not drained. > 17346781478000: system.cpu: Fetch not drained. > 17346781478500: system.cpu: Fetch not drained. > .... 5.9 million lines later > 17350227427000: system.cpu: Main CPU structures not drained. > 17350227427000: system.cpu: Fetch not drained. > 17350227427000: system.cpu: Commit not drained. > 17350227427500: system.cpu: Main CPU structures not drained. > 17350227427500: system.cpu: Fetch not drained. > 17350227427500: system.cpu: Commit not drained. > 17350227428000: system.cpu.commit: Draining: > 0:(0xffffffff8020bd20=> > 0xffffffff8020bd28).(0=>1) > 17350227428000: system.cpu.fetch: 0: Thread drained. > 17350227428000: system.cpu: Fetch not drained. > 17350227428500: system.cpu: CPU done draining, processing drain event > 17350227428500: system.membus.reqLayer: Bus not drained > 17350227428500: system.membus.respLayer: Bus not drained > 17350227428500: system.physmem: DRAM controller not drained, write: 5, > read: 0, resp: 2 > 17350227428500: system.cpu: Draining... > 17350227428500: system.cpu: CPU is already drained > > That is where gem5 aborts. Any advice or workaround would be appreciated. > > -Gedare > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
