On Sun, Dec 24, 2017 at 11:24 AM, Andreas Hartmann
wrote:
> 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
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.13 on a host running v4.15-rc1.
>>>
On Thu, Dec 21, 2017 at 12:05 PM, Andreas Hartmann
wrote:
> 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:
>>
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 gue
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 guests running v4.13 on a host running v4.15
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 refcount indeed hits overflow (
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't be killed any more.
> Because of the stac
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't be killed any more.
Because of the stack trace
[] vhost_net_ubuf_put_and_wait+0x35/0x60
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 Thu, Dec 14, 2017 at 5: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_ne
>> 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]
>> [] do_vfs_ioctl+0x8f/0x5c0
>> [] SyS_ioctl+0x74/0x80
>> []
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 Fri, Dec 08, 2017 at
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, Andreas Hartmann wrote:
> On 12/08
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 Michal Kubecek wrote:
> On Fri, De
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 +0100, Andreas Hartmann 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 +0100, Andreas Hartmann wrote:
>> >>
>> >> All my VMs are using virtio_net. BTW: I co
On 2017年12月08日 21:13, Andreas Hartmann wrote:
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 will there b
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 will there be a fix for 4.14? It is clearly a r
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 will there be a fix for 4.14? It is clearly a regression. Is
> >> it possible / a good idea to jus
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 VMs are using virtio_net. BTW: I couldn't see
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 VMs are using virtio_net. BTW: I couldn't see the problems
> >> (sometimes, the VM couldn't be s
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
>>
>>
>>
>> [v2,RFC,11/13] net: Remove all referen
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
>
>
>
> [v2,RFC,11/13] net: Remove all references to SKB_GSO_UDP. [1]
>
>
>
> For the repeated b
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 wrote:
> On 12/01/2017 at 11:11 AM Andreas Hartm
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 wrote:
On 12/01/2017 at 11:11 AM Andreas Hartmann wrote:
Hello!
I hopefully could get rid of both of my proble
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 hopefully could get rid of both of my problems (hanging network w/
>>>
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 hopefully could get rid of both of my problems (hanging network w/
virtio) and endless hanging qemu-process on VM shutdown by upgrading
q
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
>> qemu from 2.6.2 to 2.10.1. I hope it
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 persist. 10h later - same probl
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
>> -9 doesn't work). It's abso
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
> -9 doesn't work). It's absolutely necessary to *force* a reboot to exit
> or res
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:
>
> VM1 -> tun/tap -> br1
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
34 matches
Mail list logo
