[gem5-users] SPEC2017 in FS mode
Hi, I've tried running the SPEC2017 benchmarks in FS mode of gem5 using the instructions/files provided by the gem5 resources page. https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/stable/src/spec-2017 I've also followed the step by step instructions in the git repo for gem5-art. https://github.com/darchr/gem5art-experiments/blob/master/README.md Everything works as intended until the benchmarks are supposed to be built. All of them fail with one of the two following errors: 1) Error with make! 2) Error with fdo_make_pass1! First of all, why is this happening? Secondly, the vm closes after the builds fail. I don't have the opportunity to check the make.out files that have more information about the errors. Is there a way to prevent the connection from closing or reopening it again? Running it again with packer fails due to the directory existing already. I'd appreciate any help, Victor ___ 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] Cannot enter benchmark test set.
I defined TLB object tlb2 in mmu.cc file, and added tlb2 access process in getTE() function of tlb.cc file to realize simple two-level TLB. It can be compiled successfully, but it can't enter benchmark test set at runtime. I used Command line is：./build/ARM/gem5.opt /home/gem5/configs/example/fs.py --debug-flags=TLB,TLBVerbose --cpu-type=O3_ARM_v7a --caches --l2_size=2MB --l1d_size=512kB --l1i_size=512kB --l1d_assoc=8 --l1i_assoc=8 --l2_assoc=16 --script=/home/full_system_images/rcS/CPU06/450.soplex.rcS --kernel=/home/full_system_images/binaries/vmlinux.euler --disk-image=/home/full_system_images/expanded-linaro-minimal-aarch64.img I test run this command line in eclipse,the debug flags output not stopped,but the m5term terminal has stopped running in the following for a long time. [0.188161] igb: Copyright (c) 2007-2014 Intel Corporation. [0.188330] usbcore: registered new interface driver usb-storage [0.188460] mousedev: PS/2 mouse device common for all mice [0.188857] usbcore: registered new interface driver usbhid [0.188890] usbhid: USB HID core driver [0.188978] TCP: cubic registered [0.189002] NET: Registered protocol family 17 [0.341802] ata1.00: ATA-7: M5 IDE Disk, , max UDMA/66 [0.341834] ata1.00: 44039680 sectors, multi 0: LBA [0.341915] ata1.00: configured for UDMA/33 [0.342037] scsi 0:0:0:0: Direct-Access ATA M5 IDE Disk n/a PQ: 0 ANSI: 5 [0.342311] sd 0:0:0:0: Attached scsi generic sg0 type 0 [0.342373] sd 0:0:0:0: [sda] 44039680 512-byte logical blocks: (22.5 GB/20.9 GiB) [0.342463] sd 0:0:0:0: [sda] Write Protect is off [0.342493] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [0.342543] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [0.342814] sda: sda1 [0.343039] sd 0:0:0:0: [sda] Attached SCSI disk [0.343423] VFS: Mounted root (ext2 filesystem) on device 8:1. [0.343505] devtmpfs: mounted [0.343562] Freeing unused kernel memory: 208K (ffc00069 - ffc0006c4000) What is the reason that the m5term side can't run down all the time, but the command line can run down? Or is it appropriate for me to add TLB like this? Thanks in advance, ___ 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] PCI operation ordering
Hi, We have been using gem5 with the classic memory system for a while for full system X86 simulations integrating a number of different more modern PCIe device models. Now we are trying to get things to work with Ruby as well for multi-core X86 simulations. Currently we are tracking down some driver-related bugs that only show up with Ruby, and led us to the more fundamental question of how to model PCIe semantics, in particular with regards to ordering, correctly. My understanding is that PCIe guarantees strong ordering of operations (at least within a traffic class). And modren devices do take advantage of this: e.g. with descriptor queues where a posted write for the data buffer is immediately followed by a posted write for the descriptor, and then an MSI. Now currently our bridge for our device simulations in gem5 is implemented as a PCI device and just calls dmaRead/dmaWrite operations asynchronously without sequencing them synchronously. This at least seems to work for the classic memory system, but with ruby (MESI_Two_Level atm) we are seeing problems (still need to dig a bit deeper to confirm that this is 100% due to ordering). Is there a proper specification of what the model is for these memory operations? If the current dma ordering is too weak for PCIe semantics (looking at device models like the e1000, I see that DMAs are manually ordered by the device), any suggestions for how to go about ordering operations correctly without fully sequentializing everything? Thanks in advance, Antoine -- Antoine Kaufmann signature.asc Description: PGP signature ___ 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
