Re: [gem5-dev] Kernel panic caused by changeset 10552
I don't remember of the top of my head exactly the reason to enable all those features in the CPUID. I do remember trying not to enable things that gem5 does not support like SSEx, SSSE and AVX. I also remember encountering problems with libc that uses x87 instructions and pxor, so I had to enable MMX and x87. Alex -Original Message- From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black via gem5-dev Sent: Monday, December 15, 2014 12:35 AM To: gem5 Developer List Subject: Re: [gem5-dev] Kernel panic caused by changeset 10552 I tried reverting this change and it fixes the undefined instruction exceptions I was seeing. It does break KVM in SE mode though, so we probably shouldn't yank it out entirely. We need to find a minimal version of that change which makes KVM in SE work without breaking other things. Gabe On Wed, Dec 10, 2014 at 1:40 AM, Gabe Black gabebl...@google.com wrote: Yeah, I was going to say something about that. CPUID shouldn't advertise features that we don't support. For instance, that change tells CPUID to say we support AVX, but the decoder has no idea what to do with those instructions and will trigger an exception if one is executed. I noticed a bunch of undefined instruction exceptions in my own workload that weren't happening before, and I wonder if that's the cause. I'm not sure how that change helps support KVM in SE mode. Perhaps it should be reverted? Can you explain why it's necessary Alex? If it is, maybe we can reshape it a bit to avoid these side effects. Gabe On Wed, Dec 10, 2014 at 12:43 AM, 马久跃 via gem5-dev gem5-dev@gem5.org wrote: Hi everyone, I found x86_64-vmlinux-2.6.28.4 panic when apply changeset 10552: cpuid, x86: Enabling more features in CPUid. (2.6.22.9 works fine) The gem5 also report warn: x86 cpuid: unimplemented function 13, and kernel report BUG at arch/x86/kernel/xsave.c:323 as following. Can anybody check/fix this bug? Thanks. KERNEL OUTPUT -- MPTABLE: APIC at: 0xFEE0 Processor #0 (Bootup-CPU) I/O APIC #1 Version 17 at 0xFEC0. Processors: 1 Allocating PCI resources starting at c400 (gap: c000:3fff) Built 1 zonelists in Zone order, mobility grouping on. Total pages: 127500 Kernel command line: earlyprintk=ttyS0 console=ttyS0 lpj=723 root=/dev/hda1 Initializing CPU#0 FP/SSE not shown under xsave features 0x80050033000d [ cut here ] kernel BUG at arch/x86/kernel/xsave.c:323! invalid opcode: [#1] last sysfs file: CPU 0 Modules linked in: Pid: 0, comm: swapper Tainted: GW 2.6.28.4 #2 RIP: 0010:[80577b45] [80577b45] xsave_cntxt_init+0x35/0x130 RSP: 0018:80769f48 EFLAGS: 00b8 RAX: 003c RBX: RCX: 807cd460 RDX: RSI: 0d5c RDI: 80702180 RBP: R08: R09: 03fd R10: R11: R12: R13: R14: R15: FS: () GS:807bf020() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 80050033 CR2: CR3: 00201000 CR4: 06a0 DR0: DR1: DR2: DR3: DR6: DR7: Process swapper (pid: 0, threadinfo 80768000, task 806f5380) Stack: 8078f133 80795000 8078fe72 8000896f59002087 8022ee104a50 80794000 80795000 8076a98d 80795000 Call Trace: [8078f133] fpu_init+0x3e/0x8e [8078fe72] cpu_init+0x222/0x240 [8076a98d] start_kernel+0x16f/0x2d9 [8076a407] x86_64_start_kernel+0xd9/0xdfCode: 48 c1 e2 20 89 c0 48 8d 34 02 48 89 f0 48 89 35 12 a6 24 00 83 e0 03 48 83 f8 03 74 12 48 c7 c7 50 74 67 80 31 c0 e8 9c 30 01 00 0f 0b eb fe f6 05 57 b7 1e 00 04 48 c7 05 e5 a5 24 00 03 00 00 RIP [80577b45] xsave_cntxt_init+0x35/0x130 RSP 80769f48 ---[ end trace 4eaa2a86a8e2da22 ]--- Kernel panic - not syncing: Attempted to kill the idle task! Jiuyue ___ 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 mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
Gabe, is that an AMD system? The intel side works fine, it is failing on an AMD system. I will try to run some regression tests and see if I can find a failure in the standard set of tests. The AMD system I am on has a pretty old OS, which might be part of my issue. I don't want to block the fix if it is working fine for others. Getting the intel functionality is what I needed. On Sun, Dec 14, 2014 at 9:53 PM, Gabe Black via gem5-dev gem5-dev@gem5.org wrote: I just tried running bzip2 approximately like the regressions would but with the KVM CPU, and it seemed to work just fine. The only thing I changed was I hacked se.py to set the cwd to what bzip2 expects. Can you please provide more specific instructions how to reproduce the hang/crash you're seeing? If this is working as expected, it would be good to get it checked in and get KVM working again. Gabe $ M5_CPU2000=/usr/local/google/home/gabeblack/gem5/dist/m5/cpu2000/ ./build/X86/gem5.opt configs/example/se.py -c /usr/local/google/home/gabeblack/gem5/dist/m5/cpu2000/binaries/x86/linux/bzip2 --cpu-type=kvm -o 'input.source 1' gem5 Simulator System. http://gem5.org gem5 is copyrighted software; use the --copyright option for details. gem5 compiled Dec 14 2014 21:18:54 gem5 started Dec 14 2014 21:49:12 gem5 executing on gabeblackz620.mtv.corp.google.com command line: ./build/X86/gem5.opt configs/example/se.py -c /usr/local/google/home/gabeblack/gem5/dist/m5/cpu2000/binaries/x86/linux/bzip2 --cpu-type=kvm -o input.source 1 Global frequency set at 1 ticks per second warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (512 Mbytes) 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 REAL SIMULATION info: KVM: Coalesced MMIO disabled by config. info: Entering event queue @ 0. Starting simulation... warn: kvm-x86: MSR (0x12) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x11) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x4b564d01) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x4b564d00) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x4000) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x4001) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x4073) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x4b564d02) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x4b564d03) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x4b564d04) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x3a) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x3b) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x6e0) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x1a0) unsupported by gem5. Skipping. spec_init Loading Input Data Input data 1048576 bytes in length Compressing Input Data, level 7 info: Increasing stack size by one page. info: Increasing stack size by one page. info: Increasing stack size by one page. Compressed data 198546 bytes in length Uncompressing Data Uncompressed data 1048576 bytes in length Uncompressed data compared correctly Compressing Input Data, level 9 Compressed data 198677 bytes in length Uncompressing Data Uncompressed data 1048576 bytes in length Uncompressed data compared correctly Tested 1MB buffer: OK! Exiting @ tick 13987682791500 because target called exit() hack: Pretending totalOps is equivalent to totalInsts() On Sat, Dec 13, 2014 at 12:12 AM, Andreas Hansson via gem5-dev gem5-dev@gem5.org wrote: This patch should hopefully solve the issue with the refresh event: http://reviews.gem5.org/r/2573/ Andreas On 11/12/2014 15:52, Andreas Hansson via gem5-dev gem5-dev@gem5.org wrote: Hi Alex, Mike, I¹ll try and fix this whole issue of the refresh event once and for all. SimpleMemory should only really be used for fast-forwarding and high-level sweeps, and I would like to ensure there are really no reasons to move away from the DRAM controller. It seems the sensible thing to do is to use startup and drainResume as the points where we check the mode of the memory system and either disable/enable the refresh event of the DRAM controller. Hopefully I will have something working before the weekend. Andreas On 11/12/2014 15:32, Dutu, Alexandru via gem5-dev gem5-dev@gem5.org wrote: Hi Mike, Are you running with SimpleMemory, SE or FS? On my AMD platform, for SE, I get very similar execution times with old implementation, for SimpleMemory and classic memory with detailed memory controller. Also what linux kernel are you using? Thanks, Alex -Original Message- From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of mike upton via gem5-dev Sent: Wednesday, December 10, 2014 3:59 PM To: gem5 Developer List Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) I was testing this on both Intel and AMD platforms. The new code
Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
Oh, ok, yes, it's an Intel system. I don't have any AMD systems any more so I won't be able to help debug directly. Gabe On Mon, Dec 15, 2014 at 2:18 PM, mike upton via gem5-dev gem5-dev@gem5.org wrote: Gabe, is that an AMD system? The intel side works fine, it is failing on an AMD system. I will try to run some regression tests and see if I can find a failure in the standard set of tests. The AMD system I am on has a pretty old OS, which might be part of my issue. I don't want to block the fix if it is working fine for others. Getting the intel functionality is what I needed. On Sun, Dec 14, 2014 at 9:53 PM, Gabe Black via gem5-dev gem5-dev@gem5.org wrote: I just tried running bzip2 approximately like the regressions would but with the KVM CPU, and it seemed to work just fine. The only thing I changed was I hacked se.py to set the cwd to what bzip2 expects. Can you please provide more specific instructions how to reproduce the hang/crash you're seeing? If this is working as expected, it would be good to get it checked in and get KVM working again. Gabe $ M5_CPU2000=/usr/local/google/home/gabeblack/gem5/dist/m5/cpu2000/ ./build/X86/gem5.opt configs/example/se.py -c /usr/local/google/home/gabeblack/gem5/dist/m5/cpu2000/binaries/x86/linux/bzip2 --cpu-type=kvm -o 'input.source 1' gem5 Simulator System. http://gem5.org gem5 is copyrighted software; use the --copyright option for details. gem5 compiled Dec 14 2014 21:18:54 gem5 started Dec 14 2014 21:49:12 gem5 executing on gabeblackz620.mtv.corp.google.com command line: ./build/X86/gem5.opt configs/example/se.py -c /usr/local/google/home/gabeblack/gem5/dist/m5/cpu2000/binaries/x86/linux/bzip2 --cpu-type=kvm -o input.source 1 Global frequency set at 1 ticks per second warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (512 Mbytes) 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 REAL SIMULATION info: KVM: Coalesced MMIO disabled by config. info: Entering event queue @ 0. Starting simulation... warn: kvm-x86: MSR (0x12) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x11) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x4b564d01) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x4b564d00) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x4000) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x4001) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x4073) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x4b564d02) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x4b564d03) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x4b564d04) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x3a) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x3b) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x6e0) unsupported by gem5. Skipping. warn: kvm-x86: MSR (0x1a0) unsupported by gem5. Skipping. spec_init Loading Input Data Input data 1048576 bytes in length Compressing Input Data, level 7 info: Increasing stack size by one page. info: Increasing stack size by one page. info: Increasing stack size by one page. Compressed data 198546 bytes in length Uncompressing Data Uncompressed data 1048576 bytes in length Uncompressed data compared correctly Compressing Input Data, level 9 Compressed data 198677 bytes in length Uncompressing Data Uncompressed data 1048576 bytes in length Uncompressed data compared correctly Tested 1MB buffer: OK! Exiting @ tick 13987682791500 because target called exit() hack: Pretending totalOps is equivalent to totalInsts() On Sat, Dec 13, 2014 at 12:12 AM, Andreas Hansson via gem5-dev gem5-dev@gem5.org wrote: This patch should hopefully solve the issue with the refresh event: http://reviews.gem5.org/r/2573/ Andreas On 11/12/2014 15:52, Andreas Hansson via gem5-dev gem5-dev@gem5.org wrote: Hi Alex, Mike, I¹ll try and fix this whole issue of the refresh event once and for all. SimpleMemory should only really be used for fast-forwarding and high-level sweeps, and I would like to ensure there are really no reasons to move away from the DRAM controller. It seems the sensible thing to do is to use startup and drainResume as the points where we check the mode of the memory system and either disable/enable the refresh event of the DRAM controller. Hopefully I will have something working before the weekend. Andreas On 11/12/2014 15:32, Dutu, Alexandru via gem5-dev gem5-dev@gem5.org wrote: Hi Mike, Are you running with SimpleMemory, SE or FS? On my AMD platform, for SE, I get very similar execution times with old implementation, for SimpleMemory and classic memory with detailed memory controller. Also what linux kernel are you using? Thanks, Alex
