[gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-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/tru64/minor-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA/tests/opt/quick/fs/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/o3-timing 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_MOESI_hammer/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer 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/00.hello/alpha/tru64/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_MESI_Two_Level/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-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. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-atomic passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby passed. * build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest-filter passed. * build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-dram-ctrl passed. * build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-simple-mem passed. * build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest passed. * build/POWER/tests/opt/quick/se/00.hello/power/linux/o3-timing passed. * build/POWER/tests/opt/quick/se/00.hello/power/linux/simple-atomic passed. * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-atomic passed. * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing passed. * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing-ruby passed. * build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/o3-timing passed. * build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/simple-atomic passed. *
[gem5-dev] Reading Memory Traces
Hello, I'm new to the Gem5 ! I want to read some pre-recorded memory traces (it's a file that contains a serie of memory access) with Gem5. I want to stress the interconnection network and the memories with it, I need precises simulations so I want to use the Ruby Simulator. I've starting to implement a CPU that just read an access on my memory trace and convert it into a request for Ruby, this is quite similar to the Ruby Tester that generate some traffic with randomly addresses. I don't know if some works have already been done in this direction. Anyway I'm having trouble with the address of my request, cause I recorded my memory traces on my computer so the addresses that I have recorded are 48-bits virtual addresses and I don't know how to convert it to physical addresses (which seem to be on 27 bits in my case ?) If anyone has a clue , or can point be to a better direction to stimulate the Ruby system with some pre-recorded file ? I can't use the TrafficGen generators if I use Ruby Systems right ? -- Grégory Vaumourin Doctorant - Phd Student Laboratoire Adéquation Algorithme Architecture -- Matching Algorithm Architecture Laboratory Phone: +33 (1) 69080069 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Reading Memory Traces
Hi Gregory, The traffic generators should work just fine with Ruby, and they already have trace players. There is nothing precluding you from using the non-Ruby memory system. Ruby gives you the option of having a more elaborate network topology, but if you are fine with crossbars the non-Ruby memory system is probably a more sensible starting point. gem5 also has trace capturing facilities through the CommMonitor, so if you capture the traces on gem5 it should be easy to replay them (and avoid the PA VA issues). Andreas On 20/02/2015 14:17, VAUMOURIN Grégory via gem5-dev gem5-dev@gem5.org wrote: Hello, I'm new to the Gem5 ! I want to read some pre-recorded memory traces (it's a file that contains a serie of memory access) with Gem5. I want to stress the interconnection network and the memories with it, I need precises simulations so I want to use the Ruby Simulator. I've starting to implement a CPU that just read an access on my memory trace and convert it into a request for Ruby, this is quite similar to the Ruby Tester that generate some traffic with randomly addresses. I don't know if some works have already been done in this direction. Anyway I'm having trouble with the address of my request, cause I recorded my memory traces on my computer so the addresses that I have recorded are 48-bits virtual addresses and I don't know how to convert it to physical addresses (which seem to be on 27 bits in my case ?) If anyone has a clue , or can point be to a better direction to stimulate the Ruby system with some pre-recorded file ? I can't use the TrafficGen generators if I use Ruby Systems right ? -- Grégory Vaumourin Doctorant - Phd Student Laboratoire Adéquation Algorithme Architecture -- Matching Algorithm Architecture Laboratory Phone: +33 (1) 69080069 ___ 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
Re: [gem5-dev] changeset in gem5: x86: Enable three bits in the FamilyModelStep...
Hi guys, I think I figure some of this out. The Wikipedia page on CPUID ( http://en.wikipedia.org/wiki/CPUID) indicates that xsave is bit 26 of ECX. Unsetting this bit allowed me to successfully boot these older versions of Linux. For anyone running into the same issue, here is the patch for that change: -- diff --git a/src/arch/x86/cpuid.cc b/src/arch/x86/cpuid.cc --- a/src/arch/x86/cpuid.cc +++ b/src/arch/x86/cpuid.cc @@ -154,7 +154,7 @@ break; case FamilyModelStepping: result = CpuidResult(0x00020f51, 0x0805, - 0xe7dbfbff, 0x04000209); + 0xe7dbfbff, 0x0209); break; default: warn(x86 cpuid: unimplemented function %u, funcNum); -- I also discovered that the reason Linux falls into this kernel panic is that it executes a CPUID operation that is not currently implemented in gem5 (src/arch/x86/cpuid.cc). Specifically, the cpuid_count function call (here: http://lxr.free-electrons.com/source/arch/x86/kernel/xsave.c?v=2.6.32#L319) tries to execute CPUID function EAX=0xd (13), EAX=0x0. gem5 prints a warning saying that this function is unimplemented, and does not update any registers, causing the resulting EAX to be incorrect. It looks like more recent Linux versions contain more checks, and so may not reach this cpuid_count call: http://lxr.free-electrons.com/source/arch/x86/kernel/xsave.c#L618 Joel On Fri, Feb 20, 2015 at 2:17 PM, Joel Hestness jthestn...@gmail.com wrote: Hey Gabe, When I try to boot older versions of Linux (2.6.28.4, 2.6.22.9), I'm running into a kernel panic related to xsave ( http://lxr.free-electrons.com/source/arch/x86/kernel/xsave.c?v=2.6.32#L323 ): *FP/SSE not shown under xsave features 0xd* [ cut here ] kernel BUG at arch/x86/kernel/xsave.c:323! invalid opcode: [#1] SMP last sysfs file: CPU 0 Modules linked in: Pid: 0, comm: swapper Tainted: GW 2.6.28-rc4-dirty #5 RIP: 0010:[808d69e7] [808d69e7] xsave_cntxt_init+0x35/0x130 RSP: 0018:808c3f18 EFLAGS: 00b8 RAX: 002d RBX: 808c3f48 RCX: RDX: 807c3c38 RSI: 0074 RDI: 8094a5f4 RBP: R08: R09: 03fd R10: R11: R12: 807a8340 R13: 0005 R14: 8800 R15: 88000101f000 FS: () GS:808bd980() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 80050033 CR2: CR3: 00201000 CR4: 06a0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: Process swapper (pid: 0, threadinfo 808c2000, task 807a8340) Stack: 808c3f48 8060e2b1 0010 8060fa3f 0020 fff0 0100890239802087 8800 808c3f88 0040 808f7700 Call Trace: [8060e2b1] fpu_init+0x4a/0x97 [8060fa3f] cpu_init+0x319/0x33f [808cdab5] start_kernel+0x1b2/0x321 [808cd405] x86_64_start_kernel+0xd9/0xdd Code: 48 c1 e2 20 89 c0 48 8d 34 02 48 89 f0 48 89 35 90 96 05 00 83 e0 03 48 83 f8 03 74 12 48 c7 c7 10 82 71 80 31 c0 e8 4d e6 d3 ff 0f 0b eb fe f6 05 b5 70 fe ff 04 48 c7 05 63 96 05 00 03 00 00 RIP [808d69e7] xsave_cntxt_init+0x35/0x130 RSP 808c3f18 ---[ end trace 4eaa2a86a8e2da22 ]--- Kernel panic - not syncing: Attempted to kill the idle task! [ cut here ] WARNING: at kernel/smp.c:333 smp_call_function_mask+0x1de/0x250() Modules linked in: Pid: 0, comm: swapper Tainted: G D W 2.6.28-rc4-dirty #5 Call Trace: [8023af92] warn_on_slowpath+0x62/0xa0 [803a4159] vsnprintf+0x449/0x6b0 [803a3a84] string+0x34/0xf0 [803a4118] vsnprintf+0x408/0x6b0 [802547dd] up+0xd/0x40 [8023b6de] release_console_sem+0x1ae/0x200 [8021ef40] stop_this_cpu+0x0/0x30 [8025db9e] smp_call_function_mask+0x1de/0x250 [803a3f78] vsnprintf+0x268/0x6b0 [80615074] printk+0x40/0x45 [8021ef30] native_smp_send_stop+0x20/0x30 [80614f8d] panic+0x82/0x129 [8023ecae] do_exit+0x7de/0x890 [80615074] printk+0x40/0x45 [806184ba] oops_end+0x7a/0xc0 [8020d3d4] do_invalid_op+0x84/0xa0 [808d69e7] xsave_cntxt_init+0x35/0x130 [8023b6de] release_console_sem+0x1ae/0x200 [802547dd] up+0xd/0x40 [806178e9] error_exit+0x0/0x51 [808d69e7] xsave_cntxt_init+0x35/0x130 [808d69e7]
[gem5-dev] Review Request 2669: config: Add --sst configuration option
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2669/ --- Review request for Default. Repository: gem5 Description --- Changeset 10710:98bd34bb7a39 --- config: Add --sst configuration option This new option expands to the following: --external-memory-system --initialize-only These are required when running gem5 within SST. Diffs - configs/common/Options.py c6cb94a14fea4c59780d73d1623d7031bcede6af ext/sst/tests/test6_arm_4c.py PRE-CREATION Diff: http://reviews.gem5.org/r/2669/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2665: sim: Reuse the same limit_event in simulate()
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/ --- Review request for Default. Repository: gem5 Description --- Changeset 10706:e77f25583997 --- sim: Reuse the same limit_event in simulate() This patch accomplishes two things: 1. Makes simulate()'s GlobalSimLoopExitEvent a singleton reused across calls. This is slightly more efficient than recreating it every time. 2. Gives callers to simulate() (especially other simulators) a foolproof way of knowing that the simulation period ended successfully by hitting the limit event. They can call getLimitEvent() and compare it to the return value of simulate(). This change was motivated by an ongoing effort to integrate gem5 and SST, with SST as the master sim and gem5 as the slave sim. Diffs - src/sim/sim_events.hh c6cb94a14fea4c59780d73d1623d7031bcede6af src/sim/simulate.hh c6cb94a14fea4c59780d73d1623d7031bcede6af src/sim/simulate.cc c6cb94a14fea4c59780d73d1623d7031bcede6af Diff: http://reviews.gem5.org/r/2665/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2667: ext: Add SST connector
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2667/ --- Review request for Default. Repository: gem5 Description --- Changeset 10708:344bc6b7203d --- ext: Add SST connector This patch adds a connector that allows gem5 to be used as a component in SST (Structural Simulation Toolkit, sst-simulator.org). At a high level, this allows memory traffic to pass between the two simulators. SST Links are roughly analogous to gem5 Ports, although Links do not have a notion of master and slave. This distinction is important to gem5, so when connecting a gem5 CPU to an SST cache, an ExternalSlave must be used, and similarly when connecting the memory side of SST cache to a gem5 port (for memory - I/O), an ExternalMaster must be used. These connectors handle the administrative aspects of gem5 (initialization, simulation, shutdown) as well as translating SST's MemEvents into gem5 Packets and vice-versa. Diffs - ext/sst/ExtMaster.hh PRE-CREATION ext/sst/ExtMaster.cc PRE-CREATION ext/sst/ExtSlave.hh PRE-CREATION ext/sst/ExtSlave.cc PRE-CREATION ext/sst/LICENSE PRE-CREATION ext/sst/Makefile PRE-CREATION ext/sst/README PRE-CREATION ext/sst/gem5.hh PRE-CREATION ext/sst/gem5.cc PRE-CREATION ext/sst/libgem5.cc PRE-CREATION Diff: http://reviews.gem5.org/r/2667/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2668: config: Support full-system with SST's memory system
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2668/ --- Review request for Default. Repository: gem5 Description --- Changeset 10709:a3b771cd744c --- config: Support full-system with SST's memory system This patch adds an example configuration in ext/sst/tests/ that allows an SST/gem5 instance to simulate a 4-core AArch64 system with SST's memHierarchy components providing all the caches and memories. Diffs - configs/common/CacheConfig.py c6cb94a14fea4c59780d73d1623d7031bcede6af configs/common/FSConfig.py c6cb94a14fea4c59780d73d1623d7031bcede6af configs/common/MemConfig.py c6cb94a14fea4c59780d73d1623d7031bcede6af configs/common/Options.py c6cb94a14fea4c59780d73d1623d7031bcede6af configs/example/fs.py c6cb94a14fea4c59780d73d1623d7031bcede6af ext/sst/tests/test6_arm_4c.py PRE-CREATION src/dev/arm/RealView.py c6cb94a14fea4c59780d73d1623d7031bcede6af src/mem/ExternalSlave.py c6cb94a14fea4c59780d73d1623d7031bcede6af Diff: http://reviews.gem5.org/r/2668/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] changeset in gem5: x86: Enable three bits in the FamilyModelStep...
Sorry for the delayed reply. This is something I referred to when I was looking into the CPUID stuff recently. http://support.amd.com/TechDocs/25481.pdf Gabe On Fri, Feb 20, 2015 at 3:17 PM, Joel Hestness via gem5-dev gem5-dev@gem5.org wrote: Hi guys, I think I figure some of this out. The Wikipedia page on CPUID ( http://en.wikipedia.org/wiki/CPUID) indicates that xsave is bit 26 of ECX. Unsetting this bit allowed me to successfully boot these older versions of Linux. For anyone running into the same issue, here is the patch for that change: -- diff --git a/src/arch/x86/cpuid.cc b/src/arch/x86/cpuid.cc --- a/src/arch/x86/cpuid.cc +++ b/src/arch/x86/cpuid.cc @@ -154,7 +154,7 @@ break; case FamilyModelStepping: result = CpuidResult(0x00020f51, 0x0805, - 0xe7dbfbff, 0x04000209); + 0xe7dbfbff, 0x0209); break; default: warn(x86 cpuid: unimplemented function %u, funcNum); -- I also discovered that the reason Linux falls into this kernel panic is that it executes a CPUID operation that is not currently implemented in gem5 (src/arch/x86/cpuid.cc). Specifically, the cpuid_count function call (here: http://lxr.free-electrons.com/source/arch/x86/kernel/xsave.c?v=2.6.32#L319 ) tries to execute CPUID function EAX=0xd (13), EAX=0x0. gem5 prints a warning saying that this function is unimplemented, and does not update any registers, causing the resulting EAX to be incorrect. It looks like more recent Linux versions contain more checks, and so may not reach this cpuid_count call: http://lxr.free-electrons.com/source/arch/x86/kernel/xsave.c#L618 Joel On Fri, Feb 20, 2015 at 2:17 PM, Joel Hestness jthestn...@gmail.com wrote: Hey Gabe, When I try to boot older versions of Linux (2.6.28.4, 2.6.22.9), I'm running into a kernel panic related to xsave ( http://lxr.free-electrons.com/source/arch/x86/kernel/xsave.c?v=2.6.32#L323 ): *FP/SSE not shown under xsave features 0xd* [ cut here ] kernel BUG at arch/x86/kernel/xsave.c:323! invalid opcode: [#1] SMP last sysfs file: CPU 0 Modules linked in: Pid: 0, comm: swapper Tainted: GW 2.6.28-rc4-dirty #5 RIP: 0010:[808d69e7] [808d69e7] xsave_cntxt_init+0x35/0x130 RSP: 0018:808c3f18 EFLAGS: 00b8 RAX: 002d RBX: 808c3f48 RCX: RDX: 807c3c38 RSI: 0074 RDI: 8094a5f4 RBP: R08: R09: 03fd R10: R11: R12: 807a8340 R13: 0005 R14: 8800 R15: 88000101f000 FS: () GS:808bd980() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 80050033 CR2: CR3: 00201000 CR4: 06a0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: Process swapper (pid: 0, threadinfo 808c2000, task 807a8340) Stack: 808c3f48 8060e2b1 0010 8060fa3f 0020 fff0 0100890239802087 8800 808c3f88 0040 808f7700 Call Trace: [8060e2b1] fpu_init+0x4a/0x97 [8060fa3f] cpu_init+0x319/0x33f [808cdab5] start_kernel+0x1b2/0x321 [808cd405] x86_64_start_kernel+0xd9/0xdd Code: 48 c1 e2 20 89 c0 48 8d 34 02 48 89 f0 48 89 35 90 96 05 00 83 e0 03 48 83 f8 03 74 12 48 c7 c7 10 82 71 80 31 c0 e8 4d e6 d3 ff 0f 0b eb fe f6 05 b5 70 fe ff 04 48 c7 05 63 96 05 00 03 00 00 RIP [808d69e7] xsave_cntxt_init+0x35/0x130 RSP 808c3f18 ---[ end trace 4eaa2a86a8e2da22 ]--- Kernel panic - not syncing: Attempted to kill the idle task! [ cut here ] WARNING: at kernel/smp.c:333 smp_call_function_mask+0x1de/0x250() Modules linked in: Pid: 0, comm: swapper Tainted: G D W 2.6.28-rc4-dirty #5 Call Trace: [8023af92] warn_on_slowpath+0x62/0xa0 [803a4159] vsnprintf+0x449/0x6b0 [803a3a84] string+0x34/0xf0 [803a4118] vsnprintf+0x408/0x6b0 [802547dd] up+0xd/0x40 [8023b6de] release_console_sem+0x1ae/0x200 [8021ef40] stop_this_cpu+0x0/0x30 [8025db9e] smp_call_function_mask+0x1de/0x250 [803a3f78] vsnprintf+0x268/0x6b0 [80615074] printk+0x40/0x45 [8021ef30] native_smp_send_stop+0x20/0x30 [80614f8d] panic+0x82/0x129 [8023ecae] do_exit+0x7de/0x890 [80615074]
Re: [gem5-dev] changeset in gem5: x86: Enable three bits in the FamilyModelStep...
Hey Gabe, When I try to boot older versions of Linux (2.6.28.4, 2.6.22.9), I'm running into a kernel panic related to xsave ( http://lxr.free-electrons.com/source/arch/x86/kernel/xsave.c?v=2.6.32#L323): *FP/SSE not shown under xsave features 0xd* [ cut here ] kernel BUG at arch/x86/kernel/xsave.c:323! invalid opcode: [#1] SMP last sysfs file: CPU 0 Modules linked in: Pid: 0, comm: swapper Tainted: GW 2.6.28-rc4-dirty #5 RIP: 0010:[808d69e7] [808d69e7] xsave_cntxt_init+0x35/0x130 RSP: 0018:808c3f18 EFLAGS: 00b8 RAX: 002d RBX: 808c3f48 RCX: RDX: 807c3c38 RSI: 0074 RDI: 8094a5f4 RBP: R08: R09: 03fd R10: R11: R12: 807a8340 R13: 0005 R14: 8800 R15: 88000101f000 FS: () GS:808bd980() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 80050033 CR2: CR3: 00201000 CR4: 06a0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: Process swapper (pid: 0, threadinfo 808c2000, task 807a8340) Stack: 808c3f48 8060e2b1 0010 8060fa3f 0020 fff0 0100890239802087 8800 808c3f88 0040 808f7700 Call Trace: [8060e2b1] fpu_init+0x4a/0x97 [8060fa3f] cpu_init+0x319/0x33f [808cdab5] start_kernel+0x1b2/0x321 [808cd405] x86_64_start_kernel+0xd9/0xdd Code: 48 c1 e2 20 89 c0 48 8d 34 02 48 89 f0 48 89 35 90 96 05 00 83 e0 03 48 83 f8 03 74 12 48 c7 c7 10 82 71 80 31 c0 e8 4d e6 d3 ff 0f 0b eb fe f6 05 b5 70 fe ff 04 48 c7 05 63 96 05 00 03 00 00 RIP [808d69e7] xsave_cntxt_init+0x35/0x130 RSP 808c3f18 ---[ end trace 4eaa2a86a8e2da22 ]--- Kernel panic - not syncing: Attempted to kill the idle task! [ cut here ] WARNING: at kernel/smp.c:333 smp_call_function_mask+0x1de/0x250() Modules linked in: Pid: 0, comm: swapper Tainted: G D W 2.6.28-rc4-dirty #5 Call Trace: [8023af92] warn_on_slowpath+0x62/0xa0 [803a4159] vsnprintf+0x449/0x6b0 [803a3a84] string+0x34/0xf0 [803a4118] vsnprintf+0x408/0x6b0 [802547dd] up+0xd/0x40 [8023b6de] release_console_sem+0x1ae/0x200 [8021ef40] stop_this_cpu+0x0/0x30 [8025db9e] smp_call_function_mask+0x1de/0x250 [803a3f78] vsnprintf+0x268/0x6b0 [80615074] printk+0x40/0x45 [8021ef30] native_smp_send_stop+0x20/0x30 [80614f8d] panic+0x82/0x129 [8023ecae] do_exit+0x7de/0x890 [80615074] printk+0x40/0x45 [806184ba] oops_end+0x7a/0xc0 [8020d3d4] do_invalid_op+0x84/0xa0 [808d69e7] xsave_cntxt_init+0x35/0x130 [8023b6de] release_console_sem+0x1ae/0x200 [802547dd] up+0xd/0x40 [806178e9] error_exit+0x0/0x51 [808d69e7] xsave_cntxt_init+0x35/0x130 [808d69e7] xsave_cntxt_init+0x35/0x130 [8060e2b1] fpu_init+0x4a/0x97 [8060fa3f] cpu_init+0x319/0x33f [808cdab5] start_kernel+0x1b2/0x321 [808cd405] x86_64_start_kernel+0xd9/0xdd ---[ end trace 4eaa2a86a8e2da22 ]--- Based on the commit message, it looks like this patch might have enabled Linux boot features through the xsave setting. Can you please let me know which of the bits in the CpuidResult vector I should disable to test if xsave is the problem? Thanks! Joel On Wed, Jan 7, 2015 at 12:06 AM, Gabe Black via gem5-dev gem5-dev@gem5.org wrote: changeset 5d119a460f15 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=5d119a460f15 description: x86: Enable three bits in the FamilyModelStepping ECX CPUID bitfield. These are for the monitor/mwait instructions, SSSE3, and XSAVE. diffstat: src/arch/x86/cpuid.cc | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diffs (12 lines): diff -r e9bc4cde5d8e -r 5d119a460f15 src/arch/x86/cpuid.cc --- a/src/arch/x86/cpuid.cc Tue Jan 06 22:13:56 2015 -0800 +++ b/src/arch/x86/cpuid.cc Tue Jan 06 22:15:00 2015 -0800 @@ -154,7 +154,7 @@ break; case FamilyModelStepping: result = CpuidResult(0x00020f51, 0x0805, - 0xe7dbfbff, 0x0001); + 0xe7dbfbff, 0x04000209); break; default: warn(x86 cpuid: unimplemented function %u, funcNum); ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev -- Joel Hestness PhD Candidate, Computer Architecture Dept. of Computer
