Hi Andreas, Based on a quick skim of the trace, I think the problem has to do with when the MSHRs are being marked in service. This should not be done until the transaction has been issued on the bus. If a snoop hits an in-service MSHR, that indicates that the MSHR request logically precedes the snoop request in the global order, but that the MSHR simply hasn't received the final response yet. Thus somehow when you have two near-simultaneous requests issued on the same bus, you have to make sure that when the winning request gets snooped by the losing MSHR, that MSHR has not yet been marked in service.
Steve On Fri, Aug 26, 2011 at 9:45 AM, Andreas Hansson <[email protected]>wrote: > Dear all, > > I am hoping that someone can help me shed some light on the expected > behaviour of the MSHR. The issue I have occurs in the "new" TLM-like version > of gem5, but seems to be closely linked with the state transitions of the > MSHRs, so hopefully someone can help me figure out what is going wrong. > > When running the tsunami-simple-timing-dual, the system hangs after only a > few hundred instructions (the other ALPHA_SE/FS tests work). The end of the > trace with Exec,Bus,Cache,CachePort flags looks as follows: > > 498000: system.cpu0 T0 : @kludge_getpcb_addr+61 : hw_mfpr > IPR(0x143),r13 : IprAccess : D=0x0000000000000000 > 498000: system.cpu0.icache: ReadReq (ifetch) 8dac hit > 498000: system.cpu1 T0 : @kludge_getpcb_addr+61 : hw_mfpr > IPR(0x143),r13 : IprAccess : D=0x0000000000000000 > 498000: system.cpu1.icache: ReadReq (ifetch) 8dac hit > 499000: system.cpu1.dcache: WriteReq 0 miss > 499000: system.cpu1.dcache: Asserting bus request for cause 0 > 499000: system.cpu0.dcache: WriteReq 0 miss > 499000: system.cpu0.dcache: Asserting bus request for cause 0 > 500000: system.toL2Bus: beginReq from slave 1 to master 0 > 500000: system.toL2Bus: beginReq from slave 3 to master 0 > 500001: system.toL2Bus_mem_master-layer: Accepting request from slave 1 to > master 0 > 500001: global: insrv 1 expsnp 0 dwnstrmpend 0 needexcl 1 hasinv 0 ispnddrt > 1 isinv 1 <-- the state of the mshr handle snoop in > cpu1.dcache > 500001: system.cpu1.dcache: Deferring snoop on in-service MSHR to blk 0 > 500001: system.l2c: mem inhibited on 0x0: not responding > 500001: system.toL2Bus: endReq from master 0 > 500001: system.cpu0.dcache: ending master request mshrs: 0 writebuffers: 0 > 503000: system.toL2Bus_mem_master-layer: Accepting request from slave 3 to > master 0 > 503000: global: insrv 1 expsnp 0 dwnstrmpend 0 needexcl 1 hasinv 0 ispnddrt > 1 isinv 1 <-- the state of the mshr handle snoop in > cpu0.dcache > 503000: system.cpu0.dcache: Deferring snoop on in-service MSHR to blk 0 > 503000: system.l2c: mem inhibited on 0x0: not responding > 503000: system.toL2Bus: endReq from master 0 > 503000: system.cpu1.dcache: ending master request mshrs:0 writebuffers: 0 > > Both CPUs have a write miss to address 0x0, followed by two requests being > sent to the toL2Bus. The first one (from cpu0) is snooped in cpu1.dcache and > the conclusions is that it is in service, needs exclusive, is pending dirty, > and is invalidate. After this request releases the bus, the second one > continues (from cpu1) and is snooped in the cpu0.dcache, with _exactly the > same results as the first one_. Surely this must be wrong? I am tempted to > believe it has something to do with the updating of the packet flags, but > would very much appreciate to know what flags to expect for the first and > second packet. > > Thanks in advance. > > Best regards, > > Andreas > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
