[gem5-users] Debug flag DRAMPower
Hi, I have been running with the debug flag option for DRAMPower for memory power consumption however I noticed that there are no writes in any of the traces generated no matter the CPU type, seems write commands does not get registered from mem_cntrls. Best Regards Hussain ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] svc Instruction
At the end of svc instruction, R0 is being updated. On what case is R0 changed? Thanks V Vanchinathan On Thu, Aug 28, 2014 at 2:20 PM, Vanchinathan Venkataramani dcsv...@nus.edu.sg wrote: At the end of svc instruction, R0 is being updated. On what case is R0 changed? Thanks V Vanchinathan On Wed, Aug 27, 2014 at 5:23 PM, Vanchinathan Venkataramani dcsv...@gmail.com wrote: Hi all I would like to know how svc (trap) instruction is implemented in gem5. In particular I want to know on what condition the register values are changed when svc syscall is present. Thanks a lot! ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Big executed instruction difference between X86 atomic adn X86 O3
Hi Yan, Check out: http://reviews.gem5.org/r/2369/ Perhaps the problem you are struggling with is even more complex, but at least the patches on the review board should fix up a few issues. Andreas On 28/08/2014 03:27, Zi Yan via gem5-users gem5-users@gem5.org wrote: Hi Mitch, After I applied two patches and IsQuiesce modification, O3 CPU keeps in the same track as atomic CPU longer than before. But apic_timer_interrupt function comes out again in O3 CPU. It used to come out after about 500,000 instructions, now it comes out after about 990,000 instructions. In addition, I dump out tick numbers as well as PCs, so that I find out there is a 459500 ticks gap between last committed user instruction and first instruction in apic_timer_interrupt function. This confirms that the last user instruction sits in commit until timer interrupt happens. Am I right about this? Next step, I think I need to label all x86 quiesce instructions. Do you have a list of those instructions? Or does somewhere in Intel manual tell me about this? Thanks. -- Best Regards Yan Zi On 27 Aug 2014, at 15:59, Mitch Hayenga wrote: Yep, that should do it. On Wed, Aug 27, 2014 at 2:57 PM, Zi Yan birdman...@gmail.com wrote: Thanks. I will apply 1, and 2 patches. For 3, I need to change the file src/arch/x86/isa/microops/specop.isa:66 from setFlags | (ULL(1) StaticInst::IsNonSpeculative), to setFlags | (ULL(1) StaticInst::IsNonSpeculative) | (ULL(1) StaticInst::IsQuiesce), Am I doing the right thing to tag MicroHalt instruction as IsQuiesce? BTW, what I did to boot linux is to install gentoo inside QEMU, then use x86KvmCPU to boot up, then take checkpoints and run from checkpoints. I will report whether this works or not. Thanks. -- Best Regards Yan Zi On 27 Aug 2014, at 15:44, Mitch Hayenga wrote: There are probably three main patches that could help. The fact you mention the timer interrupt makes me think Andreas is right and these might solve your issue. 1. http://reviews.gem5.org/r/2363/ - o3 is supposed to stop fetching instructions immediately once a quiesce instruction is encountered, some managed to sneak by. Quiesce is used for things like sleeping until an interrupt occurs, etc. Without this patch, we experienced the case where o3 state would get corrupted and an instruction would sit at commit until the next timer interrupt happened. At which point taking the interrupt would clear the state and execution would continue (until this same bug happened again). 2. http://reviews.gem5.org/r/2367/ - If o3 was being drained while an interrupt occurred on x86, it could deadlock. 3. I believe this last patch will be posted in a day or two. x86 currently does not tag any instruction that suspends() the CPU as a quiesce. This is required by o3 to properly operate, but not by the Atomic CPU. This makes the issue in #1 far more likely to occur. It's pretty amazing that x86 booted linux at all on o3 without this. I believe this patch will be posted shortly, but otherwise you could just tag the MicroHalt instruction as IsQuiesce yourself. So a combination of those things (mainly the last one) could lead to what you are seeing. On Wed, Aug 27, 2014 at 12:59 PM, Zi Yan via gem5-users gem5-users@gem5.org wrote: OK. Could you please tell me which patches are there? In the review board there are quite a lot of new patches waiting for review. I can apply those patches myself and do a quick test. Thanks. -- Best Regards Yan Zi On 27 Aug 2014, at 13:56, Andreas Hansson wrote: Hi Yan, I would suspect this is due to a bug in the X86 O3 CPU. There have been quite a few fixes posted on the review board for similar issues. I hope to have these committed in the next week or so. Andreas On 27/08/2014 18:02, Zi Yan via gem5-users gem5-users@gem5.org wrote: Hi all, I am running kmeans via hadoop in gem5 X86 FS mode. I am using linux kernel 3.2.60 with configuration file linux-2.6.28.4 from gem5.org. I take a checkpoint before a map task and put a m5 exit after the map task. I am using *X86kvmCPU* to take checkpoints. When I restore from the same checkpoint, atomic CPU and O3 CPU give me quite different executed instructions: 1) atomic CPU executes about 350 million instructions, reaches m5 exit, then stops simulation. 2) O3 CPU executes more than 12 billion instructions, and still not reaches m5 exit to stop the simulation. I dump out committed PCs from atomic CPU and O3 CPU, finding out that after about 500,000 instructions, the systems behave differently, where atomic CPU is still executing user code, but O3 CPU switch to apic_timer_interrupt(a kernel function, it also appears in atomic CPU execution, but somewhere else). Could anyone please give some advice about why this happen? Thanks. -- Best Regards Yan Zi -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be
Re: [gem5-users] Debug flag DRAMPower
Hi Hussain, Write should work just fine. Are you sure there are actually any writes coming from the L2? Andreas From: Hussain Asad via gem5-users gem5-users@gem5.orgmailto:gem5-users@gem5.org Reply-To: Hussain Asad x7xcloudstr...@gmail.commailto:x7xcloudstr...@gmail.com, gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org Date: Thursday, 28 August 2014 07:01 To: gem5-users@gem5.orgmailto:gem5-users@gem5.org gem5-users@gem5.orgmailto:gem5-users@gem5.org Subject: [gem5-users] Debug flag DRAMPower Hi, I have been running with the debug flag option for DRAMPower for memory power consumption however I noticed that there are no writes in any of the traces generated no matter the CPU type, seems write commands does not get registered from mem_cntrls. Best Regards Hussain -- 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-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Big executed instruction difference between X86 atomic adn X86 O3
Hi Andreas, I already flag MicroHalt as IsQuiesce in my last running. And I am not using m5ops, so first part of your patch should not affect my running. Therefore, as I mentioned in my last email, the waiting for apic_timer_interrupt behavior still happens for certain instructions. 1) Is every x86 quiesce marco instruction properly decoded with MicroHalt microop in gem5? 2) Does Intel ISA manual say anything about quiesce instruction? So that I can find a reference and help check all quiesce instructions in X86. Thanks. -- Best Regards Yan Zi On 28 Aug 2014, at 3:39, Andreas Hansson wrote: Hi Yan, Check out: http://reviews.gem5.org/r/2369/ Perhaps the problem you are struggling with is even more complex, but at least the patches on the review board should fix up a few issues. Andreas On 28/08/2014 03:27, Zi Yan via gem5-users gem5-users@gem5.org wrote: Hi Mitch, After I applied two patches and IsQuiesce modification, O3 CPU keeps in the same track as atomic CPU longer than before. But apic_timer_interrupt function comes out again in O3 CPU. It used to come out after about 500,000 instructions, now it comes out after about 990,000 instructions. In addition, I dump out tick numbers as well as PCs, so that I find out there is a 459500 ticks gap between last committed user instruction and first instruction in apic_timer_interrupt function. This confirms that the last user instruction sits in commit until timer interrupt happens. Am I right about this? Next step, I think I need to label all x86 quiesce instructions. Do you have a list of those instructions? Or does somewhere in Intel manual tell me about this? Thanks. -- Best Regards Yan Zi On 27 Aug 2014, at 15:59, Mitch Hayenga wrote: Yep, that should do it. On Wed, Aug 27, 2014 at 2:57 PM, Zi Yan birdman...@gmail.com wrote: Thanks. I will apply 1, and 2 patches. For 3, I need to change the file src/arch/x86/isa/microops/specop.isa:66 from setFlags | (ULL(1) StaticInst::IsNonSpeculative), to setFlags | (ULL(1) StaticInst::IsNonSpeculative) | (ULL(1) StaticInst::IsQuiesce), Am I doing the right thing to tag MicroHalt instruction as IsQuiesce? BTW, what I did to boot linux is to install gentoo inside QEMU, then use x86KvmCPU to boot up, then take checkpoints and run from checkpoints. I will report whether this works or not. Thanks. -- Best Regards Yan Zi On 27 Aug 2014, at 15:44, Mitch Hayenga wrote: There are probably three main patches that could help. The fact you mention the timer interrupt makes me think Andreas is right and these might solve your issue. 1. http://reviews.gem5.org/r/2363/ - o3 is supposed to stop fetching instructions immediately once a quiesce instruction is encountered, some managed to sneak by. Quiesce is used for things like sleeping until an interrupt occurs, etc. Without this patch, we experienced the case where o3 state would get corrupted and an instruction would sit at commit until the next timer interrupt happened. At which point taking the interrupt would clear the state and execution would continue (until this same bug happened again). 2. http://reviews.gem5.org/r/2367/ - If o3 was being drained while an interrupt occurred on x86, it could deadlock. 3. I believe this last patch will be posted in a day or two. x86 currently does not tag any instruction that suspends() the CPU as a quiesce. This is required by o3 to properly operate, but not by the Atomic CPU. This makes the issue in #1 far more likely to occur. It's pretty amazing that x86 booted linux at all on o3 without this. I believe this patch will be posted shortly, but otherwise you could just tag the MicroHalt instruction as IsQuiesce yourself. So a combination of those things (mainly the last one) could lead to what you are seeing. On Wed, Aug 27, 2014 at 12:59 PM, Zi Yan via gem5-users gem5-users@gem5.org wrote: OK. Could you please tell me which patches are there? In the review board there are quite a lot of new patches waiting for review. I can apply those patches myself and do a quick test. Thanks. -- Best Regards Yan Zi On 27 Aug 2014, at 13:56, Andreas Hansson wrote: Hi Yan, I would suspect this is due to a bug in the X86 O3 CPU. There have been quite a few fixes posted on the review board for similar issues. I hope to have these committed in the next week or so. Andreas On 27/08/2014 18:02, Zi Yan via gem5-users gem5-users@gem5.org wrote: Hi all, I am running kmeans via hadoop in gem5 X86 FS mode. I am using linux kernel 3.2.60 with configuration file linux-2.6.28.4 from gem5.org. I take a checkpoint before a map task and put a m5 exit after the map task. I am using *X86kvmCPU* to take checkpoints. When I restore from the same checkpoint, atomic CPU and O3 CPU give me quite different executed instructions: 1) atomic CPU executes about 350 million instructions, reaches m5 exit,
Re: [gem5-users] How many cpu does the x86 vmlinux SMP kernel support?
Hi Andreas, I tried the alpha first. I found I have set up this ISA and I rebuild it for this test. It can only support 4 timing simple alpha cores. And when I set the number of cpu to 5, the m5 terminal output indicates CPU #4 (which is the 5th cpu) is stuck. So can I say it can only support 4 cpu? What should I do if I want to support more (like 16) cpus in classical memory system with alpha timing core? Thanks! On Aug 27, 2014, at 3:48 PM, Andreas Hansson andreas.hans...@arm.com wrote: Hi Chao, Unfortunately the classic memory system does not support X86 atomic RMW operations. This is why it works in atomic and not in timing. You options are: 1) implement a fix and do everyone a big favour (I vote for this one) 2) take the hit in simulation speed and switch to Ruby and stick to timing mode 3) use another ISA, e.g. ARM :-), that does not have this problem I hope that explains it. Andreas From: Chao Zhang via gem5-users gem5-users@gem5.org Reply-To: Chao Zhang zhang.c...@pku.edu.cn, gem5 users mailing list gem5-users@gem5.org Date: Wednesday, 27 August 2014 07:47 To: gem5 users mailing list gem5-users@gem5.org Subject: [gem5-users] How many cpu does the x86 vmlinux SMP kernel support? Dear all, I’m currently working on x86 FS on classical memory system to simulate cache system. But I found the kernel booting just hangs before loading benchmark script. It does not work when I set 3 or more x86 timing simple cpus, but it does work when I set them as atomic cores. And it also works when I set cpu number to 1. The gem5 change set version is 10242, the kernel is the SMP version from gem5 website (x86_64-vmlinux-2.6.28.4-smp), and I use default fs.py configuration. So I want to know how many x86 timing cores does this SMP kernel support? Or is this a memory system problem? Chao Zhang Peking University -- 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-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] How to add shared nonblocking L3 cache in gem5?
Thanks Andreas. I have one more question regarding cache. Is it posible to create a system with multiple L2 caches each private to a specific core? On Wed, Aug 27, 2014 at 2:51 AM, Andreas Hansson andreas.hans...@arm.com wrote: Hi Prathap, You can easily create a subclass of the BaseCache and give it suitable parameters for an L3. This should be fairly straight forward and also easy to instantiate in the Python scripts (e.g. fs.py) Andreas From: Prathap Kolakkampadath via gem5-users gem5-users@gem5.org Reply-To: Prathap Kolakkampadath kvprat...@gmail.com, gem5 users mailing list gem5-users@gem5.org Date: Wednesday, 27 August 2014 05:25 To: gem5 users mailing list gem5-users@gem5.org Subject: [gem5-users] How to add shared nonblocking L3 cache in gem5? Hi Users, I am new to gem5 and I want to add nonblacking shared Last level cache(L3). I could see L3 cache options in Options.py with default values set. However there is no entry for L3 in Caches.py and CacheConfig.py. So extending Cache.py and CacheConfig.py would be enough to create L3 cache? Thanks, Prathap -- 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-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] How to add shared nonblocking L3 cache in gem5?
Hi Prathap, Definitely. The gem5 memory system let’s you build any tree-topology you like, even unbalanced (L2 for one core, and no L2 for another etc, 2 core for one L2 and a single core for the next). Just instantiate an L2 per core, connect it with a CoherentBus to the L1s of that core, and then use a CoherentBus on the memory-side of the L2 to “merge” the tree into the L3 (or use split L3’s as well). If you’ve got pydot installed gem5 generates a PDF/SVG showing the system layout to visually ensure you’ve accomplished what you intended. Andreas From: Prathap Kolakkampadath kvprat...@gmail.commailto:kvprat...@gmail.com Date: Thursday, 28 August 2014 17:47 To: Andreas Hansson andreas.hans...@arm.commailto:andreas.hans...@arm.com Cc: gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org Subject: Re: [gem5-users] How to add shared nonblocking L3 cache in gem5? Thanks Andreas. I have one more question regarding cache. Is it posible to create a system with multiple L2 caches each private to a specific core? On Wed, Aug 27, 2014 at 2:51 AM, Andreas Hansson andreas.hans...@arm.commailto:andreas.hans...@arm.com wrote: Hi Prathap, You can easily create a subclass of the BaseCache and give it suitable parameters for an L3. This should be fairly straight forward and also easy to instantiate in the Python scripts (e.g. fs.py) Andreas From: Prathap Kolakkampadath via gem5-users gem5-users@gem5.orgmailto:gem5-users@gem5.org Reply-To: Prathap Kolakkampadath kvprat...@gmail.commailto:kvprat...@gmail.com, gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org Date: Wednesday, 27 August 2014 05:25 To: gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org Subject: [gem5-users] How to add shared nonblocking L3 cache in gem5? Hi Users, I am new to gem5 and I want to add nonblacking shared Last level cache(L3). I could see L3 cache options in Options.py with default values set. However there is no entry for L3 in Caches.py and CacheConfig.py. So extending Cache.py and CacheConfig.py would be enough to create L3 cache? Thanks, Prathap -- 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 -- 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-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] How to add shared nonblocking L3 cache in gem5?
In that case whether the MSHR's would be shared between 2 L2 Caches or can have separate MSHR for each L2 cache? Thanks. On Thu, Aug 28, 2014 at 11:52 AM, Andreas Hansson andreas.hans...@arm.com wrote: Hi Prathap, Definitely. The gem5 memory system let’s you build any tree-topology you like, even unbalanced (L2 for one core, and no L2 for another etc, 2 core for one L2 and a single core for the next). Just instantiate an L2 per core, connect it with a CoherentBus to the L1s of that core, and then use a CoherentBus on the memory-side of the L2 to “merge” the tree into the L3 (or use split L3’s as well). If you’ve got pydot installed gem5 generates a PDF/SVG showing the system layout to visually ensure you’ve accomplished what you intended. Andreas From: Prathap Kolakkampadath kvprat...@gmail.com Date: Thursday, 28 August 2014 17:47 To: Andreas Hansson andreas.hans...@arm.com Cc: gem5 users mailing list gem5-users@gem5.org Subject: Re: [gem5-users] How to add shared nonblocking L3 cache in gem5? Thanks Andreas. I have one more question regarding cache. Is it posible to create a system with multiple L2 caches each private to a specific core? On Wed, Aug 27, 2014 at 2:51 AM, Andreas Hansson andreas.hans...@arm.com wrote: Hi Prathap, You can easily create a subclass of the BaseCache and give it suitable parameters for an L3. This should be fairly straight forward and also easy to instantiate in the Python scripts (e.g. fs.py) Andreas From: Prathap Kolakkampadath via gem5-users gem5-users@gem5.org Reply-To: Prathap Kolakkampadath kvprat...@gmail.com, gem5 users mailing list gem5-users@gem5.org Date: Wednesday, 27 August 2014 05:25 To: gem5 users mailing list gem5-users@gem5.org Subject: [gem5-users] How to add shared nonblocking L3 cache in gem5? Hi Users, I am new to gem5 and I want to add nonblacking shared Last level cache(L3). I could see L3 cache options in Options.py with default values set. However there is no entry for L3 in Caches.py and CacheConfig.py. So extending Cache.py and CacheConfig.py would be enough to create L3 cache? Thanks, Prathap -- 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 -- 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-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] ARMv8 Client-Server configuration
You should be able to get a new working kernel with PCIe support for AArch64 like the following, however you’ll need all the patches that Andreas just mentioned in an email to gem5-dev as committed next week. wget http://www.linux-arm.org/git?p=linux-aarch64-gem5.git;a=snapshot;h=400390889828685d432d38406cbd9c7afceeaa15;sf=tgz; -O linux-aarch64-gem5.tgz tar zxvf linux-aarch64-gem5.tgz cd linux-aarch64-gem5-4003908 make ARCH=arm64 CROSS_COMPILE=aarch64-none-elf- gem5_defconfig make ARCH=arm64 CROSS_COMPILE=aarch64-none-elf- -j4 Thanks, Ali From: Ali Saidi via gem5-users gem5-users@gem5.orgmailto:gem5-users@gem5.org Reply-To: Ali Saidi sa...@umich.edumailto:sa...@umich.edu, gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org Date: Saturday, August 23, 2014 at 2:21 PM To: Ivan Stalev ids...@psu.edumailto:ids...@psu.edu, gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org Subject: Re: [gem5-users] ARMv8 Client-Server configuration You’re not going to have any support for PCIe device with that kernel. We’re working on the last bit of debugging and polishing around a kernel that will support it — I intended to have it out 2 weeks ago, but we’re still diligently working and it should be out in the next couple of days. Ali On Aug 20, 2014, at 10:36 AM, Ivan Stalev ids...@psu.edumailto:ids...@psu.edu wrote: Edit: I was using my own compiled kernel. I am now using the default kernel, vmlinux-3.14-aarch64-vexpress-emm64, and it appears not to crash. I will go ahead and test it out. On Wed, Aug 20, 2014 at 11:19 AM, Ivan Stalev ids...@psu.edumailto:ids...@psu.edu wrote: Hi Andreas, No problem, I figured it wasn't the 80 char README file patch :) I applied the 7 patches you posted this morning, but now when I run in dual mode, gem5 crashes with this: panic: M5 panic instruction called at pc=0xffc8a024. @ tick 58408160 [execute:build/ARM/arch/arm/generated/exec-ns.cc.inc, line 241403] The GDB backtrace from gem5.debug suggests that execution is somehow killed from a manually inserted breakpoint. This is also after I had to hardcode the DTB file name for the drivesys in /src/arch/arm/linux/system.cchttp://system.cc since it was not picking it up from the command line... warn: Kernel supports device tree, but no DTB file specified fatal: Expected a single ATAG memory entry but got 3 @ tick 58402784 [initState:build/ARM/arch/arm/linux/system.cchttp://system.cc, line 202] Can you share how you tested the client-server configuration? Thank you, Ivan On Wed, Aug 20, 2014 at 4:45 AM, Andreas Hansson andreas.hans...@arm.commailto:andreas.hans...@arm.com wrote: Hi Ivan, Just following up on this one. I posted the patches yesterday morning, but forgot to “Publish” then. Sorry about the misunderstanding. They are all there now. Andreas From: Andreas Hansson via gem5-users gem5-users@gem5.orgmailto:gem5-users@gem5.org Reply-To: Andreas Hansson andreas.hans...@arm.commailto:andreas.hans...@arm.com, gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org Date: Tuesday, 19 August 2014 18:48 To: Ivan Stalev ids...@psu.edumailto:ids...@psu.edu, gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org, Ali Saidi sa...@umich.edumailto:sa...@umich.edu Subject: Re: [gem5-users] ARMv8 Client-Server configuration Hi Ivan, The patches are on the review board as of this morning (UK time). Comments are welcome as always. Andreas From: Ivan Stalev via gem5-users gem5-users@gem5.orgmailto:gem5-users@gem5.org Reply-To: Ivan Stalev ids...@psu.edumailto:ids...@psu.edu, gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org Date: Tuesday, 19 August 2014 18:44 To: Ali Saidi sa...@umich.edumailto:sa...@umich.edu Cc: gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org Subject: Re: [gem5-users] ARMv8 Client-Server configuration Hi Ali, Have you had the chance to look at the issue or have some suggestions as to which source files to look at? Thanks, Ivan On Fri, Aug 8, 2014 at 8:34 PM, Ali Saidi sa...@umich.edumailto:sa...@umich.edu wrote: Hi Ivan, The kernel that you’re using and the currently gem5 don’t support pci devices with arm64. I hope to remedy this within a week. Thanks, Ali On Aug 6, 2014, at 3:42 PM, Ivan Stalev via gem5-users gem5-users@gem5.orgmailto:gem5-users@gem5.org wrote: Hi everyone, I am trying to run a client-server setup using arm64. I am using the (latest) linaro kernel (3.16) and disk image suggested on the GEM5 downloads page. Simply building the kernel with defconfig (as recommended in the README) does not seem to setup the ethernet drivers. Running ifconfig -a only yields the loopback device/interface. I then opened up the .config (generated by defconfig) using menuconfig and enabled all the settings related to ethernet and re-built the kernel. After booting, ifconfig -a results in this: bond0 Link encap:Ethernet HWaddr
Re: [gem5-users] Big executed instruction difference between X86 atomic adn X86 O3
Hi, As far as I know those are the only instructions that call suspend() on a thread context in gem5 for the x86 ISA. This is all I found from grepping the src/arch/x86 directories. But I'm not an expert on the x86 ISA, I just touched this code because it was breaking regression tests. The 459500 ticks isn't really all that large terms of time. Assuming you're running a 2GHz core (this number is in pico seconds), thats only 919 cycles. This could easily be explained by having to walk a page table, branch mispredicts, etc when entering a new region of code. The atomic CPU wouldn't have to pay any of that time cost (since memory is accessed instantaneously on it and there are no mispredicts). It also could be that the last instruction was the MicroHalt, and it only took 900 cycles for the core to be woken up. No way to know without looking at what actually happened. How are you measuring the divergence to know things are going wrong in simulation? The timings/code scheduling done by the OS can be very different for the Atomic and Timing-focused cores. Basically, different sequences of committed instructions from atomic and o3 are fine, as long as the numbers are not completely out of line. On Thu, Aug 28, 2014 at 5:49 AM, Zi Yan via gem5-users gem5-users@gem5.org wrote: Hi Andreas, I already flag MicroHalt as IsQuiesce in my last running. And I am not using m5ops, so first part of your patch should not affect my running. Therefore, as I mentioned in my last email, the waiting for apic_timer_interrupt behavior still happens for certain instructions. 1) Is every x86 quiesce marco instruction properly decoded with MicroHalt microop in gem5? 2) Does Intel ISA manual say anything about quiesce instruction? So that I can find a reference and help check all quiesce instructions in X86. Thanks. -- Best Regards Yan Zi On 28 Aug 2014, at 3:39, Andreas Hansson wrote: Hi Yan, Check out: http://reviews.gem5.org/r/2369/ Perhaps the problem you are struggling with is even more complex, but at least the patches on the review board should fix up a few issues. Andreas On 28/08/2014 03:27, Zi Yan via gem5-users gem5-users@gem5.org wrote: Hi Mitch, After I applied two patches and IsQuiesce modification, O3 CPU keeps in the same track as atomic CPU longer than before. But apic_timer_interrupt function comes out again in O3 CPU. It used to come out after about 500,000 instructions, now it comes out after about 990,000 instructions. In addition, I dump out tick numbers as well as PCs, so that I find out there is a 459500 ticks gap between last committed user instruction and first instruction in apic_timer_interrupt function. This confirms that the last user instruction sits in commit until timer interrupt happens. Am I right about this? Next step, I think I need to label all x86 quiesce instructions. Do you have a list of those instructions? Or does somewhere in Intel manual tell me about this? Thanks. -- Best Regards Yan Zi On 27 Aug 2014, at 15:59, Mitch Hayenga wrote: Yep, that should do it. On Wed, Aug 27, 2014 at 2:57 PM, Zi Yan birdman...@gmail.com wrote: Thanks. I will apply 1, and 2 patches. For 3, I need to change the file src/arch/x86/isa/microops/specop.isa:66 from setFlags | (ULL(1) StaticInst::IsNonSpeculative), to setFlags | (ULL(1) StaticInst::IsNonSpeculative) | (ULL(1) StaticInst::IsQuiesce), Am I doing the right thing to tag MicroHalt instruction as IsQuiesce? BTW, what I did to boot linux is to install gentoo inside QEMU, then use x86KvmCPU to boot up, then take checkpoints and run from checkpoints. I will report whether this works or not. Thanks. -- Best Regards Yan Zi On 27 Aug 2014, at 15:44, Mitch Hayenga wrote: There are probably three main patches that could help. The fact you mention the timer interrupt makes me think Andreas is right and these might solve your issue. 1. http://reviews.gem5.org/r/2363/ - o3 is supposed to stop fetching instructions immediately once a quiesce instruction is encountered, some managed to sneak by. Quiesce is used for things like sleeping until an interrupt occurs, etc. Without this patch, we experienced the case where o3 state would get corrupted and an instruction would sit at commit until the next timer interrupt happened. At which point taking the interrupt would clear the state and execution would continue (until this same bug happened again). 2. http://reviews.gem5.org/r/2367/ - If o3 was being drained while an interrupt occurred on x86, it could deadlock. 3. I believe this last patch will be posted in a day or two. x86 currently does not tag any instruction that suspends() the CPU as a quiesce. This is required by o3 to properly operate, but not by the Atomic CPU. This makes the issue in #1 far more likely to occur.
