On 2/6/2024 11:13 AM, Nazmus Sakib via gem5-users wrote:
I think gem5 has this SplitDataRequest() method that breaks the request if it
would need more than one cacheline.
In fact, the page fault is occurring before it goes to the cache. The panic message says the address is 0x400. By
looking into the disassembly and the output log of -debug-flag=ExecAll, I think the address is an instruction address,
as I have found addresses starting with 0x400, for example :
0x400bf8 @__libc_start_main+808 : movz x1, #0,
Although, the last instruction I see in the output from ExecAll flag is a store
instruction:
0x41c0ec @_dl_debug_initialize+124 : stlr x0, [x3] : MemWrite :
D=0x0000000000492000 *A=0x498028*
Right after this, the panic message occurs.
In fact, using debug-flag=LSQUnit, I can see the message that "Fault on store
pc" which points to this store instruction.
Yes, it *can* split requests; I'm just not sure it's prepared
to do in this case.
Since you have mentioned instructions, I'm now wondering if there
could be an issue with really small instruction cache lines.
The store might be faulting because of address translation, but it
might also be faulting because of ordering constraints (it's a
store release instruction). It is 64-bit, which means it would
cross cache lines. Maybe that's disallowed for such ordering
ops?
EM
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
