On 01/24/2018 at 06:31 AM Andreas Hartmann wrote:
> On 01/23/2018 at 04:47 PM Oliver Freyermuth wrote:
>> Am 23.01.2018 um 16:28 schrieb David Miller:
>>> Looking at how these DMA counters are handled, there appears to be a
>>> requirement that the memor
On 01/23/2018 at 04:47 PM Oliver Freyermuth wrote:
> Am 23.01.2018 um 16:28 schrieb David Miller:
>> Looking at how these DMA counters are handled, there appears to be a
>> requirement that the memory buffer is 64-byte aligned.
>>
>> [...]
>>
>> Therefore the driver needs to allocate "size + (64 -
On 12/20/2017 at 04:56 PM Andreas Hartmann wrote:
> On 12/18/2017 at 06:11 PM Andreas Hartmann wrote:
>> On 12/17/2017 at 11:33 PM Willem de Bruijn wrote:
> [...]
>>> I have been able to reproduce the hang by sending a UFO packet
>>> between two guests running v4.
On 12/20/2017 at 11:44 PM Willem de Bruijn wrote:
On Wed, Dec 20, 2017 at 10:56 AM, Andreas Hartmann
wrote:
On 12/18/2017 at 06:11 PM Andreas Hartmann wrote:
On 12/17/2017 at 11:33 PM Willem de Bruijn wrote:
[...]
I have been able to reproduce the hang by sending a UFO packet
between two
On 12/18/2017 at 06:11 PM Andreas Hartmann wrote:
> On 12/17/2017 at 11:33 PM Willem de Bruijn wrote:
[...]
>> I have been able to reproduce the hang by sending a UFO packet
>> between two guests running v4.13 on a host running v4.15-rc1.
>>
>> The vhost_net_ubuf_ref re
On 12/17/2017 at 11:33 PM Willem de Bruijn wrote:
> On Fri, Dec 15, 2017 at 1:05 AM, Andreas Hartmann
> wrote:
>> On 12/14/2017 at 11:17 PM Willem de Bruijn wrote:
>>>>> Well, the patch does not fix hanging VMs, which have been shutdown and
>>>>> can&
On 12/14/2017 at 11:17 PM Willem de Bruijn wrote:
>>> Well, the patch does not fix hanging VMs, which have been shutdown and
>>> can't be killed any more.
>>> Because of the stack trace
>>>
>>> [] vhost_net_ubuf_put_and_wait+0x35/0x60 [vhost_net]
>>> [] vhost_net_ioctl+0x304/0x870 [vhost_net]
>>> [
On 12/11/2017 at 04:54 PM Andreas Hartmann wrote:
> On 12/08/2017 at 09:44 PM Andreas Hartmann wrote:
>> On 12/08/2017 at 09:11 PM Andreas Hartmann wrote:
>>> On 12/08/2017 at 05:04 PM Willem de Bruijn wrote:
>>>> On Fri, Dec 8, 2017 at 6:40 AM, Michal Kubecek wrote:
On 12/08/2017 at 09:44 PM Andreas Hartmann wrote:
> On 12/08/2017 at 09:11 PM Andreas Hartmann wrote:
>> On 12/08/2017 at 05:04 PM Willem de Bruijn wrote:
>>> On Fri, Dec 8, 2017 at 6:40 AM, Michal Kubecek wrote:
>>>> On Fri, Dec 08, 2017 at 11:31:50AM +0100, Andre
On 12/08/2017 at 09:11 PM Andreas Hartmann wrote:
> On 12/08/2017 at 05:04 PM Willem de Bruijn wrote:
>> On Fri, Dec 8, 2017 at 6:40 AM, Michal Kubecek wrote:
>>> On Fri, Dec 08, 2017 at 11:31:50AM +0100, Andreas Hartmann wrote:
>>>> On 12/08/2017 at 09:47 AM Mich
On 12/08/2017 at 05:04 PM Willem de Bruijn wrote:
> On Fri, Dec 8, 2017 at 6:40 AM, Michal Kubecek wrote:
>> On Fri, Dec 08, 2017 at 11:31:50AM +0100, Andreas Hartmann wrote:
>>> On 12/08/2017 at 09:47 AM Michal Kubecek wrote:
>>>> On Fri, Dec 08, 2017 at 08:21:16AM
On 12/08/2017 at 01:58 PM Michal Kubecek wrote:
> On Fri, Dec 08, 2017 at 01:45:38PM +0100, Andreas Hartmann wrote:
>> On 12/08/2017 at 12:40 PM Michal Kubecek wrote:
>>> On Fri, Dec 08, 2017 at 11:31:50AM +0100, Andreas Hartmann wrote:
>>>>
>>>> When wil
On 12/08/2017 at 12:40 PM Michal Kubecek wrote:
> On Fri, Dec 08, 2017 at 11:31:50AM +0100, Andreas Hartmann wrote:
>> On 12/08/2017 at 09:47 AM Michal Kubecek wrote:
>>> On Fri, Dec 08, 2017 at 08:21:16AM +0100, Andreas Hartmann wrote:
>>>>
>>>> All my
On 12/08/2017 at 09:47 AM Michal Kubecek wrote:
> On Fri, Dec 08, 2017 at 08:21:16AM +0100, Andreas Hartmann wrote:
>>
>> Thanks for this hint - I'm not using xdp. Therefore I rechecked my
>> bisect and detected a mistake. The rebisect now leads to
>>
>>
On 12/06/2017 at 04:08 AM Jason Wang wrote:
>
>
> On 2017年12月06日 00:23, Andreas Hartmann wrote:
>> On 12/05/2017 at 04:50 AM Jason Wang wrote:
>>>
>>> On 2017年12月05日 00:28, Andreas Hartmann wrote:
>>>> On 12/03/2017 at 12:35 PM Andreas Hartmann w
On 12/05/2017 at 04:50 AM Jason Wang wrote:
>
>
> On 2017年12月05日 00:28, Andreas Hartmann wrote:
>> On 12/03/2017 at 12:35 PM Andreas Hartmann wrote:
>>> On 12/01/2017 at 11:11 AM Andreas Hartmann wrote:
>>>> Hello!
>>>>
>>>> I hopef
On 12/03/2017 at 12:35 PM Andreas Hartmann wrote:
> On 12/01/2017 at 11:11 AM Andreas Hartmann wrote:
>> Hello!
>>
>> I hopefully could get rid of both of my problems (hanging network w/
>> virtio) and endless hanging qemu-process on VM shutdown by upgrading
>> qem
On 12/01/2017 at 11:11 AM Andreas Hartmann wrote:
> Hello!
>
> I hopefully could get rid of both of my problems (hanging network w/
> virtio) and endless hanging qemu-process on VM shutdown by upgrading
> qemu from 2.6.2 to 2.10.1. I hope it will persist.
It didn't persi
Hello!
I hopefully could get rid of both of my problems (hanging network w/
virtio) and endless hanging qemu-process on VM shutdown by upgrading
qemu from 2.6.2 to 2.10.1. I hope it will persist.
BTW: Base system is Leap 42.2.
Sorry for the noise,
thanks,
kind regards,
Andreas
On 11/27/2017 at 05:55 PM Michal Kubecek wrote:
> On Mon, Nov 27, 2017 at 05:46:14PM +0100, Andreas Hartmann wrote:
>>
>> Using virtio not just breaks the network completely as described above,
>> it even leaves a never stoppable or restartable qemu process (even kill
>
On 11/26/2017 at 03:17 PM Andreas Hartmann wrote:
> Hello!
>
> Since Linux 4.14 (running as host), the virtual network based on bridge
> and tun/tap-devices is partly broken. Linux 4.13.x or earlier works
> perfectly.
>
>
> Given is the following architecture on host:
&g
Hello!
Since Linux 4.14 (running as host), the virtual network based on bridge
and tun/tap-devices is partly broken. Linux 4.13.x or earlier works
perfectly.
Given is the following architecture on host:
VM1 -> tun/tap -> br1
VM2 -> tun/tap -> br0 / br1
VM3 -> tun/tap -> br0
Example network con
22 matches
Mail list logo
