This is what happens (I've added a lot of dprintfs)... The cache port sends a packet: 507847507000: system.cpu.dcache-mem_side_port: sendPacket() called 507847507000: system.cpu.dcache-mem_side_port: -- defered Packet Ready:1 507847507000: system.cpu.dcache-mem_side_port: --sending packet
This part I don't get. The bus receives the packet and probes the cache that made the request? Either way an sendEvent gets scheduled here for the future. 507847507000: system.membus: recvTiming: src 6 dst 8 ReadResp 0x73631e4 507847507000: system.cpu.dcache: ReadReq 79d2000 miss 507847507000: system.cpu.dcache-mem_side_port: Asserting bus request for cause 0 507847507000: system.cpu.dcache-mem_side_port: sendEvent being scheduled @ 507847508000 507847507000: system.membus: The bus is now occupied from tick 507847507000 to 507847509000 Now sendTiming returns success, so the cache port says that was done, and waitingOnRetry is false (although the sendTiming scheduled an event). 507847507000: system.cpu.dcache-mem_side_port: --sendTiming returned 1 507847507000: system.cpu.dcache-mem_side_port: sendPacket(): WaitingOnRetry:0 Now the cache port attempts to schedule the next packet, since there isn't a retry pending 507847507000: system.cpu.dcache-mem_side_port: --sendEvent.scheduled=1 sendEvent.when=507847508000 507847507000: system.cpu.dcache-mem_side_port: --more packets to send @ 507847508000 At this point the sendEvent is scheduled but it's already been scheduled above, so we assert. Any ideas? Ali On Sep 24, 2010, at 4:34 PM, Steve Reinhardt wrote: > Can you provide some more information on where you're seeing this? > One simple case where it would happen is if there are actually > multiple instances of the cache that are doing this on the same > tick... > > Steve > > On Wed, Sep 22, 2010 at 4:10 PM, Ali Saidi <[email protected]> wrote: >> Anyone ever seen a case where >> schedule(sendEvent, std::max(nextReady, curTick + 1)); >> is called multiple times in cache_impl.hh? >> >> I haven't quite been able to track what is going on. Any ideas how this >> could happen Steve? >> Thanks, >> Ali >> >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
