As the error message suggest you seem to have a packet that spans a cache
line boundary. Have you checked the address and/or size to make sure they
all are within a cache line?
Andreas
On 26/02/2015 21:15, "Sensen Hu - EWI via gem5-dev"
wrote:
>hi, Andreas.
>I've tried to set Maxtick more than
hi, Andreas.
I've tried to set Maxtick more than 16000. But in the command window, it shows
Aborted (core dumped).
And the simerr file shows:
gem5.opt: build/ARM/mem/cache/cache_impl.hh:164: void
Cache::satisfyCpuSideRequest(PacketPtr, Cache::BlkType*,
bool, bool) [with TagStore = LRU; PacketP
We're running into a failing drive on zizzer, which is causing these
errors. Fortunately we have a replacement machine in place, but we're
still in the process of moving everything over.
I manually ran the full regressions on the new machine and got these
non-pass results:
* build/X86/tests/o
changeset 4206946d60fe in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=4206946d60fe
description:
Ruby: Update backing store option to propagate through to all RubyPorts
Previously, the user would have to manually set
access_backing_store=True
on all R
scons: ***
[build/ALPHA_MOESI_CMP_directory/python/m5/internal/param_ProbeListenerObject.py.fo]
Error 1
scons: ***
[build/ALPHA_MOESI_CMP_directory/python/m5/internal/param_ProbeListenerObject.py.o]
Error 1
* build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-timing
passed.
Could it not be as simple as back pressure?
The traffic generator can only send requests as fast as the port (crossbar
in this case), can accept them.
I suspect if you set the max time to some larger value it is all fine.
Andreas
On 26/02/2015 08:04, "Sensen Hu - EWI via gem5-dev"
wrote:
>tha
thanks, Erfan.
I see. But my TraceGen can't still traverse the whole tgen-simple-mem.trc file,
while it only executes the first 4 instructions. Then it stops. I check the
following simout file, shows that:
Global frequency set at 1 ticks per second
info: Entering event queue @ 0. St
