Possible bug in cache/base.cc
Dear gem5-ers -
I've run across something, which unfortunately I cannot reliably repeat, that
suggests an oversight in the code of src/mem/cache/base.cc. In particular, it
appears that a HardPFResp can arrive where the MSHR remembered in the packet's
senderState no longer has any targets. This causes this line to fail with an
assertion error in getTarget():
const QueueEntry::Target *initial_tgt = mshr->getTarget();
Presumably some suitable conditionalization on mshr->hasTargets() could be
used to fix things, unless the problem is that somehow the target(s)
disappeared when they should not have. My suspicion is that something to do
with snooping by another cache caused the target to go away, and the situation
should just be ignored, but I did not want to attempt a fix along the lines of
testing hasTargets() without further confirmation. There is also the question
of what to do about the stats in this case, there being no obvious basis for
determining a latency. [We could change the senderState to include the time
the prefetch began, though, and use HardPFReq as the command.]
Regards - Eliot Moss
Thanks for reporting this Elliot. I’ve logged the issue here: https://github.com/gem5/gem5/issues/100.
If possible, do you know the configuration you were running that triggered this issue? If so, it would be appreciated if you could share on the GitHub Issue page.
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
On Jul 14, 2023, at 12:10 PM, Eliot Moss via gem5-users gem5-users@gem5.org wrote:
Dear gem5-ers -
I've run across something, which unfortunately I cannot reliably repeat, that
suggests an oversight in the code of src/mem/cache/base.cc. In particular, it
appears that a HardPFResp can arrive where the MSHR remembered in the packet's
senderState no longer has any targets. This causes this line to fail with an
assertion error in getTarget():
const QueueEntry::Target *initial_tgt = mshr->getTarget();
Presumably some suitable conditionalization on mshr->hasTargets() could be
used to fix things, unless the problem is that somehow the target(s)
disappeared when they should not have. My suspicion is that something to do
with snooping by another cache caused the target to go away, and the situation
should just be ignored, but I did not want to attempt a fix along the lines of
testing hasTargets() without further confirmation. There is also the question
of what to do about the stats in this case, there being no obvious basis for
determining a latency. [We could change the senderState to include the time
the prefetch began, though, and use HardPFReq as the command.]
Regards - Eliot Moss
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-leave@gem5.org