Re: GPF on modprobe kvm-amd
This is resolved, but since other people might have the problem I'll still post what I figured out. It seems like a strange corner case of memory allocation. I've upgraded to kernel 2.6.28 with kvm-82, but the problem kept persisting. I've decided to remove the evga 9800gt and suddenly it kvm-amd would load without any issue. I've decided to check the Asus website and sure enough there was a bios update, I've installed it then installed the evga card back it and since then everything works (well except rebooting but anyways). The bios update is 0603, it lists fix ups for some memory modules as an improvement, so that might be it. On Wed, 31 Dec 2008, Avi Kivity wrote: Date: Wed, 31 Dec 2008 12:17:15 +0200 From: Avi Kivity To: nuit...@melchior.nuitari.net Cc: kvm@vger.kernel.org, Joerg Roedel Subject: Re: GPF on modprobe kvm-amd (adding cc) Joerg, all I can make of it is that svm is enabled on one cpu but not on the other. Can you help here? nuit...@melchior.nuitari.net wrote: This is with kvm-81 I'm getting a kernel panic when I modprobe kvm-amd It used to work until I had to use the CMOS jumper to boot. The motherboard is an Asus M3N78 PRO The CPU is an AMD Phenom 9950 Black Edition Here are the steps I've already tried: - Checking that virtualization is enabled in the BIOS - Updating the BIOS - Restoring the defaults of the BIOS - Downgrading the BIOS - Trying various versions of kvm - Trying various linux kernel versions - Trying various vcore settings - Enabling/Disabling Cool & Quiet and AMD C1E - Tried a known good kernel and modules combo - Interrupting the boot process to only have udev as a process, and killing it. - Not having any other modules loaded What I plan to try: - Updating to 2.6.28 and kvm-82 - Tranfering the nvram from an identical motherboard I own to the problematic one, using /dev/nvram Here are the traces [ 36.870419] general protection fault: [1] PREEMPT SMP [ 36.870579] CPU 0 [ 36.870667] Modules linked in: kvm_amd(+) kvm nvidia(P) snd_hda_intel [ 36.870893] Pid: 0, comm: swapper Tainted: P 2.6.27-gentoo-r7 #4 [ 36.870955] RIP: 0010:[] [] svm_hardware_enable+0x87/0xf0 [kvm_amd] [ 36.871070] RSP: 0018:808d9f28 EFLAGS: 00010006 [ 36.871130] RAX: 1d01 RBX: 0040 RCX: c080 [ 36.871193] RDX: RSI: 88021c41c9c0 RDI: [ 36.871255] RBP: 808d9f48 R08: R09: [ 36.871317] R10: R11: 80869e88 R12: 88021e843cc0 [ 36.871379] R13: 88021e843ce8 R14: R15: [ 36.871413] FS: 7fbabbbec6f0() GS:80863340() knlGS: [ 36.871413] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b [ 36.871413] CR2: 7fbabbc22000 CR3: 00201000 CR4: 06e0 [ 36.871413] DR0: DR1: DR2: [ 36.871413] DR3: DR6: 0ff0 DR7: 0400 [ 36.871413] Process swapper (pid: 0, threadinfo 80868000, task 80808340) [ 36.871413] Stack: 88002803607f 8025 880028038d20 0011 [ 36.871413] 808d9f58 a07c002e 808d9f68 a07bceaf [ 36.871413] 808d9f98 8026515b 0011 808ae500 [ 36.871413] Call Trace: [ 36.871413][] ? tick_broadcast_oneshot_control+0xff/0x130 [ 36.871413] [] kvm_arch_hardware_enable+0xe/0x10 [kvm] [ 36.871413] [] hardware_enable+0x2f/0x40 [kvm] [ 36.871413] [] generic_smp_call_function_interrupt+0x6b/0x160 [ 36.871413] [] smp_call_function_interrupt+0x19/0x30 [ 36.871413] [] call_function_interrupt+0x66/0x70 [ 36.871413][] ? default_idle+0x42/0x50 [ 36.871413] [] ? c1e_idle+0x38/0x100 [ 36.871413] [] ? atomic_notifier_call_chain+0x11/0x20 [ 36.871413] [] ? cpu_idle+0x56/0xc0 [ 36.871413] [] ? rest_init+0x86/0x90 [ 36.871413] [ 36.871413] [ 36.871413] Code: 46 10 0f 01 45 e0 48 8b 45 e2 b9 80 00 00 c0 48 83 c0 40 48 89 46 18 0f 32 48 c1 e2 20 89 c0 48 09 c2 89 d0 48 c1 ea 20 80 cc 10 <0f> 30 48 ba 00 00 00 00 00 1e 00 00 48 03 56 20 48 b8 b7 6d db [ 36.871413] RIP [] svm_hardware_enable+0x87/0xf0 [kvm_amd] [ 36.871413] RSP [ 36.871413] ---[ end trace 91fceceaf959d326 ]--- [ 36.871413] Kernel panic - not syncing: Aiee, killing interrupt handler! [ 36.871413] [ cut here ] [ 36.871413] WARNING: at kernel/smp.c:332 smp_call_function_mask+0x21c/0x230() [ 36.871413] Modules linked in: kvm_amd(+) kvm nvidia(P) snd_hda_intel [ 36.871413] Pid: 0, comm: swapper Tainted: P D 2.6.27-gentoo-r7 #4 [ 36.871413] [ 36.871413] Call Trace: [ 36.871413][] warn_on_slowpath+0x5f/0x90 [ 36.871413] [] ? __call_console_drive
RE: [PATCH][v2] kvm-userspace: Load PCI option ROMs
Thanks, Avi!
I will definitely double check it when I go back to work tomorrow.
Happy New Year! :)
Best Regards
Shan Haitao
-Original Message-
From: Avi Kivity [mailto:a...@redhat.com]
Sent: 2008年12月31日 17:29
To: Shan, Haitao
Cc: Liu, Kechao; 'kvm@vger.kernel.org'
Subject: Re: [PATCH][v2] kvm-userspace: Load PCI option ROMs
Shan, Haitao wrote:
> Hi, Avi,
>
> Option ROM already has its own BAR at 0x30h. I think the devices assignment
> code now already handles this register.
>
Okay good.
> Can I summary your proposals like the following: In guest BIOS, scan all the
> pci devices (virtual) for existance of Option ROMs. Copy them to available
> BIOS space in 0xC - 0xD. Execute the ROM code at copied location.
>
Yes.
> I don't understand why this makes differences compared to scanning and
> copying Option ROMs in QEMU,
If the ROM BAR is already handled (including registering the memory when
the BAR is programmed -- I don't see that in the code), then there is no
big advantage. It's closer to how real hardware works, but that's about it.
> especially given that the VGA BIOS and etherboot ROM are also copied to BIOS
> space in QEMU before they execute in rom_scan loop in guest BIOS.
>
The VGA BIOS is typically present on the motherboard itself, at least on
some configurations. You're right about etherboot.
I'll apply the patch. Can you take a look at the ROM BAR?
--
error compiling committee.c: too many arguments to function
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�筏�hФ�≤�}��财�z�&j:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ��&�)撷f
Re: [Qemu-devel] Re: gdbstub: packet reply is too long
Jan Kiszka wrote: > You need CR0.PE to detect if you are in real or protected mode. And then > you need GDTR/LDTR to find the descriptor CS is pointing at, parsing it > to detect if you are running 16, 32 or 64 bit code (by default). Those > extensions would also be useful in order to decode memory addresses in > case descriptor.base != 0 (or if it's CS >> 4, ie. you are in real > mode). If you're going to decode segment descriptors (great idea, btw, and helpful for threaded code), it might be better to supply the CPU's internal segment state, if that's possible, instead of looking at the LDT/GDT in memory, since the CPU's state can differ from the memory version when the latter is written to. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [DMAR] Fix endless "Unknown DMAR structure type" loop
Avi Kivity wrote: > (copying relevant people) > > Tony Battersby wrote: >> +"Invalid 0-length structure\n"); This line is everything the reader of your message will see, (unless it happens not to be the first ACPI error). I would not be able to tell the cause without grepping the kernel source. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM-82 failed to compile
Simon Gao wrote: Carlo Marcelo Arenas Belon wrote: has your kernel configuration (/usr/src/linux/.config) the following enabled? CONFIG_MMU_NOTIFIER=y I did not see the config parameter in my .config file, only has: CONFIG_MMU=y # CONFIG_IOMMU_HELPER is not set Is there other parameter to enable to see the option? Do 'make menuconfig' and select the second item from the bottom: Virtualization-->Kernel-based Virtualization (KVM) support. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2482759 ] Windows SCSI errors
Bugs item #2482759, was opened at 2009-01-02 14:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2482759&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan Bair (ryandbair) Assigned to: Nobody/Anonymous (nobody) Summary: Windows SCSI errors Initial Comment: When starting up a fresh install of Windows Server 2003 R2 x64, I get errors similar to the following... scsi-disk: Command: lun=0 tag=0x0 data=0x12 0x01 0x00 0x00 0xff 0x00 scsi-disk: Inquiry (len 255) scsi-disk: Inquiry EVPD[Supported pages] buffer size 255 scsi-disk: Read buf_len=7 scsi-disk: Read sector_count=0 scsi-disk: Command complete tag=0x0 status=0 sense=0 lsi_scsi: error: Unhandled writeb 0xff = 0x0 lsi_scsi: error: Unhandled writeb 0x100 = 0x0 lsi_scsi: error: Unhandled writeb 0x101 = 0x0 lsi_scsi: error: Unhandled writeb 0x102 = 0x0 While these errors are happening on boot, the animated bar continues to scroll. The errors continue for about a minute and then everything suddenly kicks into gear and the machine continues to boot. This also happens while trying to get partition information through the device properties in the device manager and through the disk management mmc snapin. I'm running kvm-82 on Debian Lenny AMD64. The disk is a 20GB virtual SCSI, raw format. Here's the command I'm using to run KVM. kvm -m 1024 -smp 2 -drive file=system.img,if=scsi,boot=on -localtime --vnc 127.0.0.1:0 &> ../win2k3x64.log -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2482759&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM-82 failed to compile
Carlo Marcelo Arenas Belon wrote: > Thu, Jan 01, 2009 at 12:17:06PM -0800, Simon Gao wrote: > >> I am seeing following error while compiling kvm-82: >> >> In file included from /tmp/kvm-82/kernel/x86/svm.c:56: >> /tmp/kvm-82/kernel/include/linux/kvm_host.h:171: error: field >> ‘mmu_notifier’ has incomplete type >> > > does that line correspond to "struct mmu_motifier"? > > >> This error occurred to both linux-2.6.26-gentoo-r4 and >> linux-2.6.27-gentoo-r7. >> > > has your kernel configuration (/usr/src/linux/.config) the following > enabled? > > CONFIG_MMU_NOTIFIER=y > > I did not see the config parameter in my .config file, only has: CONFIG_MMU=y # CONFIG_IOMMU_HELPER is not set Is there other parameter to enable to see the option? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM-82 failed to compile
Hi, enable KVM support on kernel against which You're compiling.. n. On Thu, Jan 01, 2009 at 02:06:26PM -0800, Simon Gao wrote: > Simon Gao wrote: > > I am seeing following error while compiling kvm-82: > > > > In file included from /tmp/kvm-82/kernel/x86/svm.c:56: > > /tmp/kvm-82/kernel/include/linux/kvm_host.h:171: error: field > > ‘mmu_notifier’ has incomplete type > > make[4]: *** [/tmp/kvm-82/kernel/x86/svm.o] Error 1 > > make[3]: *** [/tmp/kvm-82/kernel/x86] Error 2 > > make[2]: *** [_module_/tmp/kvm-82/kernel] Error 2 > > make[2]: Leaving directory `/usr/src/linux-2.6.27-gentoo-r7' > > make[1]: *** [all] Error 2 > > make[1]: Leaving directory `/tmp/kvm-82/kernel' > > make: *** [kernel] Error 2 > > > > This error occurred to both linux-2.6.26-gentoo-r4 and > > linux-2.6.27-gentoo-r7. > > > > Anyone else has such problem? > > > > > > -- > > To unsubscribe from this list: send the line "unsubscribe kvm" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Actually this compiling problem only occurred to linux-2.6.27-gentoo-r7. > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- - Nikola CIPRICH LinuxBox.cz, s.r.o. 28. rijna 168, 709 01 Ostrava tel.: +420 596 603 142 fax:+420 596 621 273 mobil: +420 777 093 799 www.linuxbox.cz mobil servis: +420 737 238 656 email servis: ser...@linuxbox.cz - -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: gdbstub: packet reply is too long
Daniel Jacobowitz wrote: > On Mon, Dec 29, 2008 at 03:58:47PM +0100, Jan Kiszka wrote: >> Well, in the current gdb design, current_gdbarch is consulted when >> disassembling the code while target_gdbarch defines the register set >> that is exchanged with the remote stub. > > This is a transitional state. Really, there isn't supposed to be a > 'current' gdbarch; we're already moving away from it. > > Thinking about it some more you may be right about the overall > solution though, sorry. The target_gdbarch idea is likely to stick > around for a while. But some work will have to be done if current and > target architectures have different register sets :-( I'll start a thread on the gdb list today, CC'ing you. Would be nice if you could then add more details on what you think would be required to achieve this. > >> I'm pretty sure that the final solution will involve extended x86 >> register sets in order to inform the frontend about the full target CPU >> state so that it can set the right current_gdbarch automatically. > > Isn't everything we need for this in eflags already? You need CR0.PE to detect if you are in real or protected mode. And then you need GDTR/LDTR to find the descriptor CS is pointing at, parsing it to detect if you are running 16, 32 or 64 bit code (by default). Those extensions would also be useful in order to decode memory addresses in case descriptor.base != 0 (or if it's CS >> 4, ie. you are in real mode). We have some usable patches for this @work, at least for 16 vs. 32 bit. But it's clear that more work is needed to get things upstream and we should first agree on how things should be done there, e.g. how to extend the register set and how to communicate that extension between backend and frontend. Jan signature.asc Description: OpenPGP digital signature
Re: KVM-82 failed to compile
Thu, Jan 01, 2009 at 12:17:06PM -0800, Simon Gao wrote: > I am seeing following error while compiling kvm-82: > > In file included from /tmp/kvm-82/kernel/x86/svm.c:56: > /tmp/kvm-82/kernel/include/linux/kvm_host.h:171: error: field > ‘mmu_notifier’ has incomplete type does that line correspond to "struct mmu_motifier"? > This error occurred to both linux-2.6.26-gentoo-r4 and > linux-2.6.27-gentoo-r7. has your kernel configuration (/usr/src/linux/.config) the following enabled? CONFIG_MMU_NOTIFIER=y > Anyone else has such problem? FWIW I have kvm-82 compiled against linux-2.6.27-gentoo-r7 Carlo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
