Sorry, please ignore the above claim of non-determinism. We're still having the problem, but its deterministic.
I ran four simulations with a single command-line and they all failed at the exact same point. I may have made a mistake earlier with the script file that was passed in. Right now, my suspicion is that by calling gem5_energy_ctrl_set_performance() directly, I've missed out on some crucial clk_* logic which is causing this assertion to fail. Regards Guru On Mon, Aug 24, 2015 at 3:55 PM, Guru Prasad <[email protected]> wrote: > Some addional information on this: > It appears that this assertion error is somewhat non-deterministic. > > I ran the same command line I was running earlier, but this time inside GDB. > I'm providing the full command line with shortened paths. Some command > line options have been manually added at our end. > > (gdb) run --stdout-file=console.txt -r --outdir=gdb-1000 > configs/example/fs.py --kernel=vmlinux --disk-image=android_full.img > --sdcard=asimbench-sdcard-new.img --mem-size=512MB > --mem-type=LPDDR3_1600_x32 --caches --l2cache > --machine-type=VExpress_EMM --cpu-type=arm_detailed > --script=bbench-net.rcS --script2=blank.rcS > --command-line='custom_ip="192.168.1.2 192.168.1.1,10.0.0.2 10.0.0.1" > pa_budget=10000 new_counters=1' > --command-line2='custom_ip="192.168.1.1 192.168.1.2,10.0.0.1 > 10.0.0.2"' --os-type=android-jellybean --disk-image2=android_tiny.img > --dual -r 2 --disable-hdlcd --frame-capture > > The run hasn't completed yet, but it has crossed 64.184s (which was > the point of failure) as per the kernel kmsg timestamps. > > > On Mon, Aug 24, 2015 at 11:45 AM, Guru Prasad <[email protected]> wrote: >> I'm having the following assertion error occur in a couple of my runs: >> >> gem5.opt: build/ARM/cpu/timebuf.hh:54: void TimeBuffer<T>::valid(int) >> const [with T = DefaultIEWDefaultCommit<O3CPUImpl>]: Assertion `idx >= >> -past && idx <= future' failed. >> Program aborted at cycle 64184127758924 >> >> The only thing different that I'm doing here is that I'm calling the >> gem5-energy-ctrl driver directly without going through cpufreq. I had >> to do this since the clk interface cannot be used from an atomic >> context and we're looking to implement per-process DVFS. >> For the sake of correctness, I also tracked down all the calls to >> cpufreq_transition_notifier_list (only arch/arm/kernel/smp.c's >> cpufreq_callback) and manually added calls to those. >> >> Could someone shed some light on why this might be happening? >> I'm currently on changeset 10987:a618349a7953. >> >> >> Regards >> Guru _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
