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
