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

Reply via email to