> On Jan. 24, 2013, 9:14 a.m., Andreas Sandberg wrote: > > What's the point of the avoidQuiesceLiveLock flag? Is there anything > > preventing us from doing a squashAfter whenever there is an interrupt > > pending and interrupts are turned on again? > > Ali Saidi wrote: > You will be throwing away perfectly good instructions that could be > committed.
Isn't this a very uncommon situation or am I missing something? Another question I have is how this affects x86. IIRC, the original patch broke (not just timing) some test cases on x86. Have you made sure that the x86 test cases pass even without the avoidQuiesceLiveLock flag? I suspect that, if there is a bug, that might be hidden by the flag. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1660/#review3895 ----------------------------------------------------------- On Jan. 22, 2013, 1:49 p.m., Ali Saidi wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1660/ > ----------------------------------------------------------- > > (Updated Jan. 22, 2013, 1:49 p.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9513:86c772cdcb3e > --------------------------- > cpu: Fix a livelock in the o3 cpu. > > Check if an instruction just enabled interrupts and we've previously had an > interrupt pending that was not handled because interrupts were subsequently > disabled before the pipeline reached a place to handle the interrupt. In that > case squash now to make sure the interrupt is handled. > > > Diffs > ----- > > src/cpu/o3/commit.hh f9e76b1eb79a > src/cpu/o3/commit_impl.hh f9e76b1eb79a > > Diff: http://reviews.gem5.org/r/1660/diff/ > > > Testing > ------- > > > Thanks, > > Ali Saidi > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
