That does seem odd... like the dcache is sending a packet, and in the middle the bus decides to retry the cache to get it to send a second packet before it completes sending the first. Can you send a stack backtrace from somewhere in the middle (where the bus has called back to the cache)?
Steve On Sun, Sep 26, 2010 at 5:04 PM, Ali Saidi <[email protected]> wrote: > 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 > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
