I have to supplement an important thing: After I changed "assert(pkt->getAddr() == tgt_pkt->getAddr()); " into "assert(pkt->getAddr() == blockAlign(tgt_pkt->getAddr()));" to pass this assert check, I got a 'SIGABRT' signal (after a while of run) and my program exits:
Program received signal SIGABRT, Aborted. I analysed this question but still feel it should not be related to my change because logically I didn't make some mistakes about my above-mentioned the address analysis of pkt and tgt_pkt. So I believe it is my change that exposes some other problem. So please help check that. Thank you so much. ------------------------------------------------------------------------------------------------ Some of the back trace are: 0x00007ffff5e7d657 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 0x00007ffff5e7ea2a in __GI_abort () at abort.c:89 0x00000000010a9eb6 in __exit_epilogue (code=-1, func=0x1da9bbe <X86ISA::PageFault::invoke(ThreadContext*, RefCountingPtr<StaticInst> const&)::__FUNCTION__> "invoke", file=0x1da99ad "build/X86/arch/x86/faults.cc", line=160, format=0x1da9a40 "Tried to %s unmapped address %#x.\n") at build/X86/base/misc.cc:94 0x0000000000d42d8f in __exit_message<char const*, unsigned long> (prefix=0x1da99ca "panic", code=-1, func=0x1da9bbe <X86ISA::PageFault::invoke(ThreadContext*, RefCountingPtr<StaticInst> const&)::__FUNCTION__> "invoke", file=0x1da99ad "build/X86/arch/x86/faults.cc", line=160, format=0x1da9a40 "Tried to %s unmapped address %#x.\n") at build/X86/base/misc.hh:81 0x0000000000d414fb in X86ISA::PageFault::invoke (this=0x3c29d70, tc=0x31ab0e0, inst=...) at build/X86/arch/x86/faults.cc:160 0x0000000000dcd3f3 in BaseSimpleCPU::advancePC (this=0x3196340, fault=...) at build/X86/cpu/simple/base.cc:532 0x0000000000dc5774 in TimingSimpleCPU::advanceInst (this=0x3196340, fault=...) at build/X86/cpu/simple/timing.cc:578 0x0000000000dc40e7 in TimingSimpleCPU::translationFault (this=0x3196340, fault=...) at build/X86/cpu/simple/timing.cc:331 0x0000000000dc4e90 in TimingSimpleCPU::finishTranslation (this=0x3196340, state=0x3c2a040) at build/X86/cpu/simple/timing.cc:497 0x0000000000dc8f39 in DataTranslation<TimingSimpleCPU*>::finish (this=0x3c29e80, fault=..., req=0x3c29cf0, tc=0x31ab0e0, mode=BaseTLB::Read) at build/X86/cpu/translation.hh:244 0x0000000000d806ab in X86ISA::TLB::translateTiming (this=0x312f380, req=0x3c29cf0, tc=0x31ab0e0, translation=0x3c29e80, mode=BaseTLB::Read) at build/X86/arch/x86/tlb.cc:429 0x0000000000dc477d in TimingSimpleCPU::readMem (this=0x3196340, addr=16, data=0x7fffffffd2c0 "", size=8, flags=4) at build/X86/cpu/simple/timing.cc:409 0x0000000001d47c5c in X86ISA::readMemTiming<ExecContext> (xc=0x31964a0, traceData=0x0, addr=16, mem=@0x7fffffffd2c0: 0, dataSize=8, flags=4) at build/X86/arch/x86/memhelpers.hh:46 0x0000000001d387a5 in X86ISAInst::LdBig::initiateAcc (this=0x3c29f70, xc=0x31964a0, traceData=0x0) at build/X86/arch/x86/generated/exec-ns.cc.inc:19231 0x0000000000dc5a86 in TimingSimpleCPU::completeIfetch (this=0x3196340, pkt=0x3c29df0) at build/X86/cpu/simple/timing.cc:619 0x0000000000dc5e89 in TimingSimpleCPU::IcachePort::ITickEvent::process (this=0x3196708) at build/X86/cpu/simple/timing.cc:666 0x0000000000ebf808 in EventQueue::serviceOne (this=0x2fc1cf0) at build/X86/sim/eventq.cc:221 ... Best On Mon, Feb 8, 2016 at 11:29 AM, Gongjin Sun <[email protected]> wrote: > Really thank you Steve, next I'll read the comment and related code again, > and hope can understand more about the working mechanism of multi-level > coherence. > > By the way, I found a possible bug again, please help verify it. (I use > se.py) > > > ----------------------------------Cache::recvTimingResp---------------------------- > > } else { > // not a cache fill, just forwarding response > // responseLatency is the latency of the return path > // from lower level cahces/memory to the core. > completion_time += clockEdge(responseLatency) + pkt->payloadDe > if (pkt->isRead() && !is_error) { > // sanity check > assert(pkt->getAddr() == tgt_pkt->getAddr()); > assert(pkt->getSize() >= tgt_pkt->getSize()); > > tgt_pkt->setData(pkt->getConstPtr<uint8_t>()); > > > ------------------------------------------------------------------------------------ > > The problematic line is : > assert(pkt->getAddr() == tgt_pkt->getAddr()); > > In the beginning I didn't get this assert failure because all my > application can't enter this "else" code. Usually gem5's default behavior > is "fill" (that is, isFill is True). > But when I modified some code and asked gem5 to not fill data in some > cache level(for example, when a ReadReq misses in L1 but hits in L2, the > returned data will be sent to CPU directly and not filled in L1), it will > enter this code branch. Now I got this assert failure. After I debugged the > process of req and resp, I found the following fact(I have a three cache > level hierarchy): > > When cpu's ReadReq arrives at L1 but misses, it will be allocated in L1 > s MSHR. In mshr entry, BLOCK address will be used. However, mshr's > target's member 'pkt' will NOT be a block aligned address necessarily. The > key thing is that then when we call getBusPacket(), we generate a new > request packet with a block aligned address: > > ------------------------------getBusPacket()------------------------------ > PacketPtr pkt = new Packet(cpu_pkt->req, cmd, blkSize); > > // the packet should be block aligned > assert(pkt->getAddr() == blockAlign(pkt->getAddr())); > > > -------------------------------------------------------------------------------- > > See, that's why when the returned resp packet arrives at L1, its > address(pkt->getAddr()) can't be equal to the target's packet's address > ('tgt_pkt->getAddr()'). > > The is just my observed things. So please help verify it. Thank you. > > Another thing, I noticed that gem5's access to cache use a physical > address. Why doesn't it use a virtual one? As I remember Virtual Index > Physical Tagged (VIPT) seems to be a common implementation. If I want to > observer the cache's access behavior by virtual address, how can I change > the configuration? I didn't find the method. (I noticed the class 'Request' > has four constructors, but only one is related to virtual address. I didn't > see too much use for this constructor with a virtual address.) > > Best regards > gjins > > On Mon, Feb 8, 2016 at 10:53 AM, Steve Reinhardt <[email protected]> wrote: > >> The O state normally is not a writable state (that's what differentiates >> it from M). The description in the wikipedia article is not very good; I >> suggest reading about MOESI from a textbook or some other source you may >> have access to. >> >> The gem5 protocol is a little unusual in how it handles states across >> different levels in a multi-level hierarchy, but that's covered in the >> comment I pointed you at previously. >> >> Steve >> >> On Sun, Feb 7, 2016 at 11:14 PM Gongjin Sun <[email protected]> wrote: >> >>> Sorry, there is a typo: "on onwer exists" should be "no owner exists". >>> >>> I think more, and still can't understand why 'O' state has a "dirty" set >>> but can't be "writable". This owner has made changes to this line, but is >>> not "writable". That sounds like a contradiction. Or did I miss something? >>> >>> Thanks >>> >>> On Sun, Feb 7, 2016 at 11:03 PM, Gongjin Sun <[email protected]> wrote: >>> >>>> Thank you, Steve. But I'm still a little confused. >>>> >>>> For the "A write hit implies that a cache has an exclusive copy". If a >>>> miss happens at all cache levels, gem5 will bring this data line from >>>> memory to L3 to L2 to L1, level by level. Now this line has three copies >>>> and its state should be shared (clean). Next if a demand write request >>>> arrives at L1, it will hit. So now how can we handle the copies in L2 and >>>> L3? We can invalidate them, or propagate this line from L1 to l2 and l3 and >>>> make its state become shared(dirty) ?? >>>> >>>> Also after I read the comments in CacheBlk::print(), I think gem5's >>>> MOESI looks like not a standard one compared with the MOESI from wikipedia: >>>> https://en.wikipedia.org/wiki/MOESI_protocol >>>> >>>> gem5's MOESI is: >>>> >>>> state writable dirty valid >>>> M 1 1 1 >>>> O 0 1 1 >>>> E 1 0 1 >>>> S 0 0 1 >>>> I 0 0 0 >>>> >>>> For a shared block, according to the explanation of wikipedia, they can >>>> be "dirty" (Here the 'dirty" is with respect to memory), We probably >>>> have several modified copies. But gem5 think they are all clean and >>>> can't be written. Does this mean on onwer exists for shared blocks? . In >>>> addition, why can't a Owned block be "writable"? It's a owner, right? >>>> >>>> I'm so confused. Hope you can help me more. Thank you so much. >>>> >>>> gjins >>>> >>>> >>>> On Sun, Feb 7, 2016 at 10:28 PM, Steve Reinhardt <[email protected]> >>>> wrote: >>>> >>>>> Upgrade requests are used on a write to a shared copy, to upgrade that >>>>> copy's state from shared (read-only) to writable. They're generally >>>>> treated >>>>> as invalidations. >>>>> >>>>> A write hit implies that a cache has an exclusive copy, so it knows >>>>> that there's no need to send invalidations to lower levels. There are >>>>> some >>>>> relevant comments on the block states in the CacheBlk::print() method >>>>> definition in src/mem/cache/blk.hh. >>>>> >>>>> Steve >>>>> >>>>> >>>>> On Sun, Feb 7, 2016 at 4:04 PM Gongjin Sun <[email protected]> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> Does any know the function of the request called "UpgradeReq"? Under >>>>>> what circumstance will this request be generated? After this request is >>>>>> sent to other cache levels, what will happen to that level? There are so >>>>>> few comments about it. Accord to its use, I guess it is related to write >>>>>> miss. But I'm not sure about the specific functions. >>>>>> >>>>>> In addition, I noticed that when a "write hit" happens in a cache >>>>>> level, this cache will NOT send an invalidate message to its lower levels >>>>>> (closer to mem) to invalidate this line's other copies. Is that correct? >>>>>> (Note: now this cache's upper level (closer to cpu) definitely doesn't >>>>>> contain this line, otherwise there must a write hit in that upper level >>>>>> rather than this cache level.) >>>>>> >>>>>> Thank you in advance >>>>>> >>>>>> Best >>>>>> gjins >>>>>> _______________________________________________ >>>>>> gem5-users mailing list >>>>>> [email protected] >>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>>> >>>>> >>>>> _______________________________________________ >>>>> gem5-users mailing list >>>>> [email protected] >>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>>> >>>> >>>> >>> _______________________________________________ >>> gem5-users mailing list >>> [email protected] >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
