On 1/4/2023 11:51 PM, Eliot Moss via gem5-users wrote:
So, what I have found is that the bad micro-op is coming from trying to execute the micro-ops of an
INT3 macro-instruction. The end of the sequence consists of the micro-ops:
andi t0, t5, 0x1
br 0x803d
br 0x80b8
followed by a bunch of "panic" micro-ops. t5 holds an m5 register,
where the low bit supposedly indicated whether we are in long mode.
The br micro-ops branch into long sequences of micro-ops in the "ROM".
I have found out some more things about this issue.
- The macro instruction is INT_I (my mistake in saying INT3), but the
micro-ops are almost exactly the same.
- My original though about a load instruction *is* connected somehow. Here's
the big-picture sequence of events:
1) A garden flavor load from memory (mov reg <- offset(reg)) gets stuck at
the head of the ROB. It was originally deferred because a page table walk
was necessary to resolve the virtual address of the load.
2) The ROB fills (all 192) entries.
3) The panic happens.
So I tried adjusting the size of the ROB, just to see what would happen. When
I increased it from 192 to 500, a panic still happened. I guess that if an
instruction remains stuck at the head of the ROB forever, the ROB fills and
then somehow causes the panic.
When I *decreased* the ROB size from 192 to 64, the program worked.
I am inclined to infer that there is (was) a bug in the O3 interactions that
would make the load micro-op fully ready and not stuck at the head of the
ROB.
What I wonder is whether any similar ROB lock-up behavior has been found and
fixed since 21.0.0.0. There have been a lot of textual changes, but many had
to do with names and such and did not really change what the code *does*. I
am hoping someone out there can confirm one way or another whether this may
have been found and fixed already if I can manage to move the rest of my
changes forward to a newer release.
Best - Eliot
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org