Good catch... unfortunately I don't see an easy answer. I believe that inside the markInService function, the MSHR code is looking at some of the snoop status bits (see http://repo.m5sim.org/gem5/file/353abb676fa2/src/mem/cache/mshr.cc#l224), which are set by snoopers after sendTiming() is called. Thus both setting the data the code is looking at and deleting the packet happens after the call to sendTIming() but before the return.
The only solutions I see are to either (1) change the allocation protocol that says the target can delete the packet or (2) somehow separate the snoop status bits from the packet so they can have a different lifetime. Either of these would be a pretty major change. Can we find a way to incorporate a fix into Andreas's new port interface? Since we already have a pretty major overhaul in sight, maybe the best solution might be to live with this for now (assuming it empirically isn't causing any actual problems) and just make sure we take care of it then. Steve On Tue, Aug 2, 2011 at 8:03 AM, Ali Saidi <[email protected]> wrote: > I can't really come up with a solution I like to this problem. If I don't > delete the packet in the down stream cache and put a hack in to delete it in > the upstream cache that seems like a hack and violates the principle that > the recipient is responsible for the packet. I could copy the packet in the > sending cache and feed that into the markInService function, but I don't > like that either. > Suggestions? > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
