You are right. The port is being "undrained" by the table walker. Using doDrain() instead of drain() gets past this problem.
-Tony On Thu, Jul 12, 2012 at 9:14 AM, Ali Saidi <sa...@umich.edu> wrote: > ** > > On 12.07.2012 02:45, Anthony Gutierrez wrote: > > I've determined this is because drainEvent()->process() is being called > when the port has properly drained. However, once it signals that it has > drained, it gets another request. > > > > So the issue here isn't the tlb, but it's another component in the system > that either issued a request while it said it was draining or improperly > signaled it was drained. > > > > After this the l2 cpu-side port and and itb walker itself signal drained > and drain() exits. Seems there is a race condition where the dma port > drains before the other devices and it gets a request in the meantime. I > suppose I need to make sure the dma port does not accept any more requests > once it's signified that it's drained. > > That won't quite work, because a component on the other side of teh port > might need to complete a request before it can say it's drained. Really > that component needs to handle just itself. The reasoning si that no one > component can ever say it's done as there might be a request flowing > through the system somewhere. That is why drain is called multiple times. > It's perfectly acceptable for the component that was holding up the drain() > to be done and signal it's read to drain, but the only reason it's ready is > that it's handed responsibility for a request off to someone else. That is > why we call drain() successively until it comes back with 0 immediately. > > > > Ali > > > > However, none of the dma code seems to rely on the State state; of the > underlying SimObject. > > >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
