[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/899140
Title:
Problem
Can you still reproduce this issue with the latest version of QEMU
(currently v2.8), or could we close this ticket nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Hi,
No I don't try, i will :)
The probleme is not present with another NIC so I use another one for
the moment.
Vincent
Le 09/02/2012 20:05, Henrique Rodrigues a écrit :
Vincent,
Have you tried to change the mtu of the tbf qdisc? The traffic control should
work well if you set it to
Vincent,
Have you tried to change the mtu of the tbf qdisc? The traffic control should
work well if you set it to 65kb.
I believe that this is happening due to the napi gro functionality. I'm still
not sure, but the problem seems to be related to that.
Henrique
--
You received this bug
Hi,
The problem seems to come from the implementation of the Intel e1000
network cards (which is the default one used by QEMU).
If you use another one, the problem does not appear ;)
Vince
Le 29/01/2012 05:49, Henrique Rodrigues a écrit :
Hi guys,
I'm having the same problem with a ubuntu
Hi,
I figured out what was the problem. It seems that the pkts generated by
each guest iperf command is bigger than the default qdisc mtu of 2kb
(the pkts have length of 65k). If you set a higher qdisc mtu (=65k) the
traffic should be controlled as expected.
Henrique
--
You received this bug
Hi guys,
I'm having the same problem with a ubuntu 11.04 (natty) host. I tried to
set the rate controllers using tc both at the host and inside the guest
i.e.:
tc qdisc add vnic0 root tbf rate 20mbit burst 20480 latency 50ms (host - to
control the traffic going to the guest vm) and
tc qdisc add
On Thu, Dec 15, 2011 at 04:48:13PM -, Vincent Autefage wrote:
Here is the problem !
The Ubuntu version works only because it not uses an *Intel e1000* but a
*rtl8139*.
Therefore, the problem about the e1000 is present in *all* version
(original or ubuntu ones).
Thus, the file
On Wed, Dec 14, 2011 at 02:42:12PM -, Vincent Autefage wrote:
Ok so the *Intel e1000* seems the only card which is impacted by the
bug.
Let me recap with a summary of your debugging:
QEMU 0.14.0, 0.15.0, and 1.0 built from source all have poor network
performance below a 20 Mbit/s limit
Ok,
So the e1000.c and the e1000_hw.h have absolutely no difference between
the original and the ubuntu version...
The only differences witch refers to the *Intel e1000* in the wall
sources is this one :
diff -ru qemu//hw/pc_piix.c qemu-kvm-0.14.0+noroms//hw/pc_piix.c
--- qemu//hw/pc_piix.c
On Thu, Dec 15, 2011 at 3:03 PM, Vincent Autefage
899...@bugs.launchpad.net wrote:
Ok,
So the e1000.c and the e1000_hw.h have absolutely no difference between
the original and the ubuntu version...
The only differences witch refers to the *Intel e1000* in the wall
sources is this one :
On Thu, Dec 15, 2011 at 4:09 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Thu, Dec 15, 2011 at 3:03 PM, Vincent Autefage
899...@bugs.launchpad.net wrote:
Ok,
So the e1000.c and the e1000_hw.h have absolutely no difference between
the original and the ubuntu version...
The only
Here is the problem !
The Ubuntu version works only because it not uses an *Intel e1000* but a
*rtl8139*.
Therefore, the problem about the e1000 is present in *all* version
(original or ubuntu ones).
Thus, the file *e1000.c* must contain some instructions which imply the
bad TC behavior.
Well,
I have checked differences between the GIT repository (V0.14.0) and the
Ubuntu version (V0.14.0) and generated patch diff file.
The patch contains about 5000 lines...
What's the next step ?
Vincent
Le 05/12/2011 12:11, Stefan Hajnoczi a écrit :
On Mon, Dec 5, 2011 at 10:45 AM, Vincent
I've just checked the problem with a *ne2k_pci* instead of the default
e1000 and the problem does not exist with the *ne2k_pci*... (Version
0.14-1 of qemu)
I'm going to check other cards right now
Vincent
Le 05/12/2011 12:11, Stefan Hajnoczi a écrit :
On Mon, Dec 5, 2011 at 10:45 AM,
On Wed, Dec 14, 2011 at 1:36 PM, Vincent Autefage
899...@bugs.launchpad.net wrote:
I have checked differences between the GIT repository (V0.14.0) and the
Ubuntu version (V0.14.0) and generated patch diff file.
The patch contains about 5000 lines...
What's the next step ?
Okay, so when you
Ok so the *Intel e1000* seems the only card which is impacted by the
bug.
Vincent
Le 05/12/2011 12:11, Stefan Hajnoczi a écrit :
On Mon, Dec 5, 2011 at 10:45 AM, Vincent Autefage
899...@bugs.launchpad.net wrote:
So we have another problem...
The thing is that the 0.14.0 (and all 0.14.0 rc)
Well
I've compiled the ubuntu package.
When I've launched qemu, I've got this :
*
*$ *qemu-system-x86_64 -hda debian.img -m 512
qemu: could not load PC BIOS 'bios.bin'
**
*I've checked the content of the *pc-bios* directory and no bios are
generated but I've got strange file like :
**.bin
On Sun, Dec 04, 2011 at 03:54:12PM -, Vincent Autefage wrote:
The result without TC is about 120 Mbit/s.
I check the bandwidth with lot of programs (not only with Iperf) and the
result is also the same
However, if I use the same raw image and the same TC configuration with
the
Hi,
So we have another problem...
The thing is that the 0.14.0 (and all 0.14.0 rc) built from GIT has the
same problem.
However, the package 0.14.0 from Ubuntu does not has this bug...
Le 05/12/2011 09:26, Stefan Hajnoczi a écrit :
On Sun, Dec 04, 2011 at 03:54:12PM -, Vincent Autefage
On Mon, Dec 5, 2011 at 10:45 AM, Vincent Autefage
899...@bugs.launchpad.net wrote:
So we have another problem...
The thing is that the 0.14.0 (and all 0.14.0 rc) built from GIT has the
same problem.
However, the package 0.14.0 from Ubuntu does not has this bug...
Okay, that's actually a good
Yes this is the package that seems to not include the bug.
I'm going to check sources of this package.
Vincent Autefage
Le 05/12/2011 12:11, Stefan Hajnoczi a écrit :
On Mon, Dec 5, 2011 at 10:45 AM, Vincent Autefage
899...@bugs.launchpad.net wrote:
So we have another problem...
The thing
The result without TC is about 120 Mbit/s.
I check the bandwidth with lot of programs (not only with Iperf) and the
result is also the same
However, if I use the same raw image and the same TC configuration with
the version 0.14.0 of QEMU or with some real physical hosts, the result
with
On Fri, Dec 2, 2011 at 2:42 PM, Vincent Autefage
899...@bugs.launchpad.net wrote:
*root@A# tc qdisc add dev eth0 root tbf rate 20mbit burst 20480 latency
50ms*
*root@B# **ifconfig eth0 192.168.0.2*
Then if we check with /Iperf/, the real rate will be about 100kbit/s :
What is the iperf
** Description changed:
Hi,
- The two last main versions of QEMU (0.15 and 1.0) have an important problem
when running on a Linux distribution which running itself a Traffic Control
(TC) instance.
+ The last main versions of QEMU (0.14.1, 0.15 and 1.0) have an important
problem when
Hi Vincent,
Please give steps to reproduce the problem including the QEMU
command-lines you used and what commands need to be run inside the
guest and on the host.
Stefan
Hi,
So, the host command lines are :
*$ qemu -name A -sdl -m 512 -enable-kvm -localtime -k fr -hda
debian1.img -net nic,macaddr=a0:00:00:00:00:01 -net
socket,mcast=230.0.0.1:7000*
The second is
*$ qemu -name B -sdl -m 512 -enable-kvm -localtime -k fr -hda
debian2.img -net
27 matches
Mail list logo
