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 web: https://www.bobbybruce.net > 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-le...@gem5.org
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
