On 19 Aug 2016, at 17:45, Rodolfo Guilherme Wottrich wrote:
Hi Rodolfo,
how did you solve this (code wise). I am trying to hunt down an
undelivered Page Fault on x86 FS and another problem only showing up as
I add more caches (e.g., a L2) and I am just curious about all kinds of
x86 problems other people see and their code changes to fix things.
Thanks,
Bjoern
For future reference: my problem was not that subsequent instructions
would
not squash. I missed out on the fact that the store queue's behaviour
is
asynchronous and although the instructions had been committed many
cycles
before, the requests would still be in the store queue to be consumed
by
the cache. It was only a matter of forcefully removing the stores for
the
LSQ and it worked.
---
Rodolfo Wottrich
On Mon, Aug 15, 2016 at 5:24 PM, Rodolfo Guilherme Wottrich <
[email protected]> wrote:
Hi Fernando,
Thank you for the suggestion. Yes, I have tried that, but the problem
is
that no similar faults take happen, especially in SE mode.
I wonder if it may be the case of some squashing function call that I
am
missing.
Does anybody have experience with squashing instructions in the
commit
stage?
---
Rodolfo Wottrich
On Mon, Aug 8, 2016 at 10:08 AM, Fernando Endo
<[email protected]>
wrote:
Hello,
Probably I can't technically help you here, but have you considered
observing the simulator behavior when similar faults happen? For
example,
simulate a program that access an invalid address and enable all
related
debug flags to track it (--debug-flags option).
Hope it helps,
--
Fernando A. Endo, Post-doc
INRIA Rennes-Bretagne Atlantique
France
2016-08-03 3:30 GMT+02:00 Rodolfo Guilherme Wottrich
<[email protected]>:
Hello,
I would like to request some assistance if possible. For my PhD
work, I
need to be able to trigger a CPU fault when a particular condition
in
the
L1 cache controller is met. I am using an o3 x86 CPU and Ruby in SE
mode.
I have come to a partial solution to the problem, based on a patch
I
found
which dealt with a similar situation. That involves creating a new
Sequencer callback function that is used only at that specific
situation in
the cache controller which triggers a sequence of actions that
eventually
lead to a Fault object being instantiated in the LSQ and in the
commit
stage of the pipeline.
The problem is that although the Fault and its handling are
"working"
(control flow changes and registers are updated as they should),
subsequent
requests still keep being received by the cache in the mandatory
queue
from
the instructions following the offending one. Those instructions
should
have been cancelled as in a branch misprediction and their requests
should
have been removed from the LSQ to avoid inconsistency.
Can anybody think of why I am having such a problem/how can I solve
it?
I
can provide specifics once the discussion starts.
Thank you in advance.
Cheers,
---
Rodolfo Wottrich
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
