Hi all,
an update for the issue.
I tried to debug the issue, with debug-flags enabled and I assume that
it is a raising condition. dcache has already started the invalidation,
while there is a pending miss request.
See the log output bellow:
5940212878500: system.cpu.dcache: access for WriteReq
[16945940:16945947] hit state: 5 (S) valid: 1 writable: 0 readable: 1
dirty: 0 | tag: 0x16945 set: 0x25 way: 0
5940212878500: system.cpu.dcache.mem_side: Scheduling send event at
5940212879500
5940212879500: system.cpu.dcache: sendMSHRQueuePacket: MSHR WriteReq
[16945940:16945947]
5940212879500: system.cpu.dcache: createMissPacket: created UpgradeReq
[16945940:1694597f] from WriteReq [16945940:16945947]
5940212879500: system.cpu.dtb_walker_cache: recvTimingSnoopReq: for
UpgradeReq [16945940:1694597f]
5940212879500: system.cpu.dtb_walker_cache: handleSnoop: for UpgradeReq
[16945940:1694597f]
5940212879500: system.cpu.dtb_walker_cache: handleSnoop: snoop hit for
UpgradeReq [16945940:1694597f], old state is state: 5 (S) valid: 1
writable: 0 readable: 1 dirty: 0 | tag: 0xb4a2c set: 0x5 way: 0
5940212879500: system.cpu.dtb_walker_cache: new state is state: 0 (I)
valid: 0 writable: 0 readable: 0 dirty: 0 | tag: 0xffffffffffffffff set:
0x5 way: 0
5940212879500: system.l2: access for UpgradeReq [16945940:1694597f] hit
state: 7 (E) valid: 1 writable: 1 readable: 1 dirty: 0 | tag: 0x2d28
set: 0x165 way: 0x7
/*
/ --->INVALIDATING DCACHE BLOCKS<---
/ dcache.memWriteback();
/ dcache.memInvalidate();
*/
5940212880500: system.cpu.icache: functionalAccess: WriteReq
[1fb9c000:1fb9c03f]
5940212880500: system.cpu.itb_walker_cache: functionalAccess: WriteReq
[1fb9c000:1fb9c03f]
5940212880500: system.cpu.dtb_walker_cache: functionalAccess: WriteReq
[1fb9c000:1fb9c03f]
5940212880500: system.l2: functionalAccess: WriteReq [1fb9c000:1fb9c03f]
valid
5940212880500: system.iocache: functionalAccess: WriteReq
[1fb9c000:1fb9c03f]
.
.
5940212880500: system.cpu.icache: functionalAccess: WriteReq
[16a7efc0:16a7efff]
5940212880500: system.cpu.itb_walker_cache: functionalAccess: WriteReq
[16a7efc0:16a7efff]
5940212880500: system.cpu.dtb_walker_cache: functionalAccess: WriteReq
[16a7efc0:16a7efff]
5940212880500: system.l2: functionalAccess: WriteReq [16a7efc0:16a7efff]
valid
5940212880500: system.iocache: functionalAccess: WriteReq
[16a7efc0:16a7efff]
5940212891500: system.cpu.dcache: recvTimingResp: Handling response
UpgradeResp [16945940:1694597f]
5940212891500: system.cpu.dcache: Block for addr 0x16945940 being
updated in Cache
gem5.opt: build/X86/mem/cache/base.cc:1379: CacheBlk*
BaseCache::handleFill(PacketPtr, CacheBlk*, PacketList&, bool):
Assertion `pkt->hasData() || pkt->cmd == MemCmd::InvalidateResp' failed.
Program aborted at tick 5940212891500
As it is depicted dcache received the TimingResponse for address
0x16945940, but the invalidation has been started.
I would like to ask if there is a way to overpass this situation,
probably before the cache invalidation we need to check if there are
pending request?
Moreover, one more question regarding the Snooprequests, that I see on
dtb_walker_cache, I am simulating a uni-core system? So I am expecting
that the snoop mechanism should be disabled, is that right?
Best regards,
Michail
Στις 2020-06-25 01:00, Michail Mavropoulos via gem5-users έγραψε:
An update, regarding the tests I performed.
I used to run the following command:
./build/X86/gem5.opt -d out_dir --stats-file=stats.stat
configs/example/fs.py --checkpoint-dir=cpt_dir/spec2006
--checkpoint-restore=5 --caches --l2cache --maxinsts=7000000
--warmup-insts=1000000 --standard-switch=1000000
kernel=kernel_dir/x86_64-vmlinux-2.6.22.9
--disk-image=disk_dir/ubuntu-14.04.img ;
I also tried the --restore-with-cpu options with
TimingSimpleCPU/DerivO3CPU/NonCachingSimpleCPU but the issue persist.
Moreover I tried to run the simulation without warmup otpion, again
the assertion was triggered.
The only case, where the simulation completed succesfully was with the
TraceCPU option. Simulation over elastic traces.
./build/X86/gem5.opt -d my_out --stats-file=stats.stat
configs/example/etrace_replay.py --cpu-type=TraceCPU --caches
--l2cache
--inst-trace-file=$el_tr_dir/system.switch_cpus.traceListener.fetchtrace.proto.gz
--data-trace-file=$el_tr_dir/system.switch_cpus.traceListener.deptrace.proto.gz;
Note that the assertion triggered only in some benchmarks from
SPEC2006 suite, and only in dcache test scenario.
Is there any idea how can I overpass the issue on full system
emulation?
Cheers,
Michail
Στις 2020-06-22 20:41, Michail Mavropoulos via gem5-users έγραψε:
Hello all,
I am facing an assertion when I try to flush the dcache periodically,
using a sheduling timing event.
I have set up a recurring timing event, and on the handler of this
event I try to flush the dcache or icache.
For the icache scenario I just call the base.cc::memInvalidate(), see
https://gem5.googlesource.com/public/gem5/+/96fce476785a834f102ae69a895e661cf08e47cd/src/mem/cache/base.cc#1585,
while for dcache case first I call the writeback (see:
https://gem5.googlesource.com/public/gem5/+/96fce476785a834f102ae69a895e661cf08e47cd/src/mem/cache/base.cc#1579)
and then the cache invalidation.
I have observed that for the dcache scenario the following assertion
get triggered, see
https://gem5.googlesource.com/public/gem5/+/96fce476785a834f102ae69a895e661cf08e47cd/src/mem/cache/base.cc#1322.
Am I doing something wrong during the dl1 cache flushing procedure?
Kind regards,
Michail
_______________________________________________
gem5-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________
gem5-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________
gem5-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
