On Fri, Aug 02, 2013 at 09:41:24PM +0200, Jan Kiszka wrote:
> On 2013-08-02 14:45, Jan Kiszka wrote:
> > On 2013-08-02 13:46, Stefan Hajnoczi wrote:
> >> On Thu, Aug 01, 2013 at 07:15:54PM +0200, Jan Kiszka wrote:
> >>> I was digging into the involved code and found something fishy:
> >>>
> >>> net
On 2013-08-02 14:45, Jan Kiszka wrote:
> On 2013-08-02 13:46, Stefan Hajnoczi wrote:
>> On Thu, Aug 01, 2013 at 07:15:54PM +0200, Jan Kiszka wrote:
>>> I was digging into the involved code and found something fishy:
>>>
>>> net/tap.c:
>>> static void tap_send(void *opaque)
>>> {
>>> ...
>>>
On 2013-08-02 14:45, Jan Kiszka wrote:
> On 2013-08-02 13:46, Stefan Hajnoczi wrote:
>> On Thu, Aug 01, 2013 at 07:15:54PM +0200, Jan Kiszka wrote:
>>> I was digging into the involved code and found something fishy:
>>>
>>> net/tap.c:
>>> static void tap_send(void *opaque)
>>> {
>>> ...
>>>
On 2013-08-02 13:46, Stefan Hajnoczi wrote:
> On Thu, Aug 01, 2013 at 07:15:54PM +0200, Jan Kiszka wrote:
>> I was digging into the involved code and found something fishy:
>>
>> net/tap.c:
>> static void tap_send(void *opaque)
>> {
>> ...
>> size = qemu_send_packet_async(&s->nc, buf, s
On Thu, Aug 01, 2013 at 07:15:54PM +0200, Jan Kiszka wrote:
> I was digging into the involved code and found something fishy:
>
> net/tap.c:
> static void tap_send(void *opaque)
> {
> ...
> size = qemu_send_packet_async(&s->nc, buf, size,
> tap_sen
On 2013-08-02 09:33, Stefan Hajnoczi wrote:
> On Thu, Aug 01, 2013 at 07:24:13PM +0200, Jan Kiszka wrote:
>> On 2013-08-01 19:15, Jan Kiszka wrote:
>>> Hi all,
>>>
>>> I'm tracking down a nasty stall of tap input over a custom 1.3.x QEMU
>>> version. Under certain load, our tap backend stops readin
On Thu, Aug 01, 2013 at 07:24:13PM +0200, Jan Kiszka wrote:
> On 2013-08-01 19:15, Jan Kiszka wrote:
> > Hi all,
> >
> > I'm tracking down a nasty stall of tap input over a custom 1.3.x QEMU
> > version. Under certain load, our tap backend stops reading from the char
> > device, and that even if w
On 2013-08-01 19:15, Jan Kiszka wrote:
> Hi all,
>
> I'm tracking down a nasty stall of tap input over a custom 1.3.x QEMU
> version. Under certain load, our tap backend stops reading from the char
> device, and that even if we reset the guest. The frontend device
> (pcnet32) is able to receive (c
Hi all,
I'm tracking down a nasty stall of tap input over a custom 1.3.x QEMU
version. Under certain load, our tap backend stops reading from the char
device, and that even if we reset the guest. The frontend device
(pcnet32) is able to receive (can_receive would return > 0), but the
tap's fd is n
