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 gu
c 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 wro
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
gt; 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'
Avi Kivity wrote:
> david ahern wrote:
>> I've run a lot more tests:
>>
>>
>> - 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
david ahern wrote:
> Avi Kivity wrote:
>> - the in-kernel ioapic is buggy and needs the extra kicking the
>> optimization prevents. Can be checked by re-adding the optimization to
>> kvm_ioapic_set_irq() (keeping it removed in qemu). If it works, the
>> problem is
Almost 7 hours and the uniprocessor case is still chugging along.
david
Avi Kivity wrote:
> david ahern wrote:
>> david ahern wrote:
>>
>>> Avi Kivity wrote:
>>>
>>>> - the in-kernel ioapic is buggy and needs the extra kicking the
>>>
.
Are you using a RHEL4 image?
david
Avi Kivity wrote:
> david ahern wrote:
>> Almost 7 hours and the uniprocessor case is still chugging along.
>>
>>
>
> How long does it usually take to hang?
>
> How do I go about reproducing this? apachebench (host) aga
accommodating changes to the
netdevice/napi api. I'll take a closer look at it today.
david
Avi Kivity wrote:
> Avi Kivity wrote:
>> david ahern wrote:
>>> Almost 7 hours and the uniprocessor case is still chugging along.
>>>
>>>
>>
>> How
If you want to go with the public bridge option usermode linux tools has tunctl.
e.g., http://www.user-mode-linux.org/cvs/tools/tunctl/
david
Dor Laor wrote:
> On Wed, 2008-02-27 at 18:08 +0800, Zhao Forrest wrote:
>> Hi experts,
>>
>> I tried to setup VM network by following the instructions at
I'm the 'dsahern' in the bug report (that's my sourceforge login). Per the
thread below yes it is due to networking and as recently as 3 days ago it made a
bit of difference for Arne Kepp with his Centos 5 VM.
david
Avi Kivity wrote:
> Marcelo Tosatti wrote:
>> On Wed, Feb 27, 2008 at 11:12:03AM
interrupts are delivered via CPU 0. I ran a few tests earlier this week without
the noapic option (hence with the apic) but with irq balancing disabled and
still had the lockups. It seems to be something specific to the apic.
david
Eckersid SIlapaswang wrote:
> david ahern cisco.com>
I did not have any better luck with the e1000 or pcnet nics when running kvm-61.
I'll try again with kvm-63 and get back to you.
david
Avi Kivity wrote:
> david ahern wrote:
>> Try adding the noapic option to your guest kernel. I re-ran that test
>> on kvm-62
>> and m
Does anyone know of tools that can dump memory for a qemu guest with addresses
as seen by the guest and generate a core file? For instance, say you know the
guest is running a 32-bit linux kernel with a 1G/3G split. Then you would want
to dump 1G of memory starting 0xc000 and create an ELF core
g up host cpu time.
david
Avi Kivity wrote:
> david ahern wrote:
>> Does anyone know of tools that can dump memory for a qemu guest with
>> addresses
>> as seen by the guest and generate a core file? For instance, say you
>> know the
>> guest is running a 32-bit
Are you interested in collecting ports of the drivers for various distributions?
I have the virtio drivers working with RHEL4. The virtio_net appears to be
working better than e1000 for the workload I am testing with (though I still the
need the noapic boot option). The virtio_blk driver mostly w
That's what I was looking for.
thanks,
david
Uri Lublin wrote:
> Avi Kivity wrote:
>> david ahern wrote:
>>
>>> Attaching gdb to qemu you work with addresses as seen by the qemu
>>> process; the
>>> idea is to work with addresses as seen inside t
Avi Kivity wrote:
> It might be difficult for RHEL 4, which is 2.6.5 based IIRC. If the
> magic required is more that 500 millithaums, then an independent driver
> would be better.
RHEL4 is based on 2.6.9.
What do you mean by "magic required is more that 500 millithaums"?
david
-
I cringed a bit when you suggested the awk script route. It's quite likely that
drivers for older distributions have to be manually updated as needed. I'll post
my RHEL4 version in the next couple of days for comments.
thanks,
david
Anthony Liguori wrote:
> david ahern wrote:
Backport of the virtio drivers to RHEL4.
The patch applies against the kvm-guest-drivers-linux-1 release but also
contains diffs for Anthony's spin_lock_irqsave/restore patch. Of note is
that to build for RHEL4 Makefile is renamed to Makefile-2.6 so that Makefile
can contain the build rules for th
I am trying to understand spikes in system time that I am seeing in a VM. The
guest OS is RHEL4, with 2 vpcus, and 2.5Gb RAM; host is running 2.6.24.2 kernel.
kvm version is kvm-63.
Using the stat scripts Christian Ehrhardt posted a few days ago (thanks,
Christian, very handy tool) I collected kvm
I am trying, unsuccessfully so far, to get a vm running with 4 cpus. It is
failing with a soft lockup:
BUG: soft lockup detected on CPU#3!
[] softlockup_tick+0x98/0xa6
[] update_process_times+0x39/0x5c
[] smp_apic_timer_interrupt+0x5c/0x64
[] apic_timer_interrupt+0x1f/0x24
[] kvm_flush_remot
I saw that in the latest git tree, but RHEL5 kernel does not have that
function. I guess I'll have to evaluate my options -- upgrading kernels, or
backporting code.
thanks,
david
Laurent Vivier wrote:
> david ahern a écrit :
>> I am trying, unsuccessfully so far, to get a vm
ote_tlbs+0xe0/0xf2 [kvm]
...
I'd like to get a solution for RHEL5, so I am attempting to backport
smp_call_function_mask(). I'm open to other suggestions if you think it is
corruption or the problem is somewhere else.
thanks,
david
Avi Kivity wrote:
> david ahern wrote:
>> I
I'll give your suggestions I try. I need to move to a server that I can
forcibly reboot remotely (to recover), so it will be a while.
david
Avi Kivity wrote:
> david ahern wrote:
>> As a quick test I added a printk to the loop, right after the while():
>>
>> whi
The issue appears to be with the RHEL5 kernel (host OS is rhel5). I tried your
suggestions below -- no effect; still hit the softlockup.
I then moved the host to the 2.6.23.1 kernel but with the kvm-48 code base.
Surprisingly, I had no issues starting my guest with '-smp 4'.
david
Avi Kivity
It appears to be a problem with the kernel proper (ie., not a Red Hat patch). I
hit the soft lockup problem with kvm-48 and the 2.6.18.4 kernel which is the
base for RHEL5. That suggests a delivery between 2.6.18.4 (November 2006) and
2.6.23.1 fixed it.
david
Avi Kivity wrote:
> david ah
I found that I had to move to a newer kernel (2.6.23.1 is what I used) to get
SMP guests to boot on RHEL5 hosts. It appears to be an issue with the host
kernel.
david
Farkas Levente wrote:
> Avi Kivity wrote:
>> If you're having trouble on AMD systems, please try this out.
>
> this version w
I now have hosts running both 32-bit and 64-bit versions of RHEL5.1. I will
retry SMP guests on the RHEL5 kernel, but at present kvm-51 does not compile:
make -C kernel
make[1]: Entering directory `/opt/kvm/kvm-51/kernel'
make -C /lib/modules/2.6.18-53.el5/build M=`pwd` "$@"
make[2]: Entering dir
se. For my purposes, I just moved up the
endif around what was defined.
With that change, kvm-51 compiles. I am still seeing 32-bit SMP guests hang on
boot for both 32-bit and 64-bit hosts (again running RHEL5.1).
david
david ahern wrote:
> I now have hosts running both 32-bit and 64-bit versio
The patch worked for me -- rhel4 smp guests boot fine on stock RHEL5 hosts,
both 32-bit and 64-bit.
david
Avi Kivity wrote:
> david ahern wrote:
>> In RHEL 5.1 defines:
>>
>> #define CPU_TASKS_FROZEN0x0010
>>
>> #define CPU_ONLINE_FROZEN (CPU_ONLI
Can you post the full qemu command that gets launched in each case?
david
Farkas Levente wrote:
> Izik Eidus wrote:
>> On Mon, 2007-11-12 at 17:07 +0100, Farkas Levente wrote:
>>> Izik Eidus wrote:
On Mon, 2007-11-12 at 16:29 +0100, Farkas Levente wrote:
> Avi Kivity wrote:
>> Small
course to make sure
there are not conflicts -- and running qemu directly rather than through
virtmanager.
david
Farkas Levente wrote:
> david ahern wrote:
>> Can you post the full qemu command that gets launched in each case?
>
> this is the current running one, the only dif
/0x277 [kvm]
[] kvm_vm_ioctl+0x264/0x277 [kvm]
[] default_wake_function+0x0/0xc
[] kvm_vcpu_ioctl+0x0/0x366 [kvm]
[] do_ioctl+0x1c/0x5d
[] vfs_ioctl+0x24a/0x25c
[] sys_ioctl+0x48/0x5f
[] syscall_call+0x7/0xb
===
david
Avi Kivity wrote:
> david ahern wrote:
>
contains traces for each thread at 3 sample times in case it
helps get some insight.
david
david ahern wrote:
> With kvm-52 my 32-bit host running RHEL5.1 can start an RHEL 5 SMP guest only
> once. Second and subsequent attempts hang. Removing kvm and kvm_intel modules
> have no affect;
Farkas Levente wrote:
> anyway how should i've test noapic? qemu command line -noapic or guest
> kernel param noapic or both?
>
Add 'noapic' to guest kernel boot options. I've been adding it for a while to
workaround a networking issue (see kvm-Bugs-1802082).
david
---
which I am
running performance tests.)
I would like to know why I need the noapic option to get around this and the
networking problem. Are there performance hits as a side effect?
david
Avi Kivity wrote:
> david ahern wrote:
>> With kvm-52 my 32-bit host running RHEL5.1 can start an R
9:28:05 bldr-ccm89 kernel: [] sys_futex+0x109/0x11f
Nov 13 09:28:05 bldr-ccm89 kernel: [] syscall_call+0x7/0xb
Nov 13 09:28:05 bldr-ccm89 kernel: ===
david
Avi Kivity wrote:
> david ahern wrote:
>> I let the host stay up for 90 minutes before loading kvm and startin
though
it hung at a different spot.
If it matters, host for this test is an HP DL380 G5.
david
Avi Kivity wrote:
> david ahern wrote:
>> First boot has been working fine since your patch this past weekend.
>> It's been subsequent boots that hang.
>>
>> I added -n
39 matches
Mail list logo
