Re: [kvm-devel] [PATCH 1/3] Move common VGAState attributes to VGA_STATE_COMMON
Anthony Liguori wrote: vmware_vga.c uses functions in vga.c to do some things. They need to agree on which parts of their state struct is common and which aren't, otherwise they'll overwrite parts of each other's state. This patch makes it so. Signed-off-by: Soren Hansen [EMAIL PROTECTED] Reviewed-by: Anthony Liguori [EMAIL PROTECTED] The trick to passing through patches is to have a From: Original Author [EMAIL PROTECTED] line in the beginning, which git picks up and uses to maintain authorship information. Also, sign-off normally. Acked-by means I know the author while Reviewed-by means I know the author well. Anyway I applied all these patches, including the vmware BAR patch since it's a dependency. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] fix widescreen resolution issues (v3)
Andreas Winkelbauer wrote: hi, I'm sorry for messing up the last patch, I shouldn't work that late... I added the changes to pc.h (VGA_RAM_SIZE) and split up the patch in a qemu part and a vgabios part. Applied, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] The SMP RHEL 5.1 PAE guest can't boot up issue
Farkas Levente wrote:
will be a new release in the near future? since many of us waiting for
this bug to be fixed on quad and other multi core cpus.
Certainly. Can you try out the attached patch?
--
error compiling committee.c: too many arguments to function
diff --git a/kernel/ioapic.c b/kernel/ioapic.c
index 317f8e2..4232fd7 100644
--- a/kernel/ioapic.c
+++ b/kernel/ioapic.c
@@ -211,6 +211,10 @@ static void ioapic_deliver(struct kvm_ioapic *ioapic, int irq)
case IOAPIC_LOWEST_PRIORITY:
vcpu = kvm_get_lowest_prio_vcpu(ioapic-kvm, vector,
deliver_bitmask);
+#ifdef CONFIG_X86
+ if (irq == 0)
+ vcpu = ioapic-kvm-vcpus[0];
+#endif
if (vcpu != NULL)
ioapic_inj_irq(ioapic, vcpu, vector,
trig_mode, delivery_mode);
@@ -220,6 +224,10 @@ static void ioapic_deliver(struct kvm_ioapic *ioapic, int irq)
deliver_bitmask, vector, IOAPIC_LOWEST_PRIORITY);
break;
case IOAPIC_FIXED:
+#ifdef CONFIG_X86
+ if (irq == 0)
+ deliver_bitmask = 1;
+#endif
for (vcpu_id = 0; deliver_bitmask != 0; vcpu_id++) {
if (!(deliver_bitmask (1 vcpu_id)))
continue;
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Status of FreeBSD 6.3 as a guest
Colin Paul Adams wrote: This isn't mentioned on the guest status page. I went ahead and tried it anyway (32-bit). It works fine if I don't specify -smp 2. But qemu rejects -m 2048. -m 1024 is fine. I had over 3GB available memory (I presume all the memory is pae-fixed to avoid both host and guest paging - if I'm wrong, please explain) so I assumed this would be OK. Are you running on a 32-bit host? If so, try less memory (2047 might work, or perhaps less). For real large memory you need a 64-bit host. (btw, please update the guest status page) -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 4/15] mark processors as presents
Glauber Costa wrote:
mark processors as present through the _STA method
Signed-off-by: Glauber Costa [EMAIL PROTECTED]
---
bios/acpi-dsdt.dsl | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index e900795..cd42e23 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -25,9 +25,28 @@ DefinitionBlock (
0x1 // OEM Revision
)
{
+ Scope (\_PR)
+ {
+Processor (CPU0, 0x00, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPU1, 0x01, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPU2, 0x02, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPU3, 0x03, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPU4, 0x04, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPU5, 0x05, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPU6, 0x06, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPU7, 0x07, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPU8, 0x08, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPU9, 0x09, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPUA, 0x0a, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPUB, 0x0b, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPUC, 0x0c, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPUD, 0x0d, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPUE, 0x0e, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+}
There is now code in rombios32.c to do this. It needs to be removed.
See acpi_build_processor_ssdt().
Scope (\)
{
+
/* CMOS memory access */
OperationRegion (CMS, SystemIO, 0x70, 0x02)
Field (CMS, ByteAcc, NoLock, Preserve)
-
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/15] introduce cpu_set to qemu monitor
Glauber Costa wrote:
in this patch, cpu_set is introduced to qemu monitor
semantics is : cpu_set x online|offline.
it will then tell the acpi backend to signal cpu x.
index e21ded0..18561e0 100644
--- a/qemu/hw/acpi.c
+++ b/qemu/hw/acpi.c
@@ -533,3 +533,6 @@ void qemu_system_powerdown(void)
}
}
#endif
+void qemu_system_cpu_hot_add(int cpu, int state)
+{
+}
Missing empty line.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/15] Review: acpi processor hotplug
Glauber Costa wrote: Hi, In this series, I'm sending the result-so-far of my work with acpi for processor hotplug. I'm able to put a cpu up and down (with the help of some udev scripts I wrote), but it still has some known bugs and issues. For x86_64 linux machines (because the kernel supports it), you can plug cpus that _were not_ listed initially in smp_cpus. The usage is : cpu_set x (online/offline), in qemu monitor. It will then send the proper signals to the cpu #x. However, it is important to note that: * there's no way to know if it suceeded. (ex, if the udev scripts are not running, the cpu will not be put up, and you'll never know) * there's no way to unconditionally send an add signal. (if you send BUS_CHECK again, and the cpu is already marked as present, it will offline it instead) because of that, management gets a bit complicated. The ideal situation is to specify: I want Y cpus, and have it. Error reported in case it fails. Because of that, I _still_ advocate for an alternative virtio implementation. ACPI still plays its role in this scenario, but not the full role. Perhaps this can be implemented in userspace; I don't see anything that needs to be in the kernel for this. Since it needs to work independently of networking, maybe it's a good first use for an AF_VIRT protocol family (which can be implemented on top of virtio). In my TODO list, you'll find: * fix some more issues in this code, and merge the gently comments I'm sure you'll make It's difficult with such near-perfect patchsets. You're reducing me to whitespace comments. Please post to qemu-devel as well so they can ignore it as usual. * device acpi hotplug * virtio cpu hotplug for linux (meaning refactoring the existing patch) Slightly related to this would be a qemu monitor mechanism to set vcpu-cpu affinity. * occupy 24 territories. * conquer 18 territories with at least 2 battalions on each. Sounds risky. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] qemu: implicit precedence for logical operator in has_work
Carlo Marcelo Arenas Belon wrote: janitorial fix for : qemu/qemu-kvm.c: In function `has_work': qemu/qemu-kvm.c:140: warning: suggest parentheses around within || Applied, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] qemu: implicit precedence for logical operator in has_work
Alexander Graf wrote:
On Feb 20, 2008, at 9:30 AM, Carlo Marcelo Arenas Belon wrote:
janitorial fix for :
qemu/qemu-kvm.c: In function `has_work':
qemu/qemu-kvm.c:140: warning: suggest parentheses around within ||
Signed-off-by: Carlo Marcelo Arenas Belon [EMAIL PROTECTED]
---
qemu/qemu-kvm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index ffc59d5..4056453 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -137,7 +137,7 @@ extern int vm_running;
static int has_work(CPUState *env)
{
-if (!vm_running || env vcpu_info[env-cpu_index].stopped)
+if (!vm_running || (env vcpu_info[env-cpu_index].stopped))
What exactly is the env check needed for here?
This code arrived from another location, where it was necessary.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] still seeing network freezes with rtl8139 nic
david ahern wrote: I know this issue has been discussed on this list before, but I am still experiencing network freezes in a guest that requires a restart to clear. When the network freezes in the guest I no longer see the network interrupts counter incrementing (i.e., the eth0 counter in /proc/interrupts in the guest). Using the crash utility, I verified that the interrupt is still enabled on the guest side and that no interrupts are pending. This suggests that the interrupts are not getting delivered to the VM. [...] I am continuing to look into the irq processing on the kvm/qemu side. I'd like to know if anyone has suggestions on what to look at. This is my first foray into the kvm and qemu code, and it's a lot to take in all at once. Standard procedure is to run with -no-kvm and -no-kvm-irqchip, to see if the problem is in qemu proper, the in-kernel irq handling, or the rest of kvm. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Allow kvm to use more than 4 VCPUs
Anthony Liguori wrote: This patch actually allows KVM to be used with more than 4 VCPUs. The change in qemu-kvm.c was pretty difficult to find because it was using an open coded array size of 4. I changed that array to be 256 since that's the real maximum on x86 and the additional storage space is a pretty trivial cost. Applied, thanks. Please keep libkvm and qemu patches separate (when possible). -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Allow kvm to use more than 4 VCPUs
On Sun, Feb 24, 2008 at 8:16 AM, Avi Kivity [EMAIL PROTECTED] wrote: Anthony Liguori wrote: This patch actually allows KVM to be used with more than 4 VCPUs. The change in qemu-kvm.c was pretty difficult to find because it was using an open coded array size of 4. I changed that array to be 256 since that's the real maximum on x86 and the additional storage space is a pretty trivial cost. Applied, thanks. Please keep libkvm and qemu patches separate (when possible). Very nice ! After I test it, I will close this SMP bug: http://sourceforge.net/tracker/index.php?func=detailaid=1850037group_id=180599atid=893831 -- -Alexey Eremenko Technologov - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1900829 ] KVM crashes with AMD NPT
Bugs item #1900829, was opened at 2008-02-24 14:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1900829group_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: Technologov (technologov) Assigned to: Nobody/Anonymous (nobody) Summary: KVM crashes with AMD NPT Initial Comment: KVM-61 guest crashes, when NPT=on, and when VM is accessed via VNC. It is 100% reproducible. Loading kvm-amd module without NPT, works fine. like: # modprobe kvm-amd npt=0 Host: AMD Barcelona, F7/x64, KVM-61. Guest: Debian 4/x86. The Command sent to Qemu/KVM: /usr/local/bin/qemu-system-x86_64 -hda /vm/debian4 -test32.qcow2 -m 256 -monitor tcp:localhost:4517,server,nowait -cdrom /isos/linu x/debian-40r0-i386-DVD-1.iso -boot d -name Debian4 -vnc :10 == *** glibc detected *** /usr/local/bin/qemu-system-x86_64: realloc(): invalid old size: 0x2aaabbde1010 *** === Backtrace: = /lib64/libc.so.6[0x3dd0271fbb] /lib64/libc.so.6(realloc+0x124)[0x3dd0273d94] /usr/local/bin/qemu-system-x86_64[0x471c02] /usr/local/bin/qemu-system-x86_64[0x47229b] /usr/local/bin/qemu-system-x86_64[0x471583] /usr/local/bin/qemu-system-x86_64[0x40de98] /usr/local/bin/qemu-system-x86_64[0x4fd81d] /usr/local/bin/qemu-system-x86_64[0x4fd859] /usr/local/bin/qemu-system-x86_64[0x4fe0a6] /usr/local/bin/qemu-system-x86_64[0x410e3d] /lib64/libc.so.6(__libc_start_main+0xf4)[0x3dd021daa4] /usr/local/bin/qemu-system-x86_64[0x406219] === Memory map: 0040-0057f000 r-xp fd:00 1952887/usr/lo cal/bin/qemu-system-x86_64 0077e000-007b2000 rw-p 0017e000 fd:00 1952887/usr/lo cal/bin/qemu-system-x86_64 007b2000-01a85000 rw-p 007b2000 00:00 0 01a85000-02a86000 rwxp 01a85000 00:00 0 02a86000-02e12000 rw-p 02a86000 00:00 0 [heap] 3238a0-3238a82000 r-xp fd:00 1266722/lib64/ libm-2.6.so 3238a82000-3238c81000 ---p 00082000 fd:00 1266722/lib64/ libm-2.6.so 3238c81000-3238c82000 r--p 00081000 fd:00 1266722/lib64/ libm-2.6.so 3238c82000-3238c83000 rw-p 00082000 fd:00 1266722/lib64/ libm-2.6.so 3604a0-3604a65000 r-xp fd:00 1954651/usr/li b64/libSDL-1.2.so.0.11.0 3604a65000-3604c65000 ---p 00065000 fd:00 1954651/usr/li b64/libSDL-1.2.so.0.11.0 3604c65000-3604c68000 rw-p 00065000 fd:00 1954651/usr/li b64/libSDL-1.2.so.0.11.0 3604c68000-3604c95000 rw-p 3604c68000 00:00 0 3dcfe0-3dcfe1a000 r-xp fd:00 1267006/lib64/ ld-2.6.so 3dd0019000-3dd001a000 r--p 00019000 fd:00 1267006/lib64/ ld-2.6.so 3dd001a000-3dd001b000 rw-p 0001a000 fd:00 1267006/lib64/ ld-2.6.so 3dd020-3dd0347000 r-xp fd:00 1267007/lib64/ libc-2.6.so 3dd0347000-3dd0546000 ---p 00147000 fd:00 1267007/lib64/ libc-2.6.so 3dd0546000-3dd054a000 r--p 00146000 fd:00 1267007/lib64/ libc-2.6.so 3dd054a000-3dd054b000 rw-p 0014a000 fd:00 1267007/lib64/ libc-2.6.so 3dd054b000-3dd055 rw-p 3dd054b000 00:00 0 3dd060-3dd0602000 r-xp fd:00 1267010/lib64/ libdl-2.6.so 3dd0602000-3dd0802000 ---p 2000 fd:00 1267010/lib64/ libdl-2.6.so 3dd0802000-3dd0803000 r--p 2000 fd:00 1267010/lib64/ libdl-2.6.so 3dd0803000-3dd0804000 rw-p 3000 fd:00 1267010/lib64/ libdl-2.6.so 3dd0e0-3dd0e14000 r-xp fd:00 1267008/lib64/ libz.so.1.2.3 3dd0e14000-3dd1013000 ---p 00014000 fd:00 1267008/lib64/ libz.so.1.2.3 3dd1013000-3dd1014000 rw-p 00013000 fd:00 1267008/lib64/ libz.so.1.2.3 3dd120-3dd1215000 r-xp fd:00 1267012/lib64/ libpthread-2.6.so 3dd1215000-3dd1414000 ---p 00015000 fd:00 1267012/lib64/ libpthread-2.6.so 3dd1414000-3dd1415000 r--p 00014000 fd:00 1267012/lib64/ libpthread-2.6.so 3dd1415000-3dd1416000 rw-p 00015000 fd:00 1267012/lib64/ libpthread-2.6.so 3dd1416000-3dd141a000 rw-p 3dd1416000 00:00 0 3dd220-3dd220d000 r-xp fd:00 1267013/lib64/ libgcc_s-4.1.2-20070503.so.1 3dd220d000-3dd240d000 ---p d000 fd:00 1267013/lib64/ libgcc_s-4.1.2-20070503.so.1 3dd240d000-3dd240e000 rw-p d000 fd:00
Re: [kvm-devel] [PATCH 1/3] Move common VGAState attributes to VGA_STATE_COMMON
Avi Kivity wrote: The trick to passing through patches is to have a From: Original Author [EMAIL PROTECTED] line in the beginning, which git picks up and uses to maintain authorship information. Also, sign-off normally. Acked-by means I know the author while Reviewed-by means I know the author well. Does From have to be the first line? git-send-email never seems to do anything with From for me. Regards, Anthony Liguori Anyway I applied all these patches, including the vmware BAR patch since it's a dependency. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/3] Move common VGAState attributes to VGA_STATE_COMMON
Anthony Liguori wrote: Avi Kivity wrote: The trick to passing through patches is to have a From: Original Author [EMAIL PROTECTED] line in the beginning, which git picks up and uses to maintain authorship information. Also, sign-off normally. Acked-by means I know the author while Reviewed-by means I know the author well. Does From have to be the first line? Yes (but after the regular email headers). git-send-email never seems to do anything with From for me. It's 'git am' which is the target of this. When applying such a patch from email, it will set the author automatically. The whole thing should work automatically, so if the patch has the correct authorship in your repo, it should come out fine without further effort. Not sure if format-patch or send-email is responsible. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Status of FreeBSD 6.3 as a guest
Avi == Avi Kivity [EMAIL PROTECTED] writes: Avi Colin Paul Adams wrote: This isn't mentioned on the guest status page. I went ahead and tried it anyway (32-bit). It works fine if I don't specify -smp 2. But qemu rejects -m 2048. -m 1024 is fine. I had over 3GB available memory (I presume all the memory is pae-fixed to avoid both host and guest paging - if I'm wrong, please explain) so I assumed this would be OK. Are you running on a 32-bit host? If so, try less memory (2047 might Avi work, or perhaps less). No - it's a 64-bit host with 8GB and a quad processor. -- Colin Adams Preston Lancashire - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Status of FreeBSD 6.3 as a guest
Avi == Avi Kivity [EMAIL PROTECTED] writes: Avi (btw, please update the guest status page) I did, but the table formatting is displaying as data for the line I added. I don't know why. Could someone please fix it, and then tell me what I did wrong? -- Colin Adams Preston Lancashire - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] still seeing network freezes with rtl8139 nic
I've run a lot more tests: - with the -no-kvm-irqchip option the vm eventully stops responding to network or console, - with the -no-kvm option the performance is so bad I cannot get our ap up and running so the results are inconclusive, - I've tried the e1000 and pcnet nic models and both showed the network lockup; with the ne2k_pci nic I did not see dropped packets and the network never locked up in 12+ hours, but system CPU time was 10% higher than when the rtl8139 nic was working - if I remove the if (!change) return optimization from pci_set_irq the rtl8139 nic worked fine for 16+ hours. I'm not recommending this as a fix, just confirming that the problem goes away. - I tried adding a thread mutex to the rtl8139 device model around accesses to the RTL8139State data, but the network still locked up. david Avi Kivity wrote: david ahern wrote: I know this issue has been discussed on this list before, but I am still experiencing network freezes in a guest that requires a restart to clear. When the network freezes in the guest I no longer see the network interrupts counter incrementing (i.e., the eth0 counter in /proc/interrupts in the guest). Using the crash utility, I verified that the interrupt is still enabled on the guest side and that no interrupts are pending. This suggests that the interrupts are not getting delivered to the VM. [...] I am continuing to look into the irq processing on the kvm/qemu side. I'd like to know if anyone has suggestions on what to look at. This is my first foray into the kvm and qemu code, and it's a lot to take in all at once. Standard procedure is to run with -no-kvm and -no-kvm-irqchip, to see if the problem is in qemu proper, the in-kernel irq handling, or the rest of kvm. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] eth0: transmit timed out
Hi, I am running KVM 61 on CentOS 5.1 x86_64 (on a Dell PowerEdge 2950 III). I start my virtual machine as follows: qemu-kvm -hda /dev/kvm_sdb/geust_root -m 1024 -net tap -net nic,vlan=0,macaddr=00:16:3e:00:00:02 -daemonize -nographic -smp 2 The problem is that when the guest (also CentOS 5.1 x86_64) utilizes the network heavily (scp to a machine on the same switch, around 12 mbyte/s) the network on the virtual machine just drops out. I can no longer ping the virtual machine, and any existing SSH sessions die. If I connect to the virtual machine using VNC everything looks okay (eth0 is up, routes are okay), but I still cannot connect to anything. All other virtual machines on the same host continue to work as if nothing has happened. The same problem occurred in -58 and -59. /var/log/messages on the guest says: NETDEV WATCHDOG: eth0: transmit timed out eth0: link up, 100Mbps, full-duplex, lpa 0x05E1 Any suggestions (permanent fixes or temporary workarounds, I'll take what you got) would be much appreciated. Thanks for all the great work :) -Arne - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] eth0: transmit timed out
I presume you are using the default rtl8139 nic. Correct? What does 'ethtool -S eth0' show when the network locks up? Many months ago adding 'noapic' to the (guest) kernel boot parameters helped, but that option is not currently helping with my RHEL4 networking issues. A thread for this issue is at: http://sourceforge.net/tracker/index.php?func=detailaid=1802082group_id=180599atid=893831 david Arne Kepp wrote: Hi, I am running KVM 61 on CentOS 5.1 x86_64 (on a Dell PowerEdge 2950 III). I start my virtual machine as follows: qemu-kvm -hda /dev/kvm_sdb/geust_root -m 1024 -net tap -net nic,vlan=0,macaddr=00:16:3e:00:00:02 -daemonize -nographic -smp 2 The problem is that when the guest (also CentOS 5.1 x86_64) utilizes the network heavily (scp to a machine on the same switch, around 12 mbyte/s) the network on the virtual machine just drops out. I can no longer ping the virtual machine, and any existing SSH sessions die. If I connect to the virtual machine using VNC everything looks okay (eth0 is up, routes are okay), but I still cannot connect to anything. All other virtual machines on the same host continue to work as if nothing has happened. The same problem occurred in -58 and -59. /var/log/messages on the guest says: NETDEV WATCHDOG: eth0: transmit timed out eth0: link up, 100Mbps, full-duplex, lpa 0x05E1 Any suggestions (permanent fixes or temporary workarounds, I'll take what you got) would be much appreciated. Thanks for all the great work :) -Arne - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] eth0: transmit timed out
Thanks David, Yes, I am using rtl8139 and it is running 2.6.18-53.1.13.el5 (Red Hat kernel, CentOS). ethtool -S eth0 on the guest says, when locked up: NIC statistics: early_rx: 0 tx_buf_mapped: 0 tx_timeouts: 4 rx_lost_in_ring: 0 It appears that 'noapic' did the trick, which is great, thanks! I am somewhat worried I'll be missing out on some SMP performance? But that's secondary. Please let me know if there is anything I can do to gather any more info to help debug the problem. -Arne david ahern wrote: I presume you are using the default rtl8139 nic. Correct? What does 'ethtool -S eth0' show when the network locks up? Many months ago adding 'noapic' to the (guest) kernel boot parameters helped, but that option is not currently helping with my RHEL4 networking issues. A thread for this issue is at: http://sourceforge.net/tracker/index.php?func=detailaid=1802082group_id=180599atid=893831 david Arne Kepp wrote: Hi, I am running KVM 61 on CentOS 5.1 x86_64 (on a Dell PowerEdge 2950 III). I start my virtual machine as follows: qemu-kvm -hda /dev/kvm_sdb/geust_root -m 1024 -net tap -net nic,vlan=0,macaddr=00:16:3e:00:00:02 -daemonize -nographic -smp 2 The problem is that when the guest (also CentOS 5.1 x86_64) utilizes the network heavily (scp to a machine on the same switch, around 12 mbyte/s) the network on the virtual machine just drops out. I can no longer ping the virtual machine, and any existing SSH sessions die. If I connect to the virtual machine using VNC everything looks okay (eth0 is up, routes are okay), but I still cannot connect to anything. All other virtual machines on the same host continue to work as if nothing has happened. The same problem occurred in -58 and -59. /var/log/messages on the guest says: NETDEV WATCHDOG: eth0: transmit timed out eth0: link up, 100Mbps, full-duplex, lpa 0x05E1 Any suggestions (permanent fixes or temporary workarounds, I'll take what you got) would be much appreciated. Thanks for all the great work :) -Arne - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel !DSPAM:4038,47c22d43155652085621377! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] The SMP RHEL 5.1 PAE guest can't boot up issue
On Sunday 24 February 2008 16:51:07 Avi Kivity wrote: Farkas Levente wrote: will be a new release in the near future? since many of us waiting for this bug to be fixed on quad and other multi core cpus. Certainly. Can you try out the attached patch? OK on my side. Once I was thinking it would somehow affect 2.6.22, for the kernel would choose one of VCPUs to deliver all the PIT interrupt alternately. But the test show it's OK. -- Thanks Yang, Sheng - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] eth0: transmit timed out
Those stats suggest you are using the 8139too nic driver. You should switch to the 8139cp driver. david Arne Kepp wrote: Thanks David, Yes, I am using rtl8139 and it is running 2.6.18-53.1.13.el5 (Red Hat kernel, CentOS). ethtool -S eth0 on the guest says, when locked up: NIC statistics: early_rx: 0 tx_buf_mapped: 0 tx_timeouts: 4 rx_lost_in_ring: 0 It appears that 'noapic' did the trick, which is great, thanks! I am somewhat worried I'll be missing out on some SMP performance? But that's secondary. Please let me know if there is anything I can do to gather any more info to help debug the problem. -Arne david ahern wrote: I presume you are using the default rtl8139 nic. Correct? What does 'ethtool -S eth0' show when the network locks up? Many months ago adding 'noapic' to the (guest) kernel boot parameters helped, but that option is not currently helping with my RHEL4 networking issues. A thread for this issue is at: http://sourceforge.net/tracker/index.php?func=detailaid=1802082group_id=180599atid=893831 david Arne Kepp wrote: Hi, I am running KVM 61 on CentOS 5.1 x86_64 (on a Dell PowerEdge 2950 III). I start my virtual machine as follows: qemu-kvm -hda /dev/kvm_sdb/geust_root -m 1024 -net tap -net nic,vlan=0,macaddr=00:16:3e:00:00:02 -daemonize -nographic -smp 2 The problem is that when the guest (also CentOS 5.1 x86_64) utilizes the network heavily (scp to a machine on the same switch, around 12 mbyte/s) the network on the virtual machine just drops out. I can no longer ping the virtual machine, and any existing SSH sessions die. If I connect to the virtual machine using VNC everything looks okay (eth0 is up, routes are okay), but I still cannot connect to anything. All other virtual machines on the same host continue to work as if nothing has happened. The same problem occurred in -58 and -59. /var/log/messages on the guest says: NETDEV WATCHDOG: eth0: transmit timed out eth0: link up, 100Mbps, full-duplex, lpa 0x05E1 Any suggestions (permanent fixes or temporary workarounds, I'll take what you got) would be much appreciated. Thanks for all the great work :) -Arne - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel !DSPAM:4038,47c22d43155652085621377! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Probieren Sie es - Mann lebt nur einmal
Online Apotheke - original Qualitaet - 100% wirksam Spezialangebot: Vi. 10 Tab. 100 mg + Ci. 10 Tab. x 20 mg 53,82 Euro Vi. 10 Tab. 26,20 Euro Vi. 30 Tab. 51,97 Euro - Sie sparen: 27,00 Euro Vi. 60 Tab. 95,69 Euro - Sie sparen: 62,00 Euro Vi. 90 Tab. 136,91 Euro - Sie sparen: 100,00 Euro Ci. 10 - 30,00 Euro Ci. 20 - 59,35 Euro - Sie sparen: 2,00 Euro Ci. 30 - 80,30 Euro - Sie sparen: 12,00 Euro - Kein langes Warten - Auslieferung innerhalb von 2-3 Tagen - Bequem und diskret online bestellen. - Visa verifizierter Onlineshop - Kein peinlicher Arztbesuch erforderlich - keine versteckte Kosten - Diskrete Verpackung und Zahlung - Kostenlose, arztliche Telefon-Beratung Bestellen Sie jetzt und vergessen Sie Ihre Enttauschungen, anhaltende Versagensaengste und wiederholte peinliche Situationen Vier Dosen gibt's bei jeder Bestellung umsonst http://officelow.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies
The top level directory of kvm-userspace is starting to get a little crowded as we start to bring in more external dependencies. Perhaps we can create a folder tools and move directories: bios extboot vgabios The reason I mention this is soon I will be sending a patch to the list soon that will add libfdt (which is a library to read device trees for ppc) as a dependency for qemu .. and it's another directory at the top level, there will most likely be more libs and tools added in the future. Not sure if tools is the best name .. maybe external_libs .. not sure .. but just a place to put external dependencies for qemu whould be a good thing. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
