>From looking at the fetch and commit code, commit should only start processing the interrupt after the pipeline has drained itself completely. Fetch as it is currently implemented will stop issuing instructions when it reaches an instruction 'boundary' as Ali has said thus allowing the interrupt to be serviced as the pipe will drain.
Either x86's ISA description is not fully correct in defining non-interruptible micro-code sequences, --or--, we may be seeing a race condition where fetch stalls while issuing micro-ops (something to do with fetching from the ROM? I don't understand how x86 works at all) that can't be interrupted and the rob drains in the meantime causing commit to start squashing in preparation for the interrupt when it shouldn't. Geoff On Wed, Jul 6, 2011 at 8:58 AM, Ali Saidi <[email protected]> wrote: > Geoff can comment as well, but my guess here is that fetch doesn't > understand what an instruction boundary is in x86 possible while > instructions are coming out of the micro-code rom. There is a check in fetch > that keeps issuing instructions have it receives an interrupt until it > reaches a delayedCommit instruction and which point it stops. If this same > check wasn't properly implemented for the micro-code fetch part that could > be the issue. > > Ali > > > > On Jul 6, 2011, at 5:28 AM, Gabe Black wrote: > > > I've tracked down the next problem in O3 to an interrupt happening > > almost (but not quite) at the end of an instruction. The microop the > > interrupt is after has the delayedCommit bit set on it, but commit > > doesn't check that at all before it recognizes an interrupt. It relies > > on fetch, although I don't really understand how that would work. Geoff > > Blake committed a changeset which touched that code, so hopefully he can > > explain? Please :-) > > > > I modified commit to keep track of whether or not the last committed > > instruction had delayedCommit set and to delay interrupts, and while > > that seemed to work in the sense that the simulation got farther, > > something was out of whack and instructions accumulated somewhere until > > they exceeded a threshold and O3 died. If you (Geoff?) want to try it > > for yourself, I can send you a series of patches (most already out for > > review) that will let you get to the point of failure. > > > > Without actually knowing exactly what's not working properly, I can't > > think of any reason this wouldn't affect ARM as well. I guess x86 is > > just a lot more microcoded and either happened on the right combination > > of circumstances or just the wrong spot so that the problem caused a > crash. > > > > Gabe > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > > > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
