nathan binkert wrote: >> I'm a little squeamish about it scheduling the event right at curTick; >> there's just something "not right" about that. However, I definitely prefer >> that to the even more meaningless and arbitrary "curTick+1". Probably the >> "right" thing to do is to schedule it on the next CPU clock tick, but I can >> imagine that it could be a pain to figure out what that is down in the >> bowels of the TLB. Overall I'm OK with leaving it the way it is, I mostly >> wanted to mention that issue to see if anyone else agreed or disagreed or >> had a better idea. >> > > Scheduling for curTick is OK. Right now, we have an assertion that > you don't schedule in the past. We should probably add an assert that > says that if you're scheduling for curTick, you can't be picking a > lower priority. I'll look into doing that. Other than that, I see no > real problem with it. > > Nate > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev >
While this does avoid the segfault, it also causes some other bug which crashes just about any of the simple timing regressions. I hadn't actually tried any of the quick regressions when I sent that out since my other testing had tricked me into thinking everything was fine. I think it has something to do with faulting accesses not dealing with the fault right away and instead continuing into the remainder of completeIfetch. Rather than try to bandaid this into working, I'm thinking I'll just going to go for it and try to see what reorganizing the code buys me. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
