[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 with
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.
https:/
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 6
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 notifi
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 n
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 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 fil
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.
Vinc
On Thu, Dec 15, 2011 at 4:09 PM, Stefan Hajnoczi 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 differences wi
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
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 2
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 s
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.1
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
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, Vincen
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
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
*.d
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...
>> Th
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
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 wr
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
> th
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 TC
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 ipe
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 nic,macaddr=a0:00:00:
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
** 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 runnin
27 matches
Mail list logo
