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
