[gem5-users] Re: regarding ERRORS in building of X86 ISA
Sravani, You have been posting very frequently to this mailing list asking for help and, on at least two occasions, have ignored the feedback given to you. While we want to help new gem5 users, we cannot hold your hand through every problem. In case you are unaware, the gem5-users list is maintained by volunteers within the gem5 community who kindly give up their time to help others. Please keep this in mind before going directly to this list for assistance. Furthermore, if there are future questions to be asked, please copy and paste the text of the error messages you receive rather than take a screenshot. Kind regards, Bobby -- Dr. Bobby R. Bruce Room 3050, Kemper Hall, UC Davis Davis, CA, 95616 web: https://www.bobbybruce.net On Wed, Sep 8, 2021 at 12:14 AM Sravani Sravanam 20PHD7041 via gem5-users < gem5-users@gem5.org> wrote: > sir, > i am sravani sravanam, a phd scholar in vit-ap university.in using gem5 i > first CREATED THE ENVIRONMENT by using > https://www.gem5.org/documentation/general_docs/building link.and then i > tried to build X86 ISA.but i am getting error like > scons: *** No SConstruct file found. > File "/usr/lib/scons/SCons/Script/Main.py", line 940, in _main > and i am attaching the screenshot of it.please check it. > I am running gem5 in a virtual machine on my laptop.is it ok sir? > please help me > thank you > sravani sravanam > vit-ap university. > ___ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-le...@gem5.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[gem5-users] gem5 v21.1.0.1 hotfix release: Fix for 'deprecated attribute' warning
Dear all, The stable branch of the gem5 repository now contains the v21.1.0.1 hotfix release. This release fixes a bug where the build output was being flooded with "'deprecated' attribute directive ignored" warnings, as reported here: https://gem5.atlassian.net/browse/GEM5-1063. While this bug never broke the gem5 build, it was making reading the build output hard and was causing confusion. Kind regards, Bobby -- Dr. Bobby R. Bruce Room 3050, Kemper Hall, UC Davis Davis, CA, 95616 web: https://www.bobbybruce.net ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[gem5-users] Re: --take-checkpoints flag
Hi Sam, I would *guess* it's the draining code getting stuck in an infinite loop. The draining code calls "drain" on all SimObjects in the system, and they do their thing. Then, the drain code asks all SimObjects if they're done draining. If not, it starts over and calls drain on all objects again. If some object isn't draining properly or if there is some circular dependence, there could be a "live lock" in this code. Just a guess, though. Cheers, Jason On Wed, Sep 8, 2021 at 10:00 AM Thomas, Samuel wrote: > Hi Jason, > > Thanks for your help. I think I've honed in on the source of the problem > -- namely, number of cpus. Is there a reason why having multiple CPUs in a > particular configuration would limit the simulator's ability to write a > checkpoint? > > Again, thank you for your help! > > Best, > Sam > > On Wed, Sep 8, 2021 at 11:12 AM Jason Lowe-Power > wrote: > >> Hi Sam, >> >> Sorry for the frustration. Writing better documentation is always #2 on >> the priority list :(. >> >> I always tell people not to trust any of the "options" to fs.py and >> se.py. Those scripts have gotten so far beyond "out of hand" at this point >> that they are almost useless. They are trying to be everything to everyone, >> and they end up just being a mess of spaghetti code and confusion. >> >> To take a checkpoint, you can add the following code to a python >> runscript: >> >> m5.simulate(1) >> m5.checkpoint() >> m5.simulate(2) >> m5.checkpoint() >> >> I tested the above code by adding it to the >> configs/learning_gem5/part1/two_level.py file. >> >> *Maybe* this is what --take-checkpoints is doing. It's certainly what it >> was *supposed* to do, but again, since this code has gotten so out of hand, >> who knows if it's actually doing what it advertises. >> >> If you want to use the m5ops to checkpoint, the code would look >> something like the following (this isn't tested and it's off the top of my >> head). >> >> while 1: >> exit_event = m5.simulate() >> if exit_event.getCause() == 'checkpoint'): >> m5.checkpoint(m5.outdir + '/' + str(num)) >> else: >> break >> >> To restore from a checkpoint, pass the checkpoint directory as the only >> parameter to m5.instantiate(ckpt_dir=). >> >> Hope this helps! If you're still experiencing a hang in this case, it's >> probably a bug in the drain() code somewhere. You can try to use one of the >> drain debug flags (I don't know exactly what these are... check gem5 >> --debug-help for a list of debug flags). Making the python runscript do >> exactly what you expect will also help with debugging. When you control the >> script, adding prints is easy, too! >> >> Finally, the file src/python/m5/simulate.py may be helpful to figure out >> what's going on when instantiating, simulating, checkpointing, etc. >> >> Cheers, >> Jason >> >> On Wed, Sep 8, 2021 at 6:14 AM Thomas, Samuel via gem5-users < >> gem5-users@gem5.org> wrote: >> >>> Hi all, >>> >>> Just to follow up, because I can see that there have been some issues >>> with not including all of the requisite issues in other threads, here is >>> the full output from what I described above. >>> >>> gem5 Simulator System. http://gem5.org >>> gem5 is copyrighted software; use the --copyright option for details. >>> >>> gem5 version 21.1.0.0 >>> gem5 compiled Sep 7 2021 19:28:16 >>> gem5 started Sep 8 2021 09:09:11 >>> gem5 executing on sam-Precision-Tower-5810, pid 445665 >>> command line: build/X86/gem5.opt -d $CURR_DIR/debug >>> $CURR_DIR/configs/example/fs.py --caches --l2cache --mem-type DDR3_1600_8x8 >>> --mem-size 2GB --meta-size 512kB --num-cpus 4 --disk-image $DISK_PATH >>> --kernel $KERNEL_PATH --cpu-type $CPU_TYPE --script=$SCRIPT_PATH >>> --l2_size=1MB --take-checkpoints=1,2 >>> >>> warn: iobus.slave is deprecated. `slave` is now called `cpu_side_ports` >>> warn: bridge.master is deprecated. `master` is now called `mem_side_port` >>> warn: membus.master is deprecated. `master` is now called >>> `mem_side_ports` >>> warn: bridge.slave is deprecated. `slave` is now called `cpu_side_port` >>> warn: iobus.master is deprecated. `master` is now called `mem_side_ports` >>> warn: apicbridge.slave is deprecated. `slave` is now called >>> `cpu_side_port` >>> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` >>> warn: apicbridge.master is deprecated. `master` is now called >>> `mem_side_port` >>> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` >>> warn: iobus.master is deprecated. `master` is now called `mem_side_ports` >>> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` >>> warn: tol2bus.master is deprecated. `master` is now called >>> `mem_side_ports` >>> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` >>> warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` >>> warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` >>> warn: tol2bus.slave is deprecated.
[gem5-users] Re: --take-checkpoints flag
Hi Jason, Thanks for your help. I think I've honed in on the source of the problem -- namely, number of cpus. Is there a reason why having multiple CPUs in a particular configuration would limit the simulator's ability to write a checkpoint? Again, thank you for your help! Best, Sam On Wed, Sep 8, 2021 at 11:12 AM Jason Lowe-Power wrote: > Hi Sam, > > Sorry for the frustration. Writing better documentation is always #2 on > the priority list :(. > > I always tell people not to trust any of the "options" to fs.py and se.py. > Those scripts have gotten so far beyond "out of hand" at this point that > they are almost useless. They are trying to be everything to everyone, and > they end up just being a mess of spaghetti code and confusion. > > To take a checkpoint, you can add the following code to a python runscript: > > m5.simulate(1) > m5.checkpoint() > m5.simulate(2) > m5.checkpoint() > > I tested the above code by adding it to the > configs/learning_gem5/part1/two_level.py file. > > *Maybe* this is what --take-checkpoints is doing. It's certainly what it > was *supposed* to do, but again, since this code has gotten so out of hand, > who knows if it's actually doing what it advertises. > > If you want to use the m5ops to checkpoint, the code would look > something like the following (this isn't tested and it's off the top of my > head). > > while 1: > exit_event = m5.simulate() > if exit_event.getCause() == 'checkpoint'): > m5.checkpoint(m5.outdir + '/' + str(num)) > else: > break > > To restore from a checkpoint, pass the checkpoint directory as the only > parameter to m5.instantiate(ckpt_dir=). > > Hope this helps! If you're still experiencing a hang in this case, it's > probably a bug in the drain() code somewhere. You can try to use one of the > drain debug flags (I don't know exactly what these are... check gem5 > --debug-help for a list of debug flags). Making the python runscript do > exactly what you expect will also help with debugging. When you control the > script, adding prints is easy, too! > > Finally, the file src/python/m5/simulate.py may be helpful to figure out > what's going on when instantiating, simulating, checkpointing, etc. > > Cheers, > Jason > > On Wed, Sep 8, 2021 at 6:14 AM Thomas, Samuel via gem5-users < > gem5-users@gem5.org> wrote: > >> Hi all, >> >> Just to follow up, because I can see that there have been some issues >> with not including all of the requisite issues in other threads, here is >> the full output from what I described above. >> >> gem5 Simulator System. http://gem5.org >> gem5 is copyrighted software; use the --copyright option for details. >> >> gem5 version 21.1.0.0 >> gem5 compiled Sep 7 2021 19:28:16 >> gem5 started Sep 8 2021 09:09:11 >> gem5 executing on sam-Precision-Tower-5810, pid 445665 >> command line: build/X86/gem5.opt -d $CURR_DIR/debug >> $CURR_DIR/configs/example/fs.py --caches --l2cache --mem-type DDR3_1600_8x8 >> --mem-size 2GB --meta-size 512kB --num-cpus 4 --disk-image $DISK_PATH >> --kernel $KERNEL_PATH --cpu-type $CPU_TYPE --script=$SCRIPT_PATH >> --l2_size=1MB --take-checkpoints=1,2 >> >> warn: iobus.slave is deprecated. `slave` is now called `cpu_side_ports` >> warn: bridge.master is deprecated. `master` is now called `mem_side_port` >> warn: membus.master is deprecated. `master` is now called `mem_side_ports` >> warn: bridge.slave is deprecated. `slave` is now called `cpu_side_port` >> warn: iobus.master is deprecated. `master` is now called `mem_side_ports` >> warn: apicbridge.slave is deprecated. `slave` is now called >> `cpu_side_port` >> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` >> warn: apicbridge.master is deprecated. `master` is now called >> `mem_side_port` >> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` >> warn: iobus.master is deprecated. `master` is now called `mem_side_ports` >> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` >> warn: tol2bus.master is deprecated. `master` is now called >> `mem_side_ports` >> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` >> warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` >> warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` >> warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` >> warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` >> warn: membus.master is deprecated. `master` is now called `mem_side_ports` >> warn: membus.master is deprecated. `master` is now called `mem_side_ports` >> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` >> warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` >> warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` >> warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` >> warn: tol2bus.slave is deprecated. `slave` is now called
[gem5-users] Re: Is it ok to remove `maxRoutingTableSizeCheck`?
Hi Emil, You can remove that check. However, you should note that the classic caches aren't designed to support high-bandwidth operation. Also, this assert triggering could be a sign that there's infinite queuing somewhere (which is one reason why the classic caches aren't great for high bandwidth systems). Cheers, Jason On Wed, Sep 8, 2021 at 3:48 AM Emil VATAI via gem5-users < gem5-users@gem5.org> wrote: > Hi, > > We are trying to do some simulations. We are using a simulator based on an > old version of Gem5 ([1] created to simulate a64fx chip). > We made some further modifications, namely replaced `SnoopMask` to be of > type `std::bitset<>` to be able to run more-or-less arbitrary number of > cores. And running with more cores resulted in triggering the following > panic in `coherent_xbar.cc` (it occurs 2x in the code, around line 330 and > 400 [3], not sure which one was triggered). > ``` > panic_if(routeTo.size() > 512, "Routing table exceeds 512 packets\n"); > ``` > comparing this to a more recent version of gem5 the constant 512 seems to > be the `maxRoutingTableSizeCheck` variable [4]. > > My question is, how important is that check? How will it impact the > simulation? Will it still be a "correct" simulation (or will skipping that > check do something silly, like skip simulation half of the memory writes or > something like that). > > Best, > Emil > > [1] https://github.com/RIKEN-RCCS/riken_simulator > [2] https://github.com/bgerofi/riken_simulator/ > [3] > https://github.com/bgerofi/riken_simulator/blob/1f6627cf95688c508b73c8ead6838aa1f843f436/src/mem/coherent_xbar.cc#L339 > [4] > https://github.com/gem5/gem5/blob/87c121fd954ea5a6e6b0760d693a2e744c2200de/src/mem/coherent_xbar.cc#L346 > ___ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-le...@gem5.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[gem5-users] Re: --take-checkpoints flag
Hi Sam, Sorry for the frustration. Writing better documentation is always #2 on the priority list :(. I always tell people not to trust any of the "options" to fs.py and se.py. Those scripts have gotten so far beyond "out of hand" at this point that they are almost useless. They are trying to be everything to everyone, and they end up just being a mess of spaghetti code and confusion. To take a checkpoint, you can add the following code to a python runscript: m5.simulate(1) m5.checkpoint() m5.simulate(2) m5.checkpoint() I tested the above code by adding it to the configs/learning_gem5/part1/two_level.py file. *Maybe* this is what --take-checkpoints is doing. It's certainly what it was *supposed* to do, but again, since this code has gotten so out of hand, who knows if it's actually doing what it advertises. If you want to use the m5ops to checkpoint, the code would look something like the following (this isn't tested and it's off the top of my head). while 1: exit_event = m5.simulate() if exit_event.getCause() == 'checkpoint'): m5.checkpoint(m5.outdir + '/' + str(num)) else: break To restore from a checkpoint, pass the checkpoint directory as the only parameter to m5.instantiate(ckpt_dir=). Hope this helps! If you're still experiencing a hang in this case, it's probably a bug in the drain() code somewhere. You can try to use one of the drain debug flags (I don't know exactly what these are... check gem5 --debug-help for a list of debug flags). Making the python runscript do exactly what you expect will also help with debugging. When you control the script, adding prints is easy, too! Finally, the file src/python/m5/simulate.py may be helpful to figure out what's going on when instantiating, simulating, checkpointing, etc. Cheers, Jason On Wed, Sep 8, 2021 at 6:14 AM Thomas, Samuel via gem5-users < gem5-users@gem5.org> wrote: > Hi all, > > Just to follow up, because I can see that there have been some issues with > not including all of the requisite issues in other threads, here is the > full output from what I described above. > > gem5 Simulator System. http://gem5.org > gem5 is copyrighted software; use the --copyright option for details. > > gem5 version 21.1.0.0 > gem5 compiled Sep 7 2021 19:28:16 > gem5 started Sep 8 2021 09:09:11 > gem5 executing on sam-Precision-Tower-5810, pid 445665 > command line: build/X86/gem5.opt -d $CURR_DIR/debug > $CURR_DIR/configs/example/fs.py --caches --l2cache --mem-type DDR3_1600_8x8 > --mem-size 2GB --meta-size 512kB --num-cpus 4 --disk-image $DISK_PATH > --kernel $KERNEL_PATH --cpu-type $CPU_TYPE --script=$SCRIPT_PATH > --l2_size=1MB --take-checkpoints=1,2 > > warn: iobus.slave is deprecated. `slave` is now called `cpu_side_ports` > warn: bridge.master is deprecated. `master` is now called `mem_side_port` > warn: membus.master is deprecated. `master` is now called `mem_side_ports` > warn: bridge.slave is deprecated. `slave` is now called `cpu_side_port` > warn: iobus.master is deprecated. `master` is now called `mem_side_ports` > warn: apicbridge.slave is deprecated. `slave` is now called `cpu_side_port` > warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` > warn: apicbridge.master is deprecated. `master` is now called > `mem_side_port` > warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` > warn: iobus.master is deprecated. `master` is now called `mem_side_ports` > warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` > warn: tol2bus.master is deprecated. `master` is now called `mem_side_ports` > warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` > warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` > warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` > warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` > warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` > warn: membus.master is deprecated. `master` is now called `mem_side_ports` > warn: membus.master is deprecated. `master` is now called `mem_side_ports` > warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` > warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` > warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` > warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` > warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` > warn: membus.master is deprecated. `master` is now called `mem_side_ports` > warn: membus.master is deprecated. `master` is now called `mem_side_ports` > warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` > warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` > warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` > warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` > warn: tol2bus.slave
[gem5-users] Re: --take-checkpoints flag
Hi all, Just to follow up, because I can see that there have been some issues with not including all of the requisite issues in other threads, here is the full output from what I described above. gem5 Simulator System. http://gem5.org gem5 is copyrighted software; use the --copyright option for details. gem5 version 21.1.0.0 gem5 compiled Sep 7 2021 19:28:16 gem5 started Sep 8 2021 09:09:11 gem5 executing on sam-Precision-Tower-5810, pid 445665 command line: build/X86/gem5.opt -d $CURR_DIR/debug $CURR_DIR/configs/example/fs.py --caches --l2cache --mem-type DDR3_1600_8x8 --mem-size 2GB --meta-size 512kB --num-cpus 4 --disk-image $DISK_PATH --kernel $KERNEL_PATH --cpu-type $CPU_TYPE --script=$SCRIPT_PATH --l2_size=1MB --take-checkpoints=1,2 warn: iobus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: bridge.master is deprecated. `master` is now called `mem_side_port` warn: membus.master is deprecated. `master` is now called `mem_side_ports` warn: bridge.slave is deprecated. `slave` is now called `cpu_side_port` warn: iobus.master is deprecated. `master` is now called `mem_side_ports` warn: apicbridge.slave is deprecated. `slave` is now called `cpu_side_port` warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: apicbridge.master is deprecated. `master` is now called `mem_side_port` warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: iobus.master is deprecated. `master` is now called `mem_side_ports` warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: tol2bus.master is deprecated. `master` is now called `mem_side_ports` warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: membus.master is deprecated. `master` is now called `mem_side_ports` warn: membus.master is deprecated. `master` is now called `mem_side_ports` warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: membus.master is deprecated. `master` is now called `mem_side_ports` warn: membus.master is deprecated. `master` is now called `mem_side_ports` warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: membus.master is deprecated. `master` is now called `mem_side_ports` warn: membus.master is deprecated. `master` is now called `mem_side_ports` warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: tol2bus.slave is deprecated. `slave` is now called `cpu_side_ports` warn: membus.master is deprecated. `master` is now called `mem_side_ports` warn: membus.master is deprecated. `master` is now called `mem_side_ports` warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports` Global frequency set at 1 ticks per second warn: system.workload.acpi_description_table_pointer.rsdt adopting orphan SimObject param 'entries' [Detaching after fork from child process 445724] [Detaching after fork from child process 445725] build/X86/mem/mem_interface.cc:792: warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (2048 Mbytes) build/X86/sim/kernel_workload.cc:46: info: kernel located at: /home/sam/Desktop/clean-gem5/gem5/_dist/binaries/x86_64-vmlinux-2.6.22.9 0: system.pc.south_bridge.cmos.rtc: Real-time clock set to Sun Jan 1 00:00:00 2012 system.pc.com_1.device: Listening for connections on port 3464 0: system.remote_gdb: listening for remote gdb on port 7008 build/X86/dev/intel_8254_timer.cc:125: warn: Reading current count from inactive timer. REAL SIMULATION build/X86/sim/simulate.cc:107: info: Entering event queue @ 0. Starting simulation... Exiting @ tick 1 because simulate() limit reached build/X86/sim/simulate.cc:107: info: Entering event queue @ 1. Starting simulation... At this point, the program hangs, and occupies the ports until I manually reset it even after killing the terminal
[gem5-users] Is it ok to remove `maxRoutingTableSizeCheck`?
Hi, We are trying to do some simulations. We are using a simulator based on an old version of Gem5 ([1] created to simulate a64fx chip). We made some further modifications, namely replaced `SnoopMask` to be of type `std::bitset<>` to be able to run more-or-less arbitrary number of cores. And running with more cores resulted in triggering the following panic in `coherent_xbar.cc` (it occurs 2x in the code, around line 330 and 400 [3], not sure which one was triggered). ``` panic_if(routeTo.size() > 512, "Routing table exceeds 512 packets\n"); ``` comparing this to a more recent version of gem5 the constant 512 seems to be the `maxRoutingTableSizeCheck` variable [4]. My question is, how important is that check? How will it impact the simulation? Will it still be a "correct" simulation (or will skipping that check do something silly, like skip simulation half of the memory writes or something like that). Best, Emil [1] https://github.com/RIKEN-RCCS/riken_simulator [2] https://github.com/bgerofi/riken_simulator/ [3] https://github.com/bgerofi/riken_simulator/blob/1f6627cf95688c508b73c8ead6838aa1f843f436/src/mem/coherent_xbar.cc#L339 [4] https://github.com/gem5/gem5/blob/87c121fd954ea5a6e6b0760d693a2e744c2200de/src/mem/coherent_xbar.cc#L346 ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[gem5-users] Different values for different versions
Hi everyone, I am looking to work on 2 computers with different versions of gem5. When I have transferred the same executable from one PC to another and have tried the execution with the same command, they have given me different values in the L1 cache. The command I ran was: ~/gem5/build/ARM/gem5.opt ~/gem5/configs/example/se.py --cpu-type=O3_ARM_v7a_3 --num-cpus=1 --cpu-clock=1GHz --mem-size=500MB --caches --l1d_size=32kB --l1i_size=32kB --l1d_assoc=1 --l1i_assoc=1 --cacheline_size=32 -c file.arm My question is what have I done wrong? How do I define the same machine for both versions of gem5? Thanks in advance #New system.cpu.dcache.ReadReq.hits::total 4.527.099 # number of ReadReq hits (Count) system.cpu.dcache.ReadReq.misses::total 1.440 # number of ReadReq misses (Count) system.cpu.icache.ReadReq.hits::total 1.823.5251 # number of ReadReq hits (Count) system.cpu.icache.ReadReq.misses::total 4.950 # number of ReadReq misses (Count) #Old system.cpu.dcache.ReadReq_hits::total 1.001.163 # number of ReadReq hits system.cpu.dcache.ReadReq_misses::total 101 # number of ReadReq misses system.cpu.icache.ReadReq_hits::total 6.016.930 # number of ReadReq hits system.cpu.icache.ReadReq_misses::total 384 # number of ReadReq misses ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[gem5-users] Re: regarding ERRORS in building of X86 ISA
What about running scons inside the gem5 directory instead of your home directory? And don't run it with sudo. ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
