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
