Re: [gem5-dev] Review Request 2469: mem: dram ctrl: correct errors due to busBusyUntil variable
As I suggested before, we will keep the timing accesses to ruby and the dram ctrl would be accessed using functional accesses. -- Nilay On Sun, 9 Nov 2014, Andreas Hansson via gem5-dev wrote: Hi Brad, Thanks a lot for the clarification. It seems the cleanest way (although that is probably requiring a lot of work), would be to do this playback without any timing involved, e.g. using atomic accesses and ignoring all return values, and doing so just after all other startup activity is done, perhaps in a new ??playbackState?? or something along those lines. In any case, for the short term, let me know if you need any help with a work-around Nilay. I??d prefer to discard the patch you currently have on RB and solve it some other way. Thanks, Andreas On 11/6/14, 6:10 PM, Beckmann, Brad via gem5-dev gem5-dev@gem5.org wrote: Andreas, we record the owner of the cache block in the trace. This methodology simplifies the configuration dependencies on the checkpoint and has worked well for Ruby for 15 years. There is actually an old paper from MIT that describes a more complete way of recording the owner of a cache block (I don't recall the author). It is quite a bit more complicated than what we do in Ruby today. Brad -Original Message- From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Hansson via gem5-dev Sent: Thursday, November 06, 2014 9:49 AM To: Nilay Vaish Cc: Default Subject: Re: [gem5-dev] Review Request 2469: mem: dram ctrl: correct errors due to busBusyUntil variable Hi Nilay, It seem like a bit of a hack to do timing within Ruby and functional to the memory, but it will probably serve as a work-around. I??m actually intrigued now how we do this recording/replaying of the cache traces. Does it really make sense to do it this way? If the cache config is the same, we could have just saved the state. If the config is different, how would we know what to play back where? Does it really restore to any sensible state? Andreas On 06/11/2014 17:45, Nilay Vaish ni...@cs.wisc.edu wrote: On Thu, 6 Nov 2014, Andreas Hansson wrote: Hi Nilay, I would really not like us to introduce yet another step in the initialisation process unless it is absolutely necessary. The steps done in the DRAM controller relies on curTick being set correctly, and to the best of my knowledge the first opportunity to do this is startup. I would prefer to stick to the rule that only functional transactions are allowed up till this point. We will not be able to load the checkpointed state only with functional reads and writes since functional accesses do not update coherence states in ruby controllers. But it seems we can limit timing accesses to the ruby portion and perform functional accesses to the dram. This should allow use to keep the dram ctrl same as it is now. I think the best solution would be if Ruby would load its state in loadState/unserialize without using timing transactions, but I do not have a good suggestion for how to make this happen. Additionally, how do we even know what transactions to play back when it is done in startup today? We just issue read for all the addresses that are part of the checkpointed cache state. -- Nilay -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression --scratch all
* build/SPARC/tests/opt/long/fs/80.solaris-boot/sparc/solaris/t1000-simple-atomic CHANGED! * build/X86/tests/opt/long/fs/10.linux-boot/x86/linux/pc-o3-timing CHANGED! scons: *** Error 1 scons: *** Error 1 scons: *** Error 124 * build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA/tests/opt/long/se/70.twolf/alpha/tru64/minor-timing passed. * build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-o3 passed. * build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA/tests/opt/long/se/50.vortex/alpha/tru64/o3-timing passed. * build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-switcheroo-full passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA/tests/opt/long/se/50.vortex/alpha/tru64/simple-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA/tests/opt/long/se/50.vortex/alpha/tru64/simple-atomic passed. * build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-minor passed. * build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-o3-dual passed. * build/ALPHA/tests/opt/long/se/60.bzip2/alpha/tru64/simple-atomic passed. * build/ALPHA/tests/opt/long/se/40.perlbmk/alpha/tru64/simple-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/minor-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing passed. * build/ALPHA/tests/opt/long/se/30.eon/alpha/tru64/o3-timing passed. * build/ALPHA/tests/opt/long/se/30.eon/alpha/tru64/simple-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA/tests/opt/long/se/30.eon/alpha/tru64/minor-timing passed. * build/ALPHA/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA/tests/opt/long/se/50.vortex/alpha/tru64/minor-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing passed. * build/ALPHA/tests/opt/long/se/70.twolf/alpha/tru64/simple-atomic passed. * build/ALPHA/tests/opt/long/se/20.parser/alpha/tru64/minor-timing passed. * build/ALPHA/tests/opt/quick/fs/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA/tests/opt/long/se/70.twolf/alpha/tru64/simple-timing passed. * build/ALPHA/tests/opt/long/se/40.perlbmk/alpha/tru64/simple-atomic passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing passed. * build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA/tests/opt/long/se/70.twolf/alpha/tru64/o3-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA/tests/opt/long/se/30.eon/alpha/tru64/simple-atomic passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA/tests/opt/long/se/60.bzip2/alpha/tru64/simple-timing passed. * build/ALPHA/tests/opt/long/se/40.perlbmk/alpha/tru64/minor-timing passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MESI_Two_Level passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MESI_Two_Level passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MESI_Two_Level passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MESI_Two_Level passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. *
Re: [gem5-dev] Review Request 2209: ruby: single physical memory in fs mode
On Sun, 9 Nov 2014, George Voicu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2209/#review5449 --- The connection of the ruby io port to the PIO bus in fs.py (line 167) should be done only once, outside of the cpus for loop. You are right. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] [gem5-users] Instcount =1500 failing for a single core full system simulation
1) I tried running the stable version of gem5. I used the latest ARM images to see if full system simulation is happening. These images are unmodified. I use the following command - /research/uthakker/gem5/gem5-stable/build/ARM/gem5.opt configs/example/fs.py --caches --cpu-type=DerivO3CPU --num-cpus=1 /_--machine-type=VExpress_EMM64__--disk-image=/research/uthakker/gem5/arm_october_2014/disks/aarch64-ubuntu-trusty-headless.img__--kernel=vmlinux.aarch64.20140821 --dtb-filename=vexpress.aarch64.20140821.dtb_/ --mem-size=2GB I get the following error while booting - /fatal: Unable to find destination for addr 0x2f001002 on bus system.iobus @ tick 12550512894000 [findPort:build/ARM/mem/bus.cc, line 353] Last few lines of system.terminal are [ 3.139624] pci :00:10.0: reg 0x14: [io 0x-0x0003] [ 3.139633] pci :00:10.0: reg 0x18: [io 0x-0x0007] [ 3.139643] pci :00:10.0: reg 0x1c: [io 0x-0x0003] [ 3.139652] pci :00:10.0: reg 0x20: [io 0x-0x000f] [ 3.139661] pci :00:10.0: reg 0x30: [mem 0x-0x07ff pref] [ 3.139695] pci_bus :00: fixups for bus [ 3.139703] pci_bus :00: bus scan returning with max=00 [ 3.139713] pci :00:00.0: calling quirk_e100_interrupt+0x0/0x1cc [ 3.139729] pci :00:00.0: fixup irq: got 33 [ 3.139737] pci :00:00.0: assigning IRQ 33 [ 3.139746] pci :00:10.0: fixup irq: got 34 [ 3.139753] pci :00:10.0: assigning IRQ 34 [ 3.139762] pci :00:00.0: BAR 0: assigned [mem 0x4000-0x4001] [ 3.139773] pci :00:00.0: BAR 6: assigned [mem 0x4002-0x400207ff pref] [ 3.139784] pci :00:10.0: BAR 6: assigned [mem 0x40020800-0x40020fff pref] [ 3.139795] pci :00:10.0: BAR 4: assigned [io 0x1000-0x100f] [ 3.139805] pci :00:10.0: BAR 0: assigned [io 0x1010-0x1017] [ 3.139815] pci :00:10.0: BAR 2: assigned [io 0x1018-0x101f] [ 3.139826] pci :00:10.0: BAR 1: assigned [io 0x1020-0x1023] [ 3.139836] pci :00:10.0: BAR 3: assigned [io 0x1024-0x1027] [ 3.140559] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 3.140871] ata_piix :00:10.0: version 2.13 [ 3.140880] ata_piix :00:10.0: enabling device ( - 0001) /_How do I start debugging this issue? _// 2) I am also trying to debug the instruction count 1500 error while running the modified arm image on gem5-dev codebase. This issue is also reached while the boot process is still on. The gem5 codebase is the latest one. I will try and see where the instructions are getting clogged and see if I could debug this issue. On 11/07/14 12:54, Ali Saidi wrote: Are you using the latest gem5 code? How long does it take for you to reach this issue? The issue is that these instructions have been created, but they haven't been deleted. This means that some resource in the pipeline is holding a reference to the instruction and it's not being deleted, the question is why and which resource. If you run the debug version of gem5 you'll get a list of which instructions haven't been deleted and then you can use those instruction serial numbers to see where they've gone in the pipeline and how the got lost. Thanks, Ali On 06.11.2014 20:17, Urmish Ajit Thakker via gem5-users wrote: Hi, I was running the full system simulation for the newly released arm 64 kernel and image. While running the simulation I encountered the following error - gem5.opt: build/ARM/cpu/base_dyn_inst_impl.hh:123: void BaseDynInst template-parameter-1-1 ::initVars() [with Impl = O3CPUImpl]: Assertion `cpu-instcount = 1500' failed. The number of CPUs I use for simulation is only one (I use the dtb file part of the download package). I have seen some related issues on the gem5 mailing list but from what I gathered they seem to be for multicore scenario. This is the command that I give to run the simulation - build/ARM/gem5.opt configs/example/fs.py --caches --cpu-type=DerivO3CPU --num-cpus=1 --machine-type=VExpress_EMM64 --disk-image=/research/uthakker/gem5/arm_october_64/disks/arm_8gb --kernel=vmlinux.aarch64.20140821 --dtb-filename=vexpress.aarch64.20140821.dtb --script=/research/uthakker/gem5/gem5/configs/boot/openCV.rcs Any pointers as to why is this happening or how should I start debugging this isssue? Regards, Urmish ___ gem5-users mailing list gem5-us...@gem5.org mailto:gem5-us...@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Assertion `!delayedResponse' failed, In X86 FS simulation
If you aren't in 64 bit mode, or you are and the instruction had the
address size prefix, virtual addresses are at most 32 bits long.
Gabe
On Sat, Nov 8, 2014 at 8:58 PM, Mohammad Alian via gem5-dev
gem5-dev@gem5.org wrote:
Hello,
I found the error source. This assertion goes up when the page table
walker inserts an entry into TLB and when it do a second lookup to get that
entry, it's not available. The problem is that when walker calls
tlb-translate(), the request matches for the following if condition and
it's vaddr gets masked; Therefore nothing will match with the masked vaddr
in the TLB:
if (m5Reg.submode != SixtyFourBitMode ||
(flags (AddrSizeFlagBit FlagShift))){
vaddr = mask(32);
Does anybody knows the purpose of the above if statement? Any fix to this
bug?
Thank you,Mohammad
On Wednesday, October 29, 2014 10:18 PM, Mohammad Alian
alian.moham...@yahoo.com wrote:
Hello every one,
I'm running some map-reduce benchmarks on X86 FS Dual mode. I can run the
benchmark with atomic simple cpu, but when I use O3 cpu, after simulating
around 3 seconds, I get the following error . Also I should mention that
I've hardcoded PCI accesses to be uncacheable to be able to start detailed
simulation Re: [gem5-dev] Ethernet device doesn't work with O3 cpu model in
X86 ISA.
Any help?
Thank you,Mohammad
switching cpus
REAL SIMULATION
warn: instruction 'prefetch_nta' unimplemented
warn: instruction 'prefetch_nta' unimplemented
warn: instruction 'prefetch_nta' unimplemented
warn: instruction 'prefetch_nta' unimplemented
warn: instruction 'prefetch_nta' unimplemented
warn: instruction 'prefetch_nta' unimplemented
warn: instruction 'prefetch_nta' unimplemented
warn: instruction 'prefetch_nta' unimplemented
warn: instruction 'prefetch_nta' unimplemented
warn: instruction 'prefetch_nta' unimplemented
warn: instruction 'prefetch_nta' unimplemented
warn: Tried to clear PCI interrupt 10
warn: instruction 'fild' unimplemented
warn: instruction 'fistp' unimplemented
warn: instruction 'fucomi' unimplemented
warn: instruction 'fsubrp' unimplemented
warn: instruction 'fistp' unimplemented
warn: instruction 'fistp' unimplemented
warn: instruction 'prefetch_nta' unimplemented
warn: instruction 'prefetch_nta' unimplemented
warn: instruction 'clflush' unimplemented
warn: instruction 'fcmovne' unimplemented
warn: instruction 'fucomip' unimplemented
warn: instruction 'prefetch_nta' unimplemented
warn: instruction 'prefetch_nta' unimplemented
warn: instruction 'prefetch_nta' unimplemented
warn: instruction 'prefetch_nta' unimplemented
warn: instruction 'prefetch_nta' unimplemented
warn: instruction 'prefetch_nta' unimplemented
warn: instruction 'prefetch_nta' unimplemented
warn: instruction 'prefetch_nta' unimplemented
warn: x86 cpuid: unimplemented function 4
gem5.opt: build/X86/arch/x86/pagetable_walker.cc:630: bool
X86ISA::Walker::WalkerState::recvPacket(PacketPtr): Assertion
`!delayedResponse' failed.
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] SSE decoding ability of the x86 decoder
Do you have a small test program that demonstrates the bug? If so, please send it to me. Gabe On Sat, Nov 8, 2014 at 10:00 AM, Ahmed Khawaja via gem5-dev gem5-dev@gem5.org wrote: Greetings, I am trying to run an SSE-enabled program through GEM5 in SE mode and I get an error about panic: Tried to read unmpapped address 0x130c1c0, I disassembled my program and ran gem5 with instruction tracing. The offending instruction does NOT appear in the disassembled code. The interesting thing to note is I added an implementation of the PEXTRB instruction and the offending instruction (which shouldn't) is directly after the first PEXTRB instruction is executed (it only shows 1 being executed, though in the source code they only appear in sequences of 8 PEXTRB instrucitons in a row). I am lead to believe this is an issue with the front end decoder, can anyone tell me if my diagnosis seems correct and what level of confidence should I expect in the front end decoder for an instruction that was NOT implemented. Thank you, Ahmed Khawaja ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
