I'd theorize it's a bug... Because a CPU can be Idle because it is switched out waiting for a memory access to complete. So "Idle" does not equate to "Drained" and should not immediately return anything signifying it's drained.
Your other bugs seem to stem from something else and you'll have to be more specific to which particular event is being scheduled in the past for us to help. A GDB backtrace should be able to show you which line of code is calling something to be scheduled incorrectly. There may be things that aren't reinitialized correctly when you switch to another core, causing some type of bad scheduling effect. On Wed, Mar 30, 2011 at 4:38 PM, Anthony Gutierrez <[email protected]> wrote: > One thing I don't understand is why the drain function returns 0 if the cpu > _status is Idle. It seems as though it is idle but there are still > instructions in the ROB, lsq, mem dep unit etc., which is why I'm seeing > errors. If I get rid of the check in the drain function I don't see these > errors anymore and can switch out, at least once. When I try to repeat I'm > still getting other assertion failures, events being scheduled in the past. > So is there a reason why the drain function returns 0 if Idle? Or is that a > bug? > > -Tony > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > -- - Korey _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
