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
