Hello, I am creating a NUMA system with the classic memory system, in my configuration there are 2 domains and each one has its own memory, so there are 2 memory buses. The second memory bus reports a badaddr_responder warning and then crashes, could anyone help me to understand how the badaddr_responder works and what the problem is? The warning is: warn: Device system.membus1.badaddr_responder accessed by read to address 0x10 size=4 And address 0x10 is used for bootloader: build/ARM/arch/arm/fs_workload.cc:121: info: Using bootloader at address 0x10 The full script is as follows: ./build/ARM/gem5.debug configs/numa/numa_fs.py --num_domains=2 --num_cpus_per_domain=2 --disk-image=$M5_PATH/disks/expanded-ubuntu-18.04-arm64-docker.img --kernel=$M5_PATH/binaries/vmlinux.arm64 --param 'system.sve_vl = 2' --caches --l2cache --num-l2caches=1 --l1d_size=32kB --l1i_size=32kB --l2_size=256kB --mem_size_per_domain=1GB --script=../arm-gem5-rsk/parsec_rcs/blackscholes_simsmall_4.rcS --cpu-type=TimingSimpleCPU gem5 Simulator System. http://gem5.org gem5 is copyrighted software; use the --copyright option for details. gem5 version 21.2.1.0 gem5 compiled Jul 13 2022 06:19:23 gem5 started Jul 26 2022 14:01:24 gem5 executing on zhewenhu-B360-M-AORUS-PRO, pid 4084998 command line: ./build/ARM/gem5.debug configs/numa/numa_fs.py --num_domains=2 --num_cpus_per_domain=2 --disk-image=/home/zhewenhu/arm/gem5/../m5_binaries/disks/expanded-ubuntu-18.04-arm64-docker.img --kernel=/home/zhewenhu/arm/gem5/../m5_binaries/binaries/vmlinux.arm64 --param 'system.sve_vl = 2' --caches --l2cache --num-l2caches=1 --l1d_size=32kB --l1i_size=32kB --l2_size=256kB --mem_size_per_domain=1GB --script=../arm-gem5-rsk/parsec_rcs/blackscholes_simsmall_4.rcS --cpu-type=TimingSimpleCPU 512MB domain#0.mem_ranges: \[0x80000000:0xc0000000\] domain#1.mem_ranges: \[0x280000000:0x2c0000000\] Global frequency set at 1000000000000 ticks per second build/ARM/mem/mem_interface.cc:791: warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (1024 Mbytes) build/ARM/mem/mem_interface.cc:791: warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (1024 Mbytes) build/ARM/sim/kernel_workload.cc:46: info: kernel located at: /home/zhewenhu/arm/gem5/../m5_binaries/binaries/vmlinux.arm64 system.vncserver: Listening for connections on port 5900 system.terminal: Listening for connections on port 3456 system.realview.uart1.device: Listening for connections on port 3457 system.realview.uart2.device: Listening for connections on port 3458 system.realview.uart3.device: Listening for connections on port 3459 0: system.remote_gdb: listening for remote gdb on port 7000 build/ARM/arch/arm/fs_workload.cc:121: info: Using bootloader at address 0x10 build/ARM/arch/arm/fs_workload.cc:139: info: Using kernel entry physical address at 0x80080000 build/ARM/arch/arm/linux/fs_workload.cc:96: info: Loading DTB file: m5out/system.dtb at address 0x88000000 \*\*\*\* REAL SIMULATION \*\*\*\* build/ARM/dev/arm/energy_ctrl.cc:252: warn: Existing EnergyCtrl, but no enabled DVFSHandler found. build/ARM/sim/simulate.cc:194: info: Entering event queue @ 0. Starting simulation... build/ARM/dev/isa_fake.cc:59: warn: Device system.membus1.badaddr_responder accessed by read to address 0x10 size=4 build/ARM/dev/isa_fake.cc:59: warn: Device system.membus1.badaddr_responder accessed by read to address 0x10 size=4 gem5.debug: build/ARM/cpu/simple/timing.cc:829: void gem5::TimingSimpleCPU::completeIfetch(gem5::PacketPtr): Assertion \`!pkt || !pkt->isError()' failed. Program aborted at tick 133500 \--- BEGIN LIBC BACKTRACE --- ./build/ARM/gem5.debug(+0x1203742)\[0x5617e358c742\] ./build/ARM/gem5.debug(+0x12244c6)\[0x5617e35ad4c6\] /lib/x86_64-linux-gnu/libpthread.so.0(+0x14420)\[0x7f7e82214420\] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcb)\[0x7f7e813ba00b\] /lib/x86_64-linux-gnu/libc.so.6(abort+0x12b)\[0x7f7e81399859\] /lib/x86_64-linux-gnu/libc.so.6(+0x22729)\[0x7f7e81399729\] /lib/x86_64-linux-gnu/libc.so.6(+0x33fd6)\[0x7f7e813aafd6\] ./build/ARM/gem5.debug(+0x10f6225)\[0x5617e347f225\] ./build/ARM/gem5.debug(+0x10f68e5)\[0x5617e347f8e5\] ./build/ARM/gem5.debug(+0x1212d96)\[0x5617e359bd96\] ./build/ARM/gem5.debug(+0x123ee6b)\[0x5617e35c7e6b\] ./build/ARM/gem5.debug(+0x123ea42)\[0x5617e35c7a42\] ./build/ARM/gem5.debug(+0xf94730)\[0x5617e331d730\] ./build/ARM/gem5.debug(+0xf92b06)\[0x5617e331bb06\] ./build/ARM/gem5.debug(+0xf8ee75)\[0x5617e3317e75\] ./build/ARM/gem5.debug(+0xf8eee0)\[0x5617e3317ee0\] ./build/ARM/gem5.debug(+0xb64dbc)\[0x5617e2eeddbc\] /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x2a8738)\[0x7f7e824cb738\] /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x8dd8)\[0x7f7e822a0f48\] /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalCodeWithName+0x8fb)\[0x7f7e823ede3b\] /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyFunction_Vectorcall+0x94)\[0x7f7e824cb114\] /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x74d6d)\[0x7f7e82297d6d\] /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x7d86)\[0x7f7e8229fef6\] /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x8006b)\[0x7f7e822a306b\] /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x74d6d)\[0x7f7e82297d6d\] /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x12fd)\[0x7f7e8229946d\] /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalCodeWithName+0x8fb)\[0x7f7e823ede3b\] /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyFunction_Vectorcall+0x94)\[0x7f7e824cb114\] /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x74d6d)\[0x7f7e82297d6d\] /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x7d86)\[0x7f7e8229fef6\] /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalCodeWithName+0x8fb)\[0x7f7e823ede3b\] /lib/x86_64-linux-gnu/libpython3.8.so.1.0(PyEval_EvalCodeEx+0x42)\[0x7f7e823ee1c2\] \--- END LIBC BACKTRACE --- Aborted (core dumped)

