Hi Eliot,

Unfortunately, I don't have a direct answer for you. However, I want to say
that I appreciate you keeping the mailing list updated with your progress!

Cheers,
Jason

On Fri, Jan 6, 2023 at 10:07 AM Eliot Moss via gem5-users <
gem5-users@gem5.org> wrote:

> 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
>
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org

Reply via email to