Zhao, Yunfeng wrote:
It's hard to tell.
We didn't run installation of Vista nightly.
Anthony's magic tester, where are you?
--
error compiling committee.c: too many arguments to function
-
This SF.net email is
Ryan Harper wrote:
We have a test which verifies #GP is not caused by setting the bits on
either AMD or Intel chips. Stray bits can get turned on in some cases
when switching between 64-bit, PAE and non-PAE address modes.
Were you testing on a 64-bit host kernel?
64-bit Host running
hi,
with kvm-40 in a x86_64 host bridged mode:
---
e1000: peth0: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex
e1000: peth0: e1000_watchdog_task: 10/100 speed: disabling TSO
---
while on the guests (both x86_64 and i386) are full with such
Night kvm-devel
2 pills a day got me an extra 2 inches
Artimus mayazur
http://www.meilidg.com/
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
Farkas Levente wrote:
hi,
with kvm-40 in a x86_64 host bridged mode:
---
e1000: peth0: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex
e1000: peth0: e1000_watchdog_task: 10/100 speed: disabling TSO
---
while on the guests (both x86_64
Cam Macdonell wrote:
Dor Laor wrote:
Hmm, well it's an old code that Uri will rebase for virtio so just
drop it.
I just thought it might help.
No worries. In terms of moving to virtIO I grabbed your tree
previously to look at it. To test and play around with virtIO, do I
need to
Still recovering from the lapic merge with two important fixes. Also
progress on paravirtualization and the x86 emulator.
As usual, if you have an issue please try with -no-kvm-irqchip and report.
Changes since kvm-40:
- refactor hypercall infrastructure for simplicity and better smp
support
This patch corrects an inconcistency of cr2 introduced by the x86 emulator
split.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
---
drivers/kvm/x86_emulate.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
hi,
kvm-41 crash the host after i start the guests (in 30 sec). both if i
give more cpus to the guest, or even if i give only one cpu per guest.
the host console are full with:
do_page_fault
do_page_fault
error_exit
do_page_fault
do_page_fault
error_exit
do_trap
do_invalid_op
sysret_check
Nitin A Kamble wrote:
Hi Avi,
Some emulation case statements have gone to wrong place in the
upstream tree. This patch fixes that.
Applied, thanks.
This time I have created the patch
using the git-format-patch command as per your suggestion.
Much easier to apply. But now my mailer
Laurent Vivier wrote:
This patch corrects an inconcistency of cr2 introduced by the x86 emulator
split.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is
Avi Kivity wrote:
Farkas Levente wrote:
hi,
kvm-41 crash the host after i start the guests (in 30 sec). both if i
give more cpus to the guest, or even if i give only one cpu per guest.
the host console are full with:
What host kernel? i386 or x86_64?
host: centos-5 x86_64,
guests:
Farkas Levente wrote:
Avi Kivity wrote:
Farkas Levente wrote:
hi,
kvm-41 crash the host after i start the guests (in 30 sec). both if i
give more cpus to the guest, or even if i give only one cpu per guest.
the host console are full with:
What host kernel? i386 or
Avi Kivity wrote:
Farkas Levente wrote:
Avi Kivity wrote:
Farkas Levente wrote:
hi,
kvm-41 crash the host after i start the guests (in 30 sec). both if i
give more cpus to the guest, or even if i give only one cpu per guest.
the host console are full with:
What host
[EMAIL PROTECTED] wrote:
repository: /home/avi/kvm/linux-2.6
branch: (no branch)
commit 5e7a195fc4b1c0df577658e01a25b91d49bc68ee
Author: Avi Kivity [EMAIL PROTECTED]
Date: Tue Sep 18 14:19:00 2007 +0200
KVM: Fix ioapic level-triggered interrupt redelivery
The ioapic failed to
Dong, Eddie wrote:
diff --git a/drivers/kvm/ioapic.c b/drivers/kvm/ioapic.c
index 3ee13c3..b8c7da4 100644
--- a/drivers/kvm/ioapic.c
+++ b/drivers/kvm/ioapic.c
@@ -243,17 +243,10 @@ void kvm_ioapic_set_irq(struct
kvm_ioapic *ioapic, int irq, int level)
entry =
Izik Eidus wrote:
this bug started at commit 091b206f6c56f2329e11bac2fa40d6f236ab0bc2
and it related to the changes that were made in vmx.c
Laurent, can you help us with this?
(openbsd find the harddisk to be 68mb while it should be 2048mb)
Of course.
Could you provide me the disk image
Avi Kivity wrote:
Also architectually level = 0 may also mean an IRQ to IOAPIC
if the polarity is negative though today we may not see this. But
this change will expose the risk, and the propose of pass-through
hardware device will change the polarity.
Sure, if you run Xen + pci
Laurent Vivier wrote:
Izik Eidus wrote:
this bug started at commit 091b206f6c56f2329e11bac2fa40d6f236ab0bc2
and it related to the changes that were made in vmx.c
Laurent, can you help us with this?
(openbsd find the harddisk to be 68mb while it should be 2048mb)
Of course.
Avi Kivity wrote:
Avi Kivity wrote:
Also architectually level = 0 may also mean an IRQ to IOAPIC
if the polarity is negative though today we may not see this. But
this change will expose the risk, and the propose of pass-through
hardware device will change the polarity.
Sure, if you
Dong, Eddie wrote:
Avi Kivity wrote:
Avi Kivity wrote:
Also architectually level = 0 may also mean an IRQ to IOAPIC
if the polarity is negative though today we may not see this. But
this change will expose the risk, and the propose of pass-through
hardware device will change the
* Avi Kivity [EMAIL PROTECTED] [2007-09-19 03:58]:
Ryan Harper wrote:
We have a test which verifies #GP is not caused by setting the bits on
either AMD or Intel chips. Stray bits can get turned on in some cases
when switching between 64-bit, PAE and non-PAE address modes.
Were you
Ryan Harper wrote:
* Avi Kivity [EMAIL PROTECTED] [2007-09-19 03:58]:
Ryan Harper wrote:
We have a test which verifies #GP is not caused by setting the bits on
either AMD or Intel chips. Stray bits can get turned on in some cases
when switching between 64-bit, PAE and non-PAE
On Wed, 2007-09-19 at 10:08 -0500, Anthony Liguori wrote:
Ryan Harper wrote:
* Avi Kivity [EMAIL PROTECTED] [2007-09-19 03:58]:
Ryan Harper wrote:
We have a test which verifies #GP is not caused by setting the bits on
either AMD or Intel chips. Stray bits can get turned on in
Zachary Amsden wrote:
BTW, VMware can run 64-bit guests on a 32-bit host, all it needs is
capable hardware, so unless you mask the 64-bit support in KVM, you
could have a strange situation where the 32-bit KVM starts (or tries to
start, expecting success) running 64-bit code. I can imagine a
Farkas Levente wrote:
hi,
on our host machine there is always a kernel message:
---
kvm: emulating exchange as write
---
why? why log it directly into the console and is it important?
It's a reminder to me that we're not
Hello,
This is a followup from my last message stating that my guest os dont load
up correctly. The problem was that my xp or vista guest os uses 100% cpu at
startup and frequent lockup then continue to load.
I played a bit with my startup parameters to find out that the problem is
related the
Daniel Paquet wrote:
Hello,
This is a followup from my last message stating that my guest os
dont load up correctly. The problem was that my xp or vista guest os
uses 100% cpu at startup and frequent lockup then continue to load.
I played a bit with my startup parameters to find out
Well this is very strange, to make it work I have to close the KVM window
and restart the guest, and eventually it will start right.
It is also starting right when I install a new version, like I just passed
from version 40 to 41 and tada my guests starts okay.
I dont have that much trafic on my
hi,
I am thinking to contribute some to KVM project and am very interested
in changing the mmu page eviction algorithm from FIFO to LRU.
If you already start working on this item, could let me know you
schedule and what I should do next?
Any comments will be highly appreciated!
Thanks,
Neo
--
* Ryan Harper [EMAIL PROTECTED] [2007-09-19 09:56]:
* Avi Kivity [EMAIL PROTECTED] [2007-09-19 03:58]:
Ryan Harper wrote:
We have a test which verifies #GP is not caused by setting the bits on
either AMD or Intel chips. Stray bits can get turned on in some cases
when switching between
Okay I just rebooted.
Now the guest os takes forever to startup with the same behaviour as before.
I have no traffic on my tap device. The only trafic on tap device is from
the guest os and for now there is not much.
And here is the output of dmesg
apic write: bad size=1 fee00030
Ignoring
Daniel Paquet wrote:
Okay I just rebooted.
Now the guest os takes forever to startup with the same behaviour as
before.
I have no traffic on my tap device. The only trafic on tap device is
from the guest os and for now there is not much.
And here is the output of dmesg
apic write: bad
Well well, that did it!!!
For now I even restarted my host machine and the guest os boots flawlessly
now with taskset! Oh well, I now know a new nice linux app taskset :)
I saw similar problems with some games under windows, that you had to set
the affinity to a specific core, if not you were
Daniel Paquet wrote:
Well well, that did it!!!
For now I even restarted my host machine and the guest os boots
flawlessly now with taskset! Oh well, I now know a new nice linux app
taskset :)
I saw similar problems with some games under windows, that you had to
set the affinity to a
Carlo Marcelo Arenas Belon wrote:
Add command line option description to qemu for -no-kvm-irqchip to
complement commit 8936d5f864ee809af05fe22673d8e891bedec7f1
Applied, thanks.
--
error compiling committee.c: too many arguments to function
Well I rebooted again, and now my guest os starts right without taskset so
for now I using the -no-kvm-irqchip wont tell if thereis an issue with smp.
I will have to wait untill the problem gets back to try this parameter. I
will try it and send the results.
On 9/19/07, Avi Kivity [EMAIL
Daniel Paquet wrote:
Just tried -no-kvmirqchip and it's a no go, and after it I tryed
without taskset and -no-kvmirqchip and it worked... Anyway I will
allways use taskset until now.
Sorry, hard to piece all the info from the scattered reports. Please
report, for each of:
- regular
-
Okay so here is the parameters
regular :
kvm -no-rtc -hda disks/vista.qcow2 -localtime -m 512 -net
nic,model=ne2k_pci,macaddr=00:00:00:00:00:01 -net tap,ifname=tap0
Well for the others I just add taskset 1 or -no-kvm-irqchip
regular = sometimes work, sometimes dont work.
-no-kvm-irqchip = never
On Sun, 2007-09-16 at 22:00 +0200, Avi Kivity wrote:
The attached patch adds support for a relatively basic boot device
selection menu to the bochs bios code.
[snip]
This is nice! Two comments:
- it would be nice for qemu to provide the bios an indication if the
'-boot' parameter was
On Wed, Sep 19, 2007 at 03:49:15PM +0200, Laurent Vivier wrote:
Izik Eidus wrote:
this bug started at commit 091b206f6c56f2329e11bac2fa40d6f236ab0bc2
and it related to the changes that were made in vmx.c
Laurent, can you help us with this?
(openbsd find the harddisk to be 68mb while it
Avi Kivity wrote:
Still recovering from the lapic merge with two important fixes. Also
progress on paravirtualization and the x86 emulator.
As usual, if you have an issue please try with -no-kvm-irqchip and report.
Changes since kvm-40:
- refactor hypercall infrastructure for simplicity
Simon Gao wrote:
kvm-41 breaks on 32bit 2.6.22-gentoo-r5, Genuine Intel(R) CPU
T2500 @ 2.00GHz
# modprobe kvm-intel
FATAL: Error inserting kvm_intel
(/lib/modules/2.6.22-gentoo-r5/extra/kvm-intel.ko): Unknown symbol in
module, or unknown parameter (see dmesg)
# dmesg
Jeremy Katz wrote:
On Sun, 2007-09-16 at 22:00 +0200, Avi Kivity wrote:
The attached patch adds support for a relatively basic boot device
selection menu to the bochs bios code.
[snip]
This is nice! Two comments:
- it would be nice for qemu to provide the bios an
44 matches
Mail list logo
