Avi Kivity wrote:
Unfortunately, no such luck. Apparently this is not msr/cpuid related -
perhaps power management. Can you enable the kvm_mmio and kvm_pio
events? Perhaps they will provide a clue.
Yeah, I did take a quick glance at the trace and figured that there
would be some "(#GP)" s
On 01/26/2010 12:25 AM, Mark Cave-Ayland wrote:
Avi Kivity wrote:
Unfortunately msr tracing fails to record some important
information. I just posted a patch to fix this. Can you rerun from
kvm.git branch msr-trace? That contains the fix.
Done.
http://pastebin.com/m209b1f13
Hopefully th
Avi Kivity wrote:
Unfortunately msr tracing fails to record some important information. I
just posted a patch to fix this. Can you rerun from kvm.git branch
msr-trace? That contains the fix.
Done.
http://pastebin.com/m209b1f13
Hopefully this trace should give a better indication of when
On 01/25/2010 06:54 PM, Mark Cave-Ayland wrote:
Avi Kivity wrote:
echo kvm > /sys/kernel/debug/tracing/set_event
(you can also enable just the msr and cpuid events, see
/sys/kernel/debug/tracing/events)
cat /sys/kernel/debug/trace
(goes on a kernel debugging crash course)
Okay I think I'v
Avi Kivity wrote:
echo kvm > /sys/kernel/debug/tracing/set_event
(you can also enable just the msr and cpuid events, see
/sys/kernel/debug/tracing/events)
cat /sys/kernel/debug/trace
(goes on a kernel debugging crash course)
Okay I think I've got the information you need for msr and cpuid:
On 01/25/2010 06:18 PM, Mark Cave-Ayland wrote:
Avi Kivity wrote:
I've had a quick look at this, and I can't work out how to enable
kvm trace in Kconfig. Is there any documentation on how to build
with kvm trace enabled for debugging?
CONFIG_FTRACE, CONFIG_TRACEPOINTS should be sufficient, I
Avi Kivity wrote:
I've had a quick look at this, and I can't work out how to enable kvm
trace in Kconfig. Is there any documentation on how to build with kvm
trace enabled for debugging?
CONFIG_FTRACE, CONFIG_TRACEPOINTS should be sufficient, I think. 2.6.32
or later IIRC.
Hmmm these alre
On 01/25/2010 06:06 PM, Mark Cave-Ayland wrote:
I'd like to find out why processor.sys fails, but the .1->.2 change
isn't any help unfortunately. It looks like here too there are two
bugs involved: one in kvm which doesn't act like processor.sys
expects it, and one in processor.sys which cau
Avi Kivity wrote:
Well, there was a regression, but it was in 0.12.1.1.
There were two bugs involved, a serious one (that caused the cpuid to
show up as AMD) hiding the less serious one (that causes processor.sys
to BSOD).
Okay, understood. I must have just got lucky when upgrading from old
On 01/25/2010 05:15 PM, Mark Cave-Ayland wrote:
Unfortunately it still crashes with the same
"DRIVER_UNLOADED_WITHOUT_CANCELING_PENDING_OPERATIONS" BSOD :(
Well, don't do that then. Is there any specific functionality in
processor.sys that you're missing?
No, not at all. My only concern wa
Avi Kivity wrote:
Hi Avi,
I've just done a quick test re-enabling processor.sys on my WinXP
guest and then did the following:
virsh stop winxp
rmmod kvm_intel
rmmod kvm
modprobe kvm ignore_msrs=1
modprobe kvm_intel
virsh start winxp
Unfortunately it still crashes with the same
"DRIVER_UNLO
On 01/07/2010 11:55 AM, Mark Cave-Ayland wrote:
Avi Kivity wrote:
I think the issue is probably similar to that explained in the
article above; with a new processor reported to the guest, the
internal processor driver tries to upload some kind of microcode to
the new device which fails and ca
On 01/07/2010 11:57 AM, Mark Cave-Ayland wrote:
Avi Kivity wrote:
I've just re-created the KVM image fresh from the VDI image once
again and can confirm that disabling just the Processor driver is
enough to allow the guest WinXP VM to function in qemu-kvm-0.12.1.2.
Perhaps the default for "-c
Avi Kivity wrote:
I've just re-created the KVM image fresh from the VDI image once again
and can confirm that disabling just the Processor driver is enough to
allow the guest WinXP VM to function in qemu-kvm-0.12.1.2. Perhaps the
default for "-cpu host" should not be changed in a micro release
Avi Kivity wrote:
I think the issue is probably similar to that explained in the article
above; with a new processor reported to the guest, the internal
processor driver tries to upload some kind of microcode to the new
device which fails and causes the guest to fall over. Can we teach KVM
to
On 01/06/2010 07:08 PM, Mark Cave-Ayland wrote:
Mark Cave-Ayland wrote:
A quick search took me to this page here:
http://blogs.msdn.com/virtual_pc_guy/archive/2005/10/24/484461.aspx
which explains the issue in more detail. I first tried disabling the
intelppm driver and rebooting, but that di
On 01/06/2010 05:45 PM, Mark Cave-Ayland wrote:
Avi Kivity wrote:
It probably did make some kind of difference. Please try a clean
install.
After several hours of testing, I've finally found out what the
problem is.
I tried a clean WinXP guest install and that worked, so it was
obviously
Mark Cave-Ayland wrote:
A quick search took me to this page here:
http://blogs.msdn.com/virtual_pc_guy/archive/2005/10/24/484461.aspx
which explains the issue in more detail. I first tried disabling the
intelppm driver and rebooting, but that didn't make a difference;
however disabling the Pr
Avi Kivity wrote:
It probably did make some kind of difference. Please try a clean install.
After several hours of testing, I've finally found out what the problem is.
I tried a clean WinXP guest install and that worked, so it was obviously
a driver issue. After disabling various drivers in
On 1/6/2010 3:14 PM, Mark Cave-Ayland wrote:
Gleb Natapov wrote:
Can you start is in safe mode and see which driver fails?
Hmmm. Booting in Safe Mode seems to work fine, although the next
attempt to boot into Normal Mode returns a BSOD with
"INTERNAL_POWER_ERROR" which is new to me. Subsequ
Gleb Natapov wrote:
Can you start is in safe mode and see which driver fails?
Hmmm. Booting in Safe Mode seems to work fine, although the next attempt
to boot into Normal Mode returns a BSOD with "INTERNAL_POWER_ERROR"
which is new to me. Subsequent reboots then return to the
"DRIVER_UNLOAD
On 01/06/2010 02:50 PM, Mark Cave-Ayland wrote:
Avi Kivity wrote:
Did you install using 0.12.1.1 and then run using 0.12.1.2? If so,
it seems Windows XP is not able to move from AMD to Intel.
No, although the original VM was built in VirtualBox if that makes a
difference? I had to manually
On Wed, Jan 06, 2010 at 12:50:29PM +, Mark Cave-Ayland wrote:
> Avi Kivity wrote:
>
> >Did you install using 0.12.1.1 and then run using 0.12.1.2? If
> >so, it seems Windows XP is not able to move from AMD to Intel.
>
> No, although the original VM was built in VirtualBox if that makes a
> d
On Wed, Jan 06, 2010 at 12:50:29PM +, Mark Cave-Ayland wrote:
> Avi Kivity wrote:
>
> >Did you install using 0.12.1.1 and then run using 0.12.1.2? If
> >so, it seems Windows XP is not able to move from AMD to Intel.
>
> No, although the original VM was built in VirtualBox if that makes a
> d
Avi Kivity wrote:
Did you install using 0.12.1.1 and then run using 0.12.1.2? If so, it
seems Windows XP is not able to move from AMD to Intel.
No, although the original VM was built in VirtualBox if that makes a
difference? I had to manually implement the "merge ide" fix here
(http://suppo
Marcelo Tosatti wrote:
> Mark,
>
> Thanks for tracking it down. Is there any difference with "-cpu host"
> option?
Yeah; if I launch 0.12.1.1 which normally works with an additional "-cpu
host" option then kvm crashes in exactly the same way.
HTH,
Mark.
--
Mark Cave-Ayland - Senior Technic
On 01/06/2010 01:25 PM, Mark Cave-Ayland wrote:
Good news - I downloaded the userspace git repository and managed to
identify the offending commit between 0.12.1.1 and 0.12.1.2 using git
bisect:
4dad7ff32aa6dcf18cef0c606d8fb43ff0b939a1 is first bad commit
commit 4dad7ff32aa6dcf18cef0c606d8fb4
On Wed, Jan 06, 2010 at 02:33:36PM +0200, Gleb Natapov wrote:
> On Wed, Jan 06, 2010 at 10:29:18AM -0200, Marcelo Tosatti wrote:
> > On Wed, Jan 06, 2010 at 11:25:14AM +, Mark Cave-Ayland wrote:
> > > Avi Kivity wrote:
> > >
> > >>> I think I'm experiencing a regression with the new qemu-kvm-0.
On Wed, Jan 06, 2010 at 10:29:18AM -0200, Marcelo Tosatti wrote:
> On Wed, Jan 06, 2010 at 11:25:14AM +, Mark Cave-Ayland wrote:
> > Avi Kivity wrote:
> >
> >>> I think I'm experiencing a regression with the new qemu-kvm-0.12.1.2
> >>> release compared to qemu-kvm-0.12.1.1 with a WinXP guest
On Wed, Jan 06, 2010 at 11:25:14AM +, Mark Cave-Ayland wrote:
> Avi Kivity wrote:
>
>>> I think I'm experiencing a regression with the new qemu-kvm-0.12.1.2
>>> release compared to qemu-kvm-0.12.1.1 with a WinXP guest on Linux.
>>>
>>> I can boot my WinXP guest without a problem under qemu-kv
Avi Kivity wrote:
I think I'm experiencing a regression with the new qemu-kvm-0.12.1.2
release compared to qemu-kvm-0.12.1.1 with a WinXP guest on Linux.
I can boot my WinXP guest without a problem under qemu-kvm-0.12.1.1,
however under qemu-kvm-0.12.1.2 a couple of seconds after reaching the
Avi Kivity wrote:
I've confirmed by switching between the two installations several
times that the error consistently occurs with qemu-kvm-0.12.1.2 but
not qemu-kvm-0.12.1.1. Is this a known issue? This is on an x86_64
Debian Lenny host with a 2.6.32.2 kernel on Intel.
It's not a known issue
On 01/05/2010 06:09 PM, Mark Cave-Ayland wrote:
Hi all,
I think I'm experiencing a regression with the new qemu-kvm-0.12.1.2
release compared to qemu-kvm-0.12.1.1 with a WinXP guest on Linux.
I can boot my WinXP guest without a problem under qemu-kvm-0.12.1.1,
however under qemu-kvm-0.12.1.2
Hi all,
I think I'm experiencing a regression with the new qemu-kvm-0.12.1.2
release compared to qemu-kvm-0.12.1.1 with a WinXP guest on Linux.
I can boot my WinXP guest without a problem under qemu-kvm-0.12.1.1,
however under qemu-kvm-0.12.1.2 a couple of seconds after reaching the
login sc
34 matches
Mail list logo
