See the list of debug flags here:
https://gem5.googlesource.com/public/gem5/+/master/src/mem/ruby/SConscript

Also, running "gem5 --debug-help" will list all of the debug flags.

There's no way to know what flags will be most helpful. You should play
around with them to find out.

Finally, I'm not sure if you've seen it or not, but I have a chapter in
Learning gem5 that covers debugging Ruby:
http://learning.gem5.org/book/part3/MSI/debugging.html

Jason

On Fri, Feb 16, 2018 at 4:59 AM SHARJEEL KHILJI <
[email protected]> wrote:

> 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 <[email protected]>
> 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 <
>> [email protected]> 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
>>> [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

Reply via email to