Hi Ali and Steve, after patching the Rev. 37c56be05af0, the error is gone! I had checked the variables which Steve mentioned. But everything looks fine until a non-related memory write caused this problem.
thanks, Dave. System on Chip Design Lab. Dept. of Computer Science and Information Engineering, National Chung Cheng University E-mail : [email protected] On Mon, Sep 27, 2010 at 10:32 AM, Steve Reinhardt <[email protected]> wrote: > The pkt->finishTime value is set in Bus::calcPacketTiming(). What we > really need to do to track this bug down is to figure out what happens > in Bus::calcPacketTiming() that causes it to set pkt->finishTime to > such an unreasonable value. One of the variables that contribute to > that calculation (pkt->dataSize, bus->clock, bus->width, ??) is > probably wrong, but we can't get much farther without knowing which > one. > > I'm skeptical that the NULL value is related... it's possible, but I > wouldn't spend too much time pursuing that angle without further > evidence. > > Steve > > On Sun, Sep 26, 2010 at 4:46 PM, Dave <[email protected]> wrote: > > Thanks for your reply, > > I tried to use gdb to step the M5 and found the situation that occupied > bus > > from tick 16000 to 4831955816 > > 16000: system.toL2bus: recvTiming: src 4 dst 0 WriteResp 0xc5ff8 > > Breakpoint 2, TimingSimpleCPU::completeDataAccess (this=0x8714b00, > > pkt=0x880eca0) at build/ALPHA_SE/cpu/simple/timing.cc:743 > > 743 advanceInst(fault); > > 4: curTick = 16000 > > 3: pkt->finishTime = 17000 > > <<-----------------------------------------------Here is fine! > > (gdb) n > > 16000: system.cpu0.icache: ReadReq 1cb68 hit > > 744 } > > 4: curTick = 16000 > > 3: pkt->finishTime = 4831955816 > > <<----------------------------------------weird > > (gdb) > > I$ hit takes too much time! > > I dig into the completeDataAccess and found the value change time of > > pkt->finishTime is after advanceInst(fault); called. > > Finally, a NULL copy occurs! the Ref counting ptr r is a NULL value... > > RefCountingPtr (this=0xbfffe494, r=...) at > build/ALPHA_SE/base/refcnt.hh:80 > > 80 RefCountingPtr(const RefCountingPtr &r) { copy(r.data); } > > when returning from the advanceInst(), the pkt->finishTime = 4831955816. > > Because I can find any relationship between RefCountingPtr > > and pkt->finishTime. I doubt that maybe some memory rewrite problem. But > I'm > > not sure. > > BTW, I'm curious about the relationship between curTick > and pkt->finishTime. > > Is it possible a pkt->finishTime smaller than curTick? or curTick should > > always larger than pkt->finishTime? > > Tahnks, > > Dave > > > > System on Chip Design Lab. > > Dept. of Computer Science and Information Engineering, > > National Chung Cheng University > > E-mail : [email protected] > > > > > > On Sun, Sep 26, 2010 at 7:13 AM, Steve Reinhardt <[email protected]> > wrote: > >> > >> First off, thanks for the detailed and thorough description of what > >> you've done and what the problem is. > >> > >> I don't see anything fundamentally wrong with what you're doing, but > >> since it is unusual, it's not too surprising you may be running into > >> some issues. > >> > >> The assignment to cpu.dcache isn't setting a param, it's attaching a > >> child to the cpu object (see > >> > >> > http://m5sim.org/wiki/index.php/Simulation_Scripts_Explained#The_configuration_hierarchy > ). > >> So not having that assignment is fine since you don't have a dcache. > >> > >> The suspicious line is this one: > >> > 16000: system.toL2bus: The bus is now occupied from tick 16000 to > >> > 4831955816 > >> Somehow in the code in src/mem/bus.cc that decides how long a packet > >> is going to occupy the bus, something is going very wrong. I suggest > >> stepping through this in gdb (use --debug-break to stop at cycle > >> 16000, then set a breakpoint in Bus::calcPacketTiming()). > >> > >> Steve > >> _______________________________________________ > >> 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
