I'm going to push my latest InOrder changes as soon as I can. With those, I was able to boot Linux successfully so I'd be interested if your error still occurs w/ those changes.
In the interim, to debug I would suggest: - figuring out what cycle the simulation breaks using a traceflag "InOrderCPU" (?) - grab trace output for about ~50-100 cycles before the bad pointer. - using the trace output figure out what instruction is causing the bad TLB access. - then with that info, trace to see if it is an instruction that is prematurely squashed but still accesses the cache (deallocated early). I would think that's the likely problem. Also, if you are interested in doing some additional testing w/the newer patches (offline), send me a email and we can discuss how to do that. I'm caught between a few things that is delaying those patches from being committed now, but I think those would likely help. On Sun, May 15, 2011 at 5:46 PM, reena panda <[email protected]> wrote: > Hi Gabe, > > It seems to me too that the problem is with the null request pointer. > Actually, The request pointer is generated in the cache_unit.cc file in the > inorder model files and the request pointer is passed on to the TLB > functions (translateAtomic and translateData) for translation.. But as I > wrote in my previous email too, the conditional assert statement that I am > putting there to check if memory was allocated or not for the request, is > not being satisfied, which is confusing me. There are no intermediate > function calls also. How else do I check if memory was allocated for this > request properly or not? Any suggestions how I can track it further? > > /inorder/resources/cache_unit.cc :: setupMemRequest function { > > if (inst->dataMemReq == NULL) { > inst->dataMemReq = new Request(cpu->asid[tid], aligned_addr, > acc_size, flags, > inst->instAddr(), cpu->readCpuId(), > tid); > * if(inst->dataMemReq == NULL) > assert(0);* > > cache_req->memReq = inst->dataMemReq; <= This is the request > pointer, pointing to 0x0. > > Thanks, > Reena > > On Sun, May 15, 2011 at 4:19 PM, Gabe Black <[email protected]> wrote: > >> Yeah, I'm pretty sure a request pointer being 0 is your problem. You can >> see in the stack trace that getVaddr is being called which gets some data >> out of the flags member. Since the request is at 0, the flags are at 0x18, >> and when that tries to check whether one of the flags is set by reading it's >> data, it does an illegal access. It looks like doTLBAccess is calling >> translateAtomic with a NULL request pointer which it got from somewhere. >> > > > Program received signal SIGSEGV, Segmentation fault. > 0x0000000000431f87 in Flags<unsigned char>::isSet (this=0x18, flags=4 > '\004') > at build/ALPHA_SE/base/flags.hh: > 63 > 63 bool isSet(Type flags) const { return (_flags & flags); } > (gdb) bt > #0 0x0000000000431f87 in Flags<unsigned char>::isSet (this=0x18, > flags=4 '\004') at build/ALPHA_SE/base/flags.hh:63 > #1 0x00000000004626d5 in Request::getVaddr (this=0x0) > at build/ALPHA_SE/mem/request.hh:368 > #2 0x000000000090c067 in AlphaISA::TLB::translateData (this=0x1710400, > *req=0x0*, tc=0x1923a90, write=false) at > build/ALPHA_SE/arch/alpha/tlb.cc:452 > #3 0x000000000090d1b5 in AlphaISA::TLB::translateAtomic (this=0x1710400, > *req=0x0*, tc=0x1923a90, mode=BaseTLB::Read) > at build/ALPHA_SE/arch/alpha/tlb.cc:587 > *#4 0x000000000073a88c in CacheUnit::doTLBAccess (this=0x17268c0, > inst=..., > cache_req=0x1bfe390, acc_size=8, flags=0, tlb_mode=BaseTLB::Read) > at build/ALPHA_SE/cpu/inorder/**resources/cache_unit.cc:431* > #5 0x000000000073d07b in CacheUnit::read (this=0x17268c0, inst=..., > addr=4831386496, data=0x7fffffff9a80 "", size=8, flags=0) > at build/ALPHA_SE/cpu/inorder/resources/cache_unit.cc:548 > #6 0x00000000007d38f7 in InOrderCPU::read (this=0x172a160, inst=..., > addr=4831386496, data=0x7fffffff9a80 "", size=8, flags=0) > at build/ALPHA_SE/cpu/inorder/cpu.cc:1787 > #7 0x00000000006d1b11 in InOrderDynInst::readBytes (this=0x26c3250, > addr=4831386496, data=0x7fffffff9a80 "", size=8, flags=0) > at build/ALPHA_SE/cpu/inorder/inorder_dyn_inst.cc:517 > #8 0x00000000006d3795 in RefCountingPtr<FaultBase> > InOrderDynInst::read<unsigned long>(unsigned long, unsigned long&, unsigned > int) () > > >> >> Gabe >> >> >> On 05/15/11 11:16, reena panda wrote: >> >> Hi Nilay, >> Thanks for your reply. I have made some changes to the code, but not to >> this part. I will remove my modifications and see if I am still running into >> the issue. >> >> The gdb trace also hints that req = 0x0 in translateData and >> translateAtomic functions. Can that be the problem? I am doubtful because if >> I put a check in setupMemRequest function in inorder/resources/cache_unit.cc >> file, it does not confirm the issue, i.e., if I include a check there, the >> assert condition does not hit before the program gets a seg fault. So, I am >> not sure if I am running into memory issues here. >> >> if (inst->dataMemReq == NULL) { >> inst->dataMemReq = new Request(cpu->asid[tid], >> aligned_addr, acc_size, flags, >> >> inst->instAddr(), cpu->readCpuId(), >> tid); >> * if(inst->dataMemReq == NULL) >> assert(0);* >> >> cache_req->memReq = inst->dataMemReq; >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x0000000000431f87 in Flags<unsigned char>::isSet (this=0x18, flags=4 >> '\004') >> at build/ALPHA_SE/base/flags.hh: >> 63 >> 63 bool isSet(Type flags) const { return (_flags & flags); } >> (gdb) bt >> #0 0x0000000000431f87 in Flags<unsigned char>::isSet (this=0x18, >> flags=4 '\004') at build/ALPHA_SE/base/flags.hh:63 >> #1 0x00000000004626d5 in Request::getVaddr (this=0x0) >> at build/ALPHA_SE/mem/request.hh:368 >> #2 0x000000000090c067 in AlphaISA::TLB::translateData (this=0x1710400, >> *req=0x0*, tc=0x1923a90, write=false) at >> build/ALPHA_SE/arch/alpha/tlb.cc:452 >> #3 0x000000000090d1b5 in AlphaISA::TLB::translateAtomic (this=0x1710400, >> *req=0x0*, tc=0x1923a90, mode=BaseTLB::Read) >> at build/ALPHA_SE/arch/alpha/tlb.cc:587 >> #4 0x000000000073a88c in CacheUnit::doTLBAccess (this=0x17268c0, >> inst=..., >> cache_req=0x1bfe390, acc_size=8, flags=0, tlb_mode=BaseTLB::Read) >> at build/ALPHA_SE/cpu/inorder/resources/cache_unit.cc:431 >> #5 0x000000000073d07b in CacheUnit::read (this=0x17268c0, inst=..., >> addr=4831386496, data=0x7fffffff9a80 "", size=8, flags=0) >> at build/ALPHA_SE/cpu/inorder/resources/cache_unit.cc:548 >> #6 0x00000000007d38f7 in InOrderCPU::read (this=0x172a160, inst=..., >> addr=4831386496, data=0x7fffffff9a80 "", size=8, flags=0) >> at build/ALPHA_SE/cpu/inorder/cpu.cc:1787 >> #7 0x00000000006d1b11 in InOrderDynInst::readBytes (this=0x26c3250, >> addr=4831386496, data=0x7fffffff9a80 "", size=8, flags=0) >> at build/ALPHA_SE/cpu/inorder/inorder_dyn_inst.cc:517 >> #8 0x00000000006d3795 in RefCountingPtr<FaultBase> >> InOrderDynInst::read<unsigned long>(unsigned long, unsigned long&, unsigned >> int) () >> >> Thanks, >> Reena >> >> On Sun, May 15, 2011 at 12:08 AM, reena panda <[email protected]>wrote: >> >>> Just an addition. The benchmark runs fine till 50 million instructions, >>> this segmentation fault happens when I try to run the benchmark for more >>> number of instructions(by using maxinsts option). Can anybody give some >>> help? >>> >>> Thanks, >>> Reena >>> >>> >>> On Sat, May 14, 2011 at 11:41 PM, reena panda <[email protected]>wrote: >>> >>>> Hi, >>>> I am running m5 in ALPHA SE mode for inorder CPU model. I am getting a >>>> segmentation fault in the data translation section in tlb.cc file, when I >>>> am >>>> running for the SPEC2k6 mcf benchmark. I have not made any modifications >>>> to >>>> this part of the code. So, could anybody help me figure out the cause of >>>> the >>>> issue? >>>> >>>> Following is the gdb trace of the fault:- It shows that the fault is >>>> occuring when a translation is attempted in translatedata function in >>>> arch/tlb.cc file. The flag value returning from the isSet function is set >>>> at >>>> "4" => the Vaddr is valid (as per the mem/request.hh file). What might be >>>> causing this issue? >>>> >>>> Program received signal SIGSEGV, Segmentation fault. >>>> 0x0000000000431f87 in Flags<unsigned char>::isSet (this=0x18, *flags=4 >>>> '\004')* >>>> at build/ALPHA_SE/base/flags.hh:63 >>>> 63 bool isSet(Type flags) const { return (_flags & flags); } >>>> (gdb) bt >>>> #0 0x0000000000431f87 in Flags<unsigned char>::isSet (this=0x18, >>>> flags=4 '\004') at build/ALPHA_SE/base/flags.hh:63 >>>> #1 0x00000000004626d5 in Request::getVaddr (this=0x0) >>>> at build/ALPHA_SE/mem/request.hh:368 >>>> #2 0x000000000090c067 in AlphaISA::TLB::translateData (this=0x1710400, >>>> req=0x0, tc=0x1923a90, write=false) at >>>> build/ALPHA_SE/arch/alpha/tlb.cc:452 >>>> #3 0x000000000090d1b5 in AlphaISA::TLB::translateAtomic >>>> (this=0x1710400, >>>> req=0x0, tc=0x1923a90, mode=BaseTLB::Read) >>>> at build/ALPHA_SE/arch/alpha/tlb.cc:587 >>>> #4 0x000000000073a88c in CacheUnit::doTLBAccess (this=0x17268c0, >>>> inst=..., >>>> cache_req=0x1bfe390, acc_size=8, flags=0, tlb_mode=BaseTLB::Read) >>>> at build/ALPHA_SE/cpu/inorder/resources/cache_unit.cc:431 >>>> #5 0x000000000073d07b in CacheUnit::read (this=0x17268c0, inst=..., >>>> addr=4831386496, data=0x7fffffff9a80 "", size=8, flags=0) >>>> at build/ALPHA_SE/cpu/inorder/resources/cache_unit.cc:548 >>>> #6 0x00000000007d38f7 in InOrderCPU::read (this=0x172a160, inst=..., >>>> addr=4831386496, data=0x7fffffff9a80 "", size=8, flags=0) >>>> at build/ALPHA_SE/cpu/inorder/cpu.cc:1787 >>>> #7 0x00000000006d1b11 in InOrderDynInst::readBytes (this=0x26c3250, >>>> addr=4831386496, data=0x7fffffff9a80 "", size=8, flags=0) >>>> at build/ALPHA_SE/cpu/inorder/inorder_dyn_inst.cc:517 >>>> #8 0x00000000006d3795 in RefCountingPtr<FaultBase> >>>> InOrderDynInst::read<unsigned long>(unsigned long, unsigned long&, unsigned >>>> int) () >>>> >>>> Thanks, >>>> Reena >>>> >>>> >>> >> >> _______________________________________________ >> m5-users mailing list >> [email protected]http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> >> >> >> _______________________________________________ >> m5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > -- - Korey
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
