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 was that the VM had been running
absolutely fine under older KVM and VirtualBox until the upgrade from
0.12.1.1 to 0.12.1.2 which made me think there had been a regression
somewhere along the line.
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).
I appreciate from tracking both qemu and kvm mailing lists that there
is currently a lot of rapid development occuring across both QEMU and
KVM, and hence sometimes things can break. It would be interesting to
find out exactly *why* this doesn't work in KVM and so I can provide
debugging assistance if you can point me in the right direction.
At the moment, I'm just happy that I can run the VM under KVM even
with the processor.sys driver disabled. At least by bringing up the
problem and solution on this mailing list thread then the solution is
documented for other people who find themselves in the same situation.
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 causes it to
UNLOAD_ITSELF_WITHOUT_CANCELLING_PENDING_OPERATIONS. You might try
running with kvm trace enabled and look at msr and cpuid accesses just
prior to the crash.
--
error compiling committee.c: too many arguments to function
--
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