Hi, On 7/26/22 20:21, larried1111@gmail.com<mailto:larried1111@gmail.com> wrote: > > Hello, > > I am creating a NUMA system with the classic memory system, in my > configuration there are 2 domains and each one has its own memory, so > there are 2 memory buses. The second memory bus reports a > badaddr_responder warning and then crashes, could anyone help me to > understand how the badaddr_responder works and what the problem is? > > The warning is: > > warn: Device system.membus1.badaddr_responder accessed by read to > address 0x10 size=4 > > > And address 0x10 is used for bootloader: The badaddr_responder kicks in whenever the memory bus doesn't know where to dispatch a packet based on its address. Where has the bootloader been loaded? To the memory attached to membus0 or membus1? Kind Regards Giacomo > > build/ARM/arch/arm/fs_workload.cc:121: info: Using bootloader at > address 0x10 > > > The full script is as follows: > > > ./build/ARM/gem5.debug configs/numa/numa_fs.py --num_domains=2 > --num_cpus_per_domain=2 > --disk-image=$M5_PATH/disks/expanded-ubuntu-18.04-arm64-docker.img > --kernel=$M5_PATH/binaries/vmlinux.arm64 --param 'system.sve_vl = 2' > --caches --l2cache --num-l2caches=1 --l1d_size=32kB --l1i_size=32kB > --l2_size=256kB --mem_size_per_domain=1GB > --script=../arm-gem5-rsk/parsec_rcs/blackscholes_simsmall_4.rcS > --cpu-type=TimingSimpleCPU > > gem5 Simulator System. http://gem5.org > > gem5 is copyrighted software; use the --copyright option for > details. > > gem5 version 21.2.1.0 > > gem5 compiled Jul 13 2022 06:19:23 > > gem5 started Jul 26 2022 14:01:24 > > gem5 executing on zhewenhu-B360-M-AORUS-PRO, pid 4084998 > > command line: ./build/ARM/gem5.debug configs/numa/numa_fs.py > --num_domains=2 --num_cpus_per_domain=2 > --disk-image=/home/zhewenhu/arm/gem5/../m5_binaries/disks/expanded-ubuntu-18.04-arm64-docker.img > --kernel=/home/zhewenhu/arm/gem5/../m5_binaries/binaries/vmlinux.arm64 > --param 'system.sve_vl = 2' --caches --l2cache --num-l2caches=1 > --l1d_size=32kB --l1i_size=32kB --l2_size=256kB > --mem_size_per_domain=1GB > --script=../arm-gem5-rsk/parsec_rcs/blackscholes_simsmall_4.rcS > --cpu-type=TimingSimpleCPU > > 512MB > > domain#0.mem_ranges: > > [0x80000000:0xc0000000] > > domain#1.mem_ranges: > > [0x280000000:0x2c0000000] > > Global frequency set at 1000000000000 ticks per second > > build/ARM/mem/mem_interface.cc:791: warn: DRAM device capacity (8192 > Mbytes) does not match the address range assigned (1024 Mbytes) > > build/ARM/mem/mem_interface.cc:791: warn: DRAM device capacity (8192 > Mbytes) does not match the address range assigned (1024 Mbytes) > > build/ARM/sim/kernel_workload.cc:46: info: kernel located at: > /home/zhewenhu/arm/gem5/../m5_binaries/binaries/vmlinux.arm64 > > system.vncserver: Listening for connections on port 5900 > > system.terminal: Listening for connections on port 3456 > > system.realview.uart1.device: Listening for connections on port 3457 > > system.realview.uart2.device: Listening for connections on port 3458 > > system.realview.uart3.device: Listening for connections on port 3459 > > 0: system.remote_gdb: listening for remote gdb on port 7000 > > build/ARM/arch/arm/fs_workload.cc:121: info: Using bootloader at > address 0x10 > > build/ARM/arch/arm/fs_workload.cc:139: info: Using kernel entry > physical address at 0x80080000 > > build/ARM/arch/arm/linux/fs_workload.cc:96: info: Loading DTB file: > m5out/system.dtb at address 0x88000000 > > **** REAL SIMULATION **** > > build/ARM/dev/arm/energy_ctrl.cc:252: warn: Existing EnergyCtrl, but > no enabled DVFSHandler found. > > build/ARM/sim/simulate.cc:194: info: Entering event queue @ 0. > Starting simulation... > > build/ARM/dev/isa_fake.cc:59: warn: Device > system.membus1.badaddr_responder accessed by read to address 0x10 > size=4 > > build/ARM/dev/isa_fake.cc:59: warn: Device > system.membus1.badaddr_responder accessed by read to address 0x10 > size=4 > > gem5.debug: build/ARM/cpu/simple/timing.cc:829: void > gem5::TimingSimpleCPU::completeIfetch(gem5::PacketPtr): Assertion > `!pkt || !pkt->isError()' failed. > > Program aborted at tick 133500 > > --- BEGIN LIBC BACKTRACE --- > > ./build/ARM/gem5.debug(+0x1203742)[0x5617e358c742] > > ./build/ARM/gem5.debug(+0x12244c6)[0x5617e35ad4c6] > > /lib/x86_64-linux-gnu/libpthread.so.0(+0x14420)[0x7f7e82214420] > > /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcb)[0x7f7e813ba00b] > > /lib/x86_64-linux-gnu/libc.so.6(abort+0x12b)[0x7f7e81399859] > > /lib/x86_64-linux-gnu/libc.so.6(+0x22729)[0x7f7e81399729] > > /lib/x86_64-linux-gnu/libc.so.6(+0x33fd6)[0x7f7e813aafd6] > > ./build/ARM/gem5.debug(+0x10f6225)[0x5617e347f225] > > ./build/ARM/gem5.debug(+0x10f68e5)[0x5617e347f8e5] > > ./build/ARM/gem5.debug(+0x1212d96)[0x5617e359bd96] > > ./build/ARM/gem5.debug(+0x123ee6b)[0x5617e35c7e6b] > > ./build/ARM/gem5.debug(+0x123ea42)[0x5617e35c7a42] > > ./build/ARM/gem5.debug(+0xf94730)[0x5617e331d730] > > ./build/ARM/gem5.debug(+0xf92b06)[0x5617e331bb06] > > ./build/ARM/gem5.debug(+0xf8ee75)[0x5617e3317e75] > > ./build/ARM/gem5.debug(+0xf8eee0)[0x5617e3317ee0] > > ./build/ARM/gem5.debug(+0xb64dbc)[0x5617e2eeddbc] > > /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x2a8738)[0x7f7e824cb738] > > /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x8dd8)[0x7f7e822a0f48] > > > /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalCodeWithName+0x8fb)[0x7f7e823ede3b] > > /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyFunction_Vectorcall+0x94)[0x7f7e824cb114] > > > /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x74d6d)[0x7f7e82297d6d] > > /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x7d86)[0x7f7e8229fef6] > > > /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x8006b)[0x7f7e822a306b] > > /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x74d6d)[0x7f7e82297d6d] > > /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x12fd)[0x7f7e8229946d] > > > /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalCodeWithName+0x8fb)[0x7f7e823ede3b] > > /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyFunction_Vectorcall+0x94)[0x7f7e824cb114] > > > /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x74d6d)[0x7f7e82297d6d] > > /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x7d86)[0x7f7e8229fef6] > > > /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalCodeWithName+0x8fb)[0x7f7e823ede3b] > > /lib/x86_64-linux-gnu/libpython3.8.so.1.0(PyEval_EvalCodeEx+0x42)[0x7f7e823ee1c2] > > > --- END LIBC BACKTRACE --- > > Aborted (core dumped) > > > _______________________________________________ gem5-users mailing > list -- gem5-users@gem5.org<mailto:gem5-users@gem5.org> To unsubscribe send an email to > gem5-users-leave@gem5.org<mailto:gem5-users-leave@gem5.org> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Hi Travaglini, Thank you very much for the reply, the bootloader is loaded to the memory of membus0, I also uploaded my configuration in the attachment, if they are useful. Best regards, Zhewen Hu

