Hi Jason, Can you tell me about more debug flags other than ProtocolTrace that can be used to trace the addresses in caches.
regards, Muhammad On 14 February 2018 at 22:05, Jason Lowe-Power <ja...@lowepower.com> wrote: > Hi Muhammad, > > Unfortunately, debugging these kinds of issues is *incredibly* difficult. > Especially when they only occur during full system execution. > > I would try grepping for the address that is deadlocking and starting by > tracing the address from where it originally issued through the cache > hierarchy to find where it is deadlocking. > > Other than that, I can't help much. > > Good luck finding the problem! > > Jason > > > > On Tue, Feb 13, 2018 at 7:24 AM SHARJEEL KHILJI < > sharjeelsaeedkhi...@gmail.com> wrote: > >> >> Hi Jason, >> >> Last email was incomplete sorry for that. >> >> I am running following system, >> >> ./build/ARM/gem5.debug --debug-flags ProtocolTrace >> configs/example/fs.py --l1d_size=32kB --l1i_size=32kB --num-l2caches 4 >> --l2_size=1MB --cacheline_size=64 --machine-type=VExpress_GEM5_V1 >> --kernel /home/khilji/gem5/m5/system/binaries/vmlinux-aarch32 >> --disk-image /home/khilji/gem5/m5/system/disks/arm-ubuntu-natty-headless.img >> --dtb-filename /home/khilji/gem5/m5/system/dtb/armv7_gem5_v1_4cpu.dtb >> --num-cpus 4 --cpu-type ex5_big --ruby --num-dirs=4 --network=garnet2.0 >> --topology Mesh_XY --mesh-rows 2 --mem-size 1G >> >> I am facing following problem, >> >> panic: Possible Deadlock detected. Aborting! version: 3 request.paddr: >> 0x801578d8 m_readRequestTable: 1 current time: 3244524422000 issue_time: >> 3244269289000 difference: 255133000 >> >> Memory Usage: 1581920 Kbytes >> >> This was in the gem5.fast simulation and when I repeated it in the debug >> with ProtocolTrace on I got following results >> >> 547724013000 0 L1Cache Ifetch >> S>S [0x80243000, line >> 0x80243000] >> >> 547724013500 0 Directory DMA_READ M_DRDI>M_DRDI >> [0xbf040000, line 0xbf040000] >> >> 547724014000 0 Seq Begin > >> [0x80243010, line 0x80243000] >> IFETCH >> >> 547724014500 0 Seq Done > >> [0x80243010, >> line 0x80243000] 1 cycles >> >> 547724014500 0 L1Cache Ifetch S>S >> [0x80243000, line 0x80243000] >> >> 547724015500 0 Seq Begin > >> [0x80243020, line >> 0x80243000] IFETCH >> >> 547724016000 0 Seq Done > >> [0x80243020, line >> 0x80243000] 1 cycles >> >> 547724016000 0 L1Cache Ifetch S>S >> [0x80243000, line 0x80243000] >> >> 547724018000 1 DMA Data BUSY_RD>READY >> [0xbf040000, line 0xbf040000] >> >> 547724018500 0 Directory DMA_READ M_DRDI>M_DRDI >> [0xbf040000, line 0xbf040000] >> >> gem5.debug: build/ARM/mem/ruby/network/MessageBuffer.cc:220: Tick >> MessageBuffer::dequeue(Tick, bool): Assertion `isReady(current_time)' >> failed. >> >> Program aborted at tick 547724021000 >> >> The directory controller does many DMA reads but after the read at tick >> 547724018500 the assertion in message buffer of network fails. >> >> I am using MESI_Two_Level protocol and this protocol did not support >> multiple DMA controllers. I have added the support for the multiple DMA >> controllers in this protocol. If that is the issue. I am facing this issue >> with ex5_big and DerivO3CPU. Simulation with TimingSimpleCPU is fine. >> Kindly, if you can suggest any thing in this issue. Thanks! >> >> best regards, >> >> Muhammad >> >> >> >> _______________________________________________ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
