I think you are on the right path. I draw similar conclusion from the debug trace.
My guess is your writeback pkt stuck in the write buffer although it has been sent to L2 cache. You may want to track your writeback packet in the write buffer, check if it is correctly moved forward in the readyList and has been markInService properly. Check if it has been erased from the ready list and not block the buffer. On Tue, Apr 19, 2016 at 12:24 AM, Chunweiguan <[email protected]> wrote: > Hi, Mr Wang, > Thanks for your help! I'm so sorry that I didn't describe my question > clearly. Actually, I can receive the response of the request that I send to > L2 cache. I will describe my question more clearly below. > > First, I add special master id to global master id list so that I can > trace the request that I send out. Then I insert schedReq() function into > Cache::CpuSidePort::recvTimingReq(PacketPtr pkt) to build user-defined > requests under special condition. > Second, I build the user-defined read request in schedReq() function, > using MemCmd::ReadReq, target addr A, special master id and other config. > Then I call Cache::CpuSidePort::recvTimingReq(PacketPtr pkt) to send the > new read request to L2 cache through the cpu side port(I have some code to > avoid recurrence relation). > Third, I override the Cache::CpuSidePort::schedTimingResp(PacketPtr pkt, > Tick when) function so that I can get the response of the request that has > special master id. Then I copy the data in the response packet to a new > request packet, which the request packet build with MemCmd::Writeback(don't > need response), target addr B(different from A) and so on. After that, I > send the new write request to Cache::CpuSidePort::recvTimingReq(PacketPtr > pkt) and delete the old read response to avoid it being send to upper level > cache. > > The words I said before "it works at beginning" means I do receive the > response of the user-defined read request, and send the new write request > to L2 cache successfully, the debug trace is shown below: > 954816875: system.l2: Handling response ReadResp for addr 0x617d40 > size 64 (ns) > 954816875: system.l2: Block for addr 0x617d40 being updated in Cache > 954816875: system.l2: replacement: replacing 0x5d7d40 (ns) with > 0x617d40 (ns): clean > 954816875: system.l2: Block addr 0x617d40 (ns) moving from state 0 to > state: 7 (E) valid: 1 writable: 1 readable: 1 dirty: 0 tag: c2 > 954816875: system.l2: access for Writeback addr 0x22aa03d40 size 64 > 954816875: system.l2: Writeback addr 0x22aa03d40 size 64 (ns) miss > 954816875: system.l2: replacement: replacing 0x22a303d40 (ns) with > 0x22aa03d40 (ns): writeback > 954816875: system.l2: access new state is state: d (O) valid: 1 > writable: 0 readable: 1 dirty: 1 tag: 45540 > 954816875: system.l2: Leaving recvTimingResp with ReadResp for addr > 0x617d40 > the *0x617d40 *is addr A and the *0x22aa03d40 *is add B. So I think the > system is running as I expect at this point. But soon the system prints > nothing new when I use --debug-flags=Cache, and when I change to use > --debug-flags=DRAM, it just prints endless: > 26356456250: system.mem_ctrls2_0: All banks already precharged, > starting refresh > 26356456250: system.mem_ctrls3_0: Refresh due > I think it's mean that dram is working normally and the cache may be > blocked or have dead locks. Yesterday, I check the trace info carefully and > find something interesting: > 954823750: system.cpu.dcache: Blocking for cause 1, mask=2 > It shows that dcache is blocked because its write buffer is full and I > can't find unblock info after that. So I guess is this the reason why cache > stops working? But I haven't injected other requests into the dcache. Or > because the user-defined requests' data occupy the cache line, so that the > dcache write buffer cann't evict data to L2 cache?But > 954816875: system.l2: replacement: replacing 0x22a303d40 (ns) with > 0x22aa03d40 (ns): writeback > shows that user-defined requests' data can be replaced, now I have no idea > again...If you have solution or suggestions, please help me! Thank you very > much, Mr Wang! > > Best wishes, > Chunweiguan > > > >Date: Sun, 17 Apr 2016 12:36:17 -0400 > >From: Yipeng Wang <[email protected]> > >To: gem5 users mailing list <[email protected]> > >Subject: Re: [gem5-users] How to inject user-defined data request into > > shared cache system > >Message-ID: > > <CAJDUSqpNfzUpsP4O2B6v=+Xg7ncknn=uwpdfg2prz4str69...@mail.gmail.com> > >Content-Type: text/plain; charset="utf-8" > > > >Hi, > > > >You may want to show more details about your issue. As my understanding, > >you sent some your own request to cache but got no response. I think the > >most possible reason is that you did not create your user-defined read > >request properly, so that the request does not follow the normal path in > >the cache. > > > > Also, what do you mean that it works at beginning? Do you mean the > >simulation stop working or your own defined request stop working any more > >after some time? Since you use your own defined request, my suggestion is > >not only depending on the gem5's own debug-flags, but also try to insert > >your own printfs or debug flags to trace the cause of the issue. > > > > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > -- yw
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
