Hey guys, I was trying to help Rodrigo (cc'd) to debug a system hang that he is experiencing (http://comments.gmane.org/gmane.comp.emulators.m5.users/14424), but the bug appears to be pretty complicated. I wanted to report it on the dev list so we're aware of it. I've also submitted the bug report below to Flyspray (http://flyspray.gem5.org/index.php?do=details&task_id=7&project=3 ).
The basic problem is that, after collecting a checkpoint in x86 full-system mode with the classic memory model, restoring from the checkpoint into the O3 CPU results in the system hanging. This appears to behave much like the bug that Nilay and I have seen previously in which two interrupts arrive at the same CPU local APIC device, and the lower priority interrupt gets dropped. We've put a temporary fix in place for that bug, but this new one appears to be very similar in the symptoms. Unfortunately, I have not been able to establish if it is the same issue, because in the new case, both CPU cores drop into IRQ spin-wait loops and the simulation grinds along painfully slowly. Based on the simulation speed, I estimate that to see if Linux will catch the dropped interrupt will require at least 3 weeks worth of simulation time, so the best way to approach this would probably be to get my hands dirty with the x86 interrupts device/O3 commit implementation again to put in a check whether/when multiple interrupts arrive. I've found that an older gem5 revision, 9603, appears to work around the bug as a stopgap, but I'm wondering if anyone has ideas for what might be causing the bug or any suspect changes since then. Thanks, Joel --------------------- Bug Report --------------------- Symptoms: After checkpoint restore: - Terminal output (system.pc.com_1.terminal) hangs while printing the way that is expected in the benchmark - Executing system appears to hang and not make progress - LocalApic trace shows that activity halts after terminal stops printing - Exec trace shows both cores fall into spin lock loop (_spin_lock_irqsave) Checkpoints collected with: 2 core, atomic or timing CPU, x86, full-system, classic memory model, any cache organizations Affected simulation modes: 2 core, O3 CPU, x86, full-system, classic memory model, any cache organizations Affected changesets: 9606, 9623, 9703 Changeset 9603 does NOT witness this bug (though it may still exist) To reproduce: 1) Use one of the changesets listed above 2) Build x86 simulator: scons build/X86/gem5.opt 3) Download x86_64-vmlinux-2.6.28.4-smp, found here: http://www.cs.utexas.edu/~parsec_m5/x86_64-vmlinux-2.6.28.4-smp 4) Setup to use disk image found here: http://www.cs.utexas.edu/~parsec_m5/x86root-parsec.img.bz2 5) Use configs/example/fs.py to take a checkpoint after boot using configs/boot/hack_back_ckpt.rcS: ./build/X86/gem5.opt ./configs/example/fs.py --kernel x86_64-vmlinux-2.6.28.4-smp --script=./configs/boot/hack_back_ckpt.rcS -n 2 6) Restore into O3 CPU and run a benchmark using --script: ./build/X86/gem5.opt ./configs/example/fs.py --kernel x86_64-vmlinux-2.6.28.4-smp --script=./configs/boot/<<your_favorite_parsec_bmark>>.rcS -n 2 --cpu-type=detailed --caches -r 1 -- Joel Hestness PhD Student, Computer Architecture Dept. of Computer Science, University of Wisconsin - Madison http://pages.cs.wisc.edu/~hestness/ _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
