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
