Since the problem seems to be related to the faulty load instruction being
re-executed before the faulty version is committed, is it safe to skip load
execution if the instruction has ReExec fault and its Executed flag is set
and manually resetting the Executed flag once the faulty instruction is
completed?
This is roughly what I had in mind. I am not very familiar with the flow of
instructions through the pipeline on the O3 implementation. so I would
appreciate if you could give some feedback on whether this is safe to
implement or not.
DefaultIEW<Impl>::executeInsts()
{
.
.
.
.
} else if (inst->isLoad()) {
// Added check
if ((dynamic_cast<ReExec*>(inst->fault.get()) != nullptr)
&& (inst->isExecuted()))
{
if (inst->isCompleted())
inst->clearExecuted();
continue;
}
// End of added check
.
.
.
.
}
I am having better luck with this modification but Ruby (MOESI_hammer)
still sometimes runs into deadlock
On Mon, Sep 16, 2019 at 2:52 PM Shehab Elsayed <shehaby...@gmail.com> wrote:
> I ran some more tests and it doesn't always break at the same instruction (
> MOV_R_M). However, what seems to be common is that the instruction
> causing the problem (let's call it instruction A) conflicts with another
> instruction in the 'checkSnoop' function in 'src/cpu/o3/lsq_unit_impl.hh'.
> Therefore, 'A' ends up being faulty with ReExec and consequently marked
> as executed and sent to commit but never actually gets to commit before
> being executed again.
>
> What I understood from the comments in this function is that offending
> instructions should be squashed (since I amusing X86 which sets needsTSO
> to True and consequently force_squash to True as well). But looks like
> the Instructions are not squashed as far as I can tell.
>
> I am not sure if this helps narrow down the problem or not but I hope it
> helps!
>
>
> On Thu, Sep 12, 2019 at 2:52 PM Shehab Elsayed <shehaby...@gmail.com>
> wrote:
>
>> Looks like this is the instruction causing the assertion failure
>>
>> MOV_R_M : ld r9, DS:[rdx + 0x10]
>>
>>
>>
>> On Wed, Sep 11, 2019 at 5:20 PM Pouya Fotouhi <pfoto...@ucdavis.edu>
>> wrote:
>>
>>> If you use --debug-flags=ExecAll,Decode and narrow down your trace to
>>> the Ticks that you know the load is failing with --debug-start and
>>> --debug-end you should be able to get that.
>>>
>>> Best,
>>>
>>> On Wed, Sep 11, 2019 at 2:15 PM Shehab Elsayed <shehaby...@gmail.com>
>>> wrote:
>>>
>>>> Is there a way to get the macroop from the corresponding instruction
>>>> pointer?
>>>>
>>>>
>>>> On Wed, Sep 11, 2019 at 5:07 PM Pouya Fotouhi <pfoto...@ucdavis.edu>
>>>> wrote:
>>>>
>>>>> Hi Shehab,
>>>>>
>>>>> Can you please confirm what is the macroop that is issuing that load?
>>>>> I suspect it's one of the 128-bit instructions (maybe recently
>>>>> non-temporal
>>>>> ones that I added) that are executed as two 64-bit loads, and possibly the
>>>>> second one is failing due to the cda check that we do, and that stops the
>>>>> load from being committed.
>>>>>
>>>>> Best,
>>>>>
>>>>> On Wed, Sep 11, 2019 at 1:16 PM Shehab Elsayed <shehaby...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> So actually load instruction gets executed twice causing the
>>>>>> assertion to fail on the second time.
>>>>>>
>>>>>> 7694139490000: system.switch_cpus.iew.lsq.thread0: Doing memory
>>>>>> access for inst [sn:15059405] PC
>>>>>> (0xffffffff810ed626=>0xffffffff810ed62a).(1=>2)
>>>>>> 7694139490000: system.switch_cpus.iew.lsq.thread0: Load [sn:15059405]
>>>>>> not executed from fault
>>>>>> 7694139490000: system.switch_cpus.iew.lsq.thread0: 1- Setting
>>>>>> [sn:15059405] as executed (I added this message to track when LSQ
>>>>>> instructions are set as executed)
>>>>>>
>>>>>> I believe this instruction should then be committed and removed from
>>>>>> the LSQ before before executed again, however, this does not happen.
>>>>>> Instead it gets executed again before being removed and then comes the
>>>>>> assertion failure that it has already executed.
>>>>>>
>>>>>> I see that it gets sent to commit
>>>>>>
>>>>>> 7694139490000: system.switch_cpus.iew: Sending instructions to
>>>>>> commit, [sn:15059405] PC (0xffffffff810ed626=>0xffffffff810ed62a).(1=>2).
>>>>>>
>>>>>> but it never actually gets to commit and removed from LSQ.
>>>>>>
>>>>>>
>>>>>> On Mon, Sep 9, 2019 at 3:01 PM Pouya Fotouhi <pfoto...@ucdavis.edu>
>>>>>> wrote:
>>>>>>
>>>>>>> You can try dumping Exec trace for the last few million ticks and
>>>>>>> see what is going on in your LSQ and why you have load instruction that
>>>>>>> is
>>>>>>> not executed.
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> On Mon, Sep 9, 2019 at 11:28 AM Shehab Elsayed <shehaby...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I am not sure that prefetch_nta is the problem. For different runs
>>>>>>>> the simulation would fail after different periods after printing the
>>>>>>>> prefetch_nta warning message. Also, from what I have seen in
>>>>>>>> different posts it seems that this warning has been around for a while.
>>>>>>>>
>>>>>>>> I tried compiling my hello world program with -march=athlon64 alone
>>>>>>>> and together with -O0 and the the same problem happens.
>>>>>>>>
>>>>>>>> Also, the I am building my benchmark on the disk image directly
>>>>>>>> using qemu and the gcc on the image is versio 5.4.0
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Sep 8, 2019 at 4:14 PM Pouya Fotouhi <pfoto...@ucdavis.edu>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Shehab,
>>>>>>>>>
>>>>>>>>> Good, that's "progress"!
>>>>>>>>> My guess off the top of my head is that you used a "more recent"
>>>>>>>>> compiler (compared to what other gem5 users tend to use), and thus
>>>>>>>>> some
>>>>>>>>> instructions are being generated that were not critical to the
>>>>>>>>> execution of
>>>>>>>>> applications other users had so far (and that's mostly why those
>>>>>>>>> instructions are not yet implemented). I think you have two options:
>>>>>>>>>
>>>>>>>>> 1. You can try implementing prefetch_nta, and possibly ignore
>>>>>>>>> the non-temporal hint (i.e. implement it as a cacheable prefetch).
>>>>>>>>> You can
>>>>>>>>> start by looking at the implementation of other prefetch
>>>>>>>>> instruction we
>>>>>>>>> have in gem5 (basically you can do the same :) ).
>>>>>>>>> 2. Try compiling your application (I think we are still
>>>>>>>>> talking about the hello world, right?), and target an older
>>>>>>>>> architecture
>>>>>>>>> (you can do as extreme as march=athlon64) with less optimizations
>>>>>>>>> involved
>>>>>>>>> to avoid these performance-optimizations (reducing cache pollution
>>>>>>>>> in this
>>>>>>>>> particular case) that your compiler is trying to apply.
>>>>>>>>>
>>>>>>>>> My suggestion is to go with the first one, since running real
>>>>>>>>> applications compiled for an older architecture with less
>>>>>>>>> optimization on a
>>>>>>>>> "newer" system is the equivalent of not using "parts/features" of your
>>>>>>>>> system (e.g. SIMD units, direct prefetch, etc), which would (possibly)
>>>>>>>>> directly impact any study you are working on.
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>>
>>>>>>>>> On Sat, Sep 7, 2019 at 8:27 PM Shehab Elsayed <
>>>>>>>>> shehaby...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> I am sorry for the late update. I tried running with
>>>>>>>>>> MESI_Two_Level but the simulation ends with this error.
>>>>>>>>>>
>>>>>>>>>> warn: instruction 'prefetch_nta' unimplemented
>>>>>>>>>>
>>>>>>>>>> gem5.opt: build/X86_MESI_Two_Level/cpu/o3/lsq_unit.hh:621: Fault
>>>>>>>>>> LSQUnit<Impl>::read(LSQUnit<Impl>::LSQRequest*, int) [with Impl =
>>>>>>>>>> O3CPUImpl; Fault = std::shared_ptr<FaultBase>;
>>>>>>>>>> LSQUnit<Impl>::LSQRequest = L
>>>>>>>>>> SQ<O3CPUImpl>::LSQRequest]: Assertion `!load_inst->isExecuted()'
>>>>>>>>>> failed.
>>>>>>>>>>
>>>>>>>>>> Which I believe has something to do with a recent update since I
>>>>>>>>>> don't remember seeing it before. And this error happens even for
>>>>>>>>>> just 2
>>>>>>>>>> cores and 2 threads.
>>>>>>>>>>
>>>>>>>>>> On Fri, Sep 6, 2019 at 3:16 PM Pouya Fotouhi <
>>>>>>>>>> pfoto...@ucdavis.edu> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Shehab,
>>>>>>>>>>>
>>>>>>>>>>> As Jason pointed out, I won’t be surprised if you are having
>>>>>>>>>>> issues with classic caches running workloads that rely on locking
>>>>>>>>>>> mechanisms. Your pthread implementation is possibly using some
>>>>>>>>>>> synchronization variables which requires cache coherence to
>>>>>>>>>>> maintain its
>>>>>>>>>>> correctness, and classic caches (at least for now) doesn’t support
>>>>>>>>>>> that.
>>>>>>>>>>>
>>>>>>>>>>> Switch to ruby caches (I suggest MESI Two Level to begin with),
>>>>>>>>>>> and given your kernel version you should be getting stable behavior
>>>>>>>>>>> from
>>>>>>>>>>> gem5.
>>>>>>>>>>>
>>>>>>>>>>> Best,
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Sep 6, 2019 at 11:47 AM Jason Lowe-Power <
>>>>>>>>>>> ja...@lowepower.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Shehab,
>>>>>>>>>>>>
>>>>>>>>>>>> IIRC, there are some issues when using classic caches + x86 +
>>>>>>>>>>>> multiple cores on full system mode. I suggest using Ruby
>>>>>>>>>>>> (MESI_two_level or
>>>>>>>>>>>> MOESI_hammer) for FS simulations.
>>>>>>>>>>>>
>>>>>>>>>>>> Jason
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Sep 6, 2019 at 11:24 AM Shehab Elsayed <
>>>>>>>>>>>> shehaby...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> My latest experiments are with the classical memory system,
>>>>>>>>>>>>> but I remember trying Ruby and it was not different. I am using
>>>>>>>>>>>>> kernel
>>>>>>>>>>>>> 4.8.13 and ubuntu-16.04.1-server-amd64 disk image. I am using
>>>>>>>>>>>>> Pthreads for
>>>>>>>>>>>>> my Hello World program.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Sep 6, 2019 at 1:13 PM Pouya Fotouhi <
>>>>>>>>>>>>> pfoto...@ucdavis.edu> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Shehab,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Can you confirm a few details about the configuration you are
>>>>>>>>>>>>>> using? Are you using classic caches or Ruby? What is the kernel
>>>>>>>>>>>>>> version and
>>>>>>>>>>>>>> disk image you are using? What is the implementation of your
>>>>>>>>>>>>>> "multithreaded
>>>>>>>>>>>>>> hello world" (are you using OMP)?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Sep 6, 2019 at 8:58 AM Shehab Elsayed <
>>>>>>>>>>>>>> shehaby...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> First of all, thanks for your replies, Ryan and Jason.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have already pulled the latest changes by Pouya and the
>>>>>>>>>>>>>>> problem still persists.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As for checkpointing, I was originally doing exactly what
>>>>>>>>>>>>>>> Jason mentioned and ran into the same problem. I then switched
>>>>>>>>>>>>>>> to not
>>>>>>>>>>>>>>> checkpointing just to avoid any problems that might be
>>>>>>>>>>>>>>> caused by checkpointing (if any). My plan was to go back to
>>>>>>>>>>>>>>> checkpointing after proving that it works without it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> However, the problem doesn't seem to be related to KVM as
>>>>>>>>>>>>>>> linux boots reliable every time. The problem happens after
>>>>>>>>>>>>>>> the benchmarks starts execution and it seems to be happening
>>>>>>>>>>>>>>> only when
>>>>>>>>>>>>>>> running multiple cores (>=4). My latest experiments with a
>>>>>>>>>>>>>>> single core and
>>>>>>>>>>>>>>> 8 threads for the benchmark seem to be working fine. But once I
>>>>>>>>>>>>>>> increase
>>>>>>>>>>>>>>> the number of simulated cores problems happen.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Also, I have posted a link to the repo I am using to run my
>>>>>>>>>>>>>>> tests in a previous message. I have also added 2 debug traces
>>>>>>>>>>>>>>> with the Exec
>>>>>>>>>>>>>>> flag for a working and non-working examples.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Sep 6, 2019 at 11:28 AM Jason Lowe-Power <
>>>>>>>>>>>>>>> ja...@lowepower.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi Shehab,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> One quick note: There is *no way* to have deterministic
>>>>>>>>>>>>>>>> behavior when running with KVM. Since you are using the
>>>>>>>>>>>>>>>> hardware, the
>>>>>>>>>>>>>>>> underlying host OS will influence the execution path of the
>>>>>>>>>>>>>>>> workload.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> To try to narrow down the bug you're seeing, you can try to
>>>>>>>>>>>>>>>> take a checkpoint after booting with KVM. Then, the execution
>>>>>>>>>>>>>>>> from the
>>>>>>>>>>>>>>>> checkpoint should be deterministic since it is 100% in gem5.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> BTW, I doubt you can run the KVM CPU in a VM since this
>>>>>>>>>>>>>>>> would require your hardware and the VM to support nested
>>>>>>>>>>>>>>>> virtualization.
>>>>>>>>>>>>>>>> There *is* support for this in the Linux kernel, but I don't
>>>>>>>>>>>>>>>> think it's
>>>>>>>>>>>>>>>> been widely deployed outside of specific cloud environments.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> One other note: Pouya has pushed some changes which
>>>>>>>>>>>>>>>> implement some x86 instructions that were causing issues for
>>>>>>>>>>>>>>>> him. You can
>>>>>>>>>>>>>>>> try with the current gem5 mainline to see if that helps.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>> Jason
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, Sep 6, 2019 at 8:22 AM Shehab Elsayed <
>>>>>>>>>>>>>>>> shehaby...@gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That's interesting. Are you using Full System as well? I
>>>>>>>>>>>>>>>>> don't think FS behavior is supposed to be so dependent on the
>>>>>>>>>>>>>>>>> host
>>>>>>>>>>>>>>>>> environment!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Fri, Sep 6, 2019 at 11:16 AM Gambord, Ryan <
>>>>>>>>>>>>>>>>> gambo...@oregonstate.edu> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I have found that gem5 behavior is sensitive to the
>>>>>>>>>>>>>>>>>> execution environment. I now run gem5 inside an ubuntu vm on
>>>>>>>>>>>>>>>>>> qemu and have
>>>>>>>>>>>>>>>>>> had much more consistent results. I haven't tried running
>>>>>>>>>>>>>>>>>> kvm gem5 inside a
>>>>>>>>>>>>>>>>>> kvm qemu vm, so not sure how that works, but might be worth
>>>>>>>>>>>>>>>>>> trying.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Ryan
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Fri, Sep 6, 2019, 08:07 Shehab Elsayed <
>>>>>>>>>>>>>>>>>> shehaby...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I was wondering if anyone is running into the same
>>>>>>>>>>>>>>>>>>> problem or if anyone has any suggestions on how to proceed
>>>>>>>>>>>>>>>>>>> with debugging
>>>>>>>>>>>>>>>>>>> this problem.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Mon, Jul 29, 2019 at 4:57 PM Shehab Elsayed <
>>>>>>>>>>>>>>>>>>> shehaby...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Sorry for the spam. I just forgot to mention that the
>>>>>>>>>>>>>>>>>>>> system configuration I am using is mainly from
>>>>>>>>>>>>>>>>>>>> https://github.com/darchr/gem5/tree/jason/kvm-testing/configs/myconfigs.
>>>>>>>>>>>>>>>>>>>> <https://github.com/darchr/gem5/tree/jason/kvm-testing/configs/myconfigs>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Shehab Y. Elsayed, MSc.
>>>>>>>>>>>>>>>>>>>> PhD Student
>>>>>>>>>>>>>>>>>>>> The Edwards S. Rogers Sr. Dept. of Electrical and
>>>>>>>>>>>>>>>>>>>> Computer Engineering
>>>>>>>>>>>>>>>>>>>> University of Toronto
>>>>>>>>>>>>>>>>>>>> E-mail: shehaby...@gmail.com
>>>>>>>>>>>>>>>>>>>> <https://webmail.rice.edu/imp/message.php?mailbox=INBOX&index=11#>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Mon, Jul 29, 2019 at 4:08 PM Shehab Elsayed <
>>>>>>>>>>>>>>>>>>>> shehaby...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I have set up a repo with gem5 that demonstrates the
>>>>>>>>>>>>>>>>>>>>> problem. The repo includes the latest version of gem5
>>>>>>>>>>>>>>>>>>>>> from gem5's github
>>>>>>>>>>>>>>>>>>>>> repo with a few patches applied to get KVM working
>>>>>>>>>>>>>>>>>>>>> together with the kernel
>>>>>>>>>>>>>>>>>>>>> binary and disk image I am using. You can get the repo at
>>>>>>>>>>>>>>>>>>>>> https://github.com/ShehabElsayed/gem5_debug.git.
>>>>>>>>>>>>>>>>>>>>> <https://github.com/ShehabElsayed/gem5_debug.git>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> These steps should reproduce the problem:
>>>>>>>>>>>>>>>>>>>>> 1- scons build/X86/gem5.opt
>>>>>>>>>>>>>>>>>>>>> 2- ./scripts/get_fs_stuff.sh
>>>>>>>>>>>>>>>>>>>>> 3- ./scripts/run_fs.sh 8
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I have also included sample m5term outputs for both a
>>>>>>>>>>>>>>>>>>>>> 2 thread run (m5out_2t) and an 8 thread run (m5out_8t)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Any help is really appreciated.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Tue, Jul 23, 2019 at 11:01 AM Shehab Elsayed <
>>>>>>>>>>>>>>>>>>>>> shehaby...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> When I enable the Exec debug flag I can see that it
>>>>>>>>>>>>>>>>>>>>>> seems to be stuck in a spin lock
>>>>>>>>>>>>>>>>>>>>>> (queued_spin_lock_slowpath)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Fri, Jul 19, 2019 at 5:28 PM Shehab Elsayed <
>>>>>>>>>>>>>>>>>>>>>> shehaby...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Hello All,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I have a gem5 X86 full system set up that starts
>>>>>>>>>>>>>>>>>>>>>>> with KVM cores and then switches to O3 cores once
>>>>>>>>>>>>>>>>>>>>>>> the benchmark reaches the region of interest. Right now
>>>>>>>>>>>>>>>>>>>>>>> I am testing with a
>>>>>>>>>>>>>>>>>>>>>>> simple multithreaded hello world benchmark.
>>>>>>>>>>>>>>>>>>>>>>> Sometimes the benchmark completes successfully while
>>>>>>>>>>>>>>>>>>>>>>> others gem5 just seems
>>>>>>>>>>>>>>>>>>>>>>> to hang after starting the benchmark. I believe it is
>>>>>>>>>>>>>>>>>>>>>>> still executing some
>>>>>>>>>>>>>>>>>>>>>>> instructions but without making any progress. The
>>>>>>>>>>>>>>>>>>>>>>> chance of this behavior (
>>>>>>>>>>>>>>>>>>>>>>> indeterminism) happening increases as the number of
>>>>>>>>>>>>>>>>>>>>>>> simulated cores or the number of threads created by the
>>>>>>>>>>>>>>>>>>>>>>> benchmark increases.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Any ideas what might be the reason for this or how I
>>>>>>>>>>>>>>>>>>>>>>> can start debugging this problem?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Note: I have tried the patch in https://gem5-review.
>>>>>>>>>>>>>>>>>>>>>>> googlesource.com/c/public/gem5/+/19568 but the
>>>>>>>>>>>>>>>>>>>>>>> problem persists.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>> gem5-users mailing list
>>>>>>>>>>>>>>>>>>> gem5-users@gem5.org
>>>>>>>>>>>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>> gem5-users mailing list
>>>>>>>>>>>>>>>>>> gem5-users@gem5.org
>>>>>>>>>>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> gem5-users mailing list
>>>>>>>>>>>>>>>>> gem5-users@gem5.org
>>>>>>>>>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> gem5-users mailing list
>>>>>>>>>>>>>>>> gem5-users@gem5.org
>>>>>>>>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> gem5-users mailing list
>>>>>>>>>>>>>>> gem5-users@gem5.org
>>>>>>>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Pouya Fotouhi
>>>>>>>>>>>>>> PhD Candidate
>>>>>>>>>>>>>> Department of Electrical and Computer Engineering
>>>>>>>>>>>>>> University of California, Davis
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> gem5-users mailing list
>>>>>>>>>>>>>> gem5-users@gem5.org
>>>>>>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> gem5-users mailing list
>>>>>>>>>>>>> gem5-users@gem5.org
>>>>>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> gem5-users mailing list
>>>>>>>>>>>> gem5-users@gem5.org
>>>>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Pouya Fotouhi
>>>>>>>>>>> PhD Candidate
>>>>>>>>>>> Department of Electrical and Computer Engineering
>>>>>>>>>>> University of California, Davis
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> gem5-users mailing list
>>>>>>>>>>> gem5-users@gem5.org
>>>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> gem5-users mailing list
>>>>>>>>>> gem5-users@gem5.org
>>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Pouya Fotouhi
>>>>>>>>> PhD Candidate
>>>>>>>>> Department of Electrical and Computer Engineering
>>>>>>>>> University of California, Davis
>>>>>>>>> _______________________________________________
>>>>>>>>> gem5-users mailing list
>>>>>>>>> gem5-users@gem5.org
>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> gem5-users mailing list
>>>>>>>> gem5-users@gem5.org
>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Pouya Fotouhi
>>>>>>> PhD Candidate
>>>>>>> Department of Electrical and Computer Engineering
>>>>>>> University of California, Davis
>>>>>>> _______________________________________________
>>>>>>> gem5-users mailing list
>>>>>>> gem5-users@gem5.org
>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>
>>>>>> _______________________________________________
>>>>>> gem5-users mailing list
>>>>>> gem5-users@gem5.org
>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Pouya Fotouhi
>>>>> PhD Candidate
>>>>> Department of Electrical and Computer Engineering
>>>>> University of California, Davis
>>>>> _______________________________________________
>>>>> gem5-users mailing list
>>>>> gem5-users@gem5.org
>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>
>>>> _______________________________________________
>>>> gem5-users mailing list
>>>> gem5-users@gem5.org
>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>
>>>
>>>
>>> --
>>> Pouya Fotouhi
>>> PhD Candidate
>>> Department of Electrical and Computer Engineering
>>> University of California, Davis
>>> _______________________________________________
>>> gem5-users mailing list
>>> gem5-users@gem5.org
>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>>
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
