It's possible that this could be because of some memory management bugs that I
posted a diff for a few days ago. You might want to apply the patch on review
board and see if that fixes your issue or run it through valgrind.
Ali
On Sep 26, 2010, at 6:46 PM, Dave 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