Hi Giacomo, Where can I control the bootloader? In my config file I basically just follow the example FSConfig.py to setup the bootloader: https://github.com/gem5/gem5/blob/1d03f6de941520860c673b5f7954c82a46e8b191/configs/common/FSConfig.py#L295 Do I need to modify the bootloader file to make it work?

Hi On 8/2/22 22:46, larried1111@gmail.com wrote: > > Hi Giacomo, > > Where can I control the bootloader? In my config file I basically just > follow the example FSConfig.py to setup the bootloader: > > https://github.com/gem5/gem5/blob/1d03f6de941520860c673b5f7954c82a46e8b191/configs/common/FSConfig.py#L295 > > > Do I need to modify the bootloader file to make it work? > You definitely don't need to modify the bootloader. There is probably something wrong in the way you have connected you platform in the python world (it is a routing issue). The bootloader should be loaded in the bootmem memory (see src/dev/arm/RealView.py) based on its starting address. And as far as you told me bootmem is connected to membus0. This leads me to believe the failing fetch request starts from a cpu in the second NUMA node (this can be easily verified via GDB). When the fetch reaches the membus1, it is not able to be routed to bootmem as it is not directly connected to the bus. It should go through numa_caches_downward1 -> system_bus -> etc, but from your config.ini I see the numa_caches_downward is configured with DRAM only address ranges. It should include the bootmem range as well in order to accept memory requests falling in that range... This should fix the issue I believe. Kind Regards Giacomo > > _______________________________________________ > gem5-users mailing list --gem5-users@gem5.org > To unsubscribe send an email togem5-users-leave@gem5.org IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.