On Fri, Oct 18, 2019 at 09:13:24AM +0200, Thomas Huth wrote: > On 18/10/2019 00.55, Eduardo Habkost wrote: > > On Thu, Oct 17, 2019 at 07:05:41PM -0300, Eduardo Habkost wrote: > >> On Wed, Oct 16, 2019 at 07:41:24PM -0300, Eduardo Habkost wrote: > >>> On Wed, Oct 16, 2019 at 08:11:57AM +0200, Thomas Huth wrote: > >>>> On 16/10/2019 05.00, Eduardo Habkost wrote: > >>>>> On Tue, Sep 17, 2019 at 08:31:40PM -0300, Eduardo Habkost wrote: > >>>>>> On Mon, Jul 01, 2019 at 07:25:27PM -0300, Eduardo Habkost wrote: > >>>>>>> On Mon, Jun 10, 2019 at 01:58:50PM +0100, Peter Maydell wrote: > >>>>> [...] > >>>>>>>> The configure check also spits out deprecation warnings for > >>>>>>>> the NetBSD/FreeBSD/OpenBSD tests/vm configurations. It would be nice > >>>>>>>> to get those updated. > >>>>>>> > >>>>>>> CCing the test/vm maintainers. > >>>>>>> > >>>>>>> Fam, Alex, are you able to fix this and create new BSD VM images > >>>>>>> with Python 3 available? I thought the VM image configurations > >>>>>>> were stored in the source tree, but they are downloaded from > >>>>>>> download.patchew.org. > >>>>>> > >>>>>> Fam, Alex, can you help us on this? Python 2 won't be supported > >>>>>> anymore, so we need the VM images to be updated. > >>>>> > >>>>> Anyone? > >>>>> > >>>>> I'm about to submit patches to remove Python 2 support, and this > >>>>> will break tests/vm/netbsd. > >>>>> > >>>>> I'm powerless to fix this issue, because the netbsd image is > >>>>> hosted at download.patchew.org. > >>>> > >>>> Gerd had a patch to convert the netbsd VM script to ad hoc image > >>>> creation, too: > >>>> > >>>> https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg04459.html > >>>> > >>>> But there was a regression with the serial port between QEMU v3.0 and > >>>> v4.x, so it was not included: > >>>> > >>>> https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg06784.html > >>> > >>> The URL above has this error: > >>> > >>> con recv: x: Exitqqqqqqqqqqqqqqqqqqqqqqqqqj > >>> con recv: To be able to use the network, we need answers to the > >>> following:Network media type > >>> con send: <enter> > >>> con recv: : qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk Perform autoconfiguration? > >>> >a: Yes b: Noqqqqqqqqqqqqqqqqq > >>> console: *** read timeout *** > >>> console: waiting for: 'a: Yes' > >>> console: line buffer: > >>> > >>> con recv: qqqqqqqqqqqqqqj > >>> > >>> I believe that problem was solved in v4, because v4 was reading > >>> the serial output 1 byte at a time. > >>> > >>> The issue that caused the netbsd patch to be dropped was: > >>> https://lore.kernel.org/qemu-devel/cafeaca8k9qja9ie-kwiaphr0fy_2zg7jrx5uv4aassjxcss...@mail.gmail.com/ > >>> > >>> Possibly this is the same issue we saw at: > >>> https://lore.kernel.org/qemu-devel/20190607034214.gb22...@habkost.net/ > >>> > >>> The test script must either close the console socket, or keep > >>> reading from it. Otherwise, the QEMU VCPU threads might get > >>> stuck waiting for the chardev to be writeable. > >> > >> It doesn't seem to be the same issue. Even if the console socket is > >> closed, > >> I'm seeing results similar to the ones reported by Peter (the "pkgin -y > >> install" step is unreasonably slow). > >> > >> Running with V=1, I see packages being downloaded at reasonable speeds, but > >> there's a huge interval (of various minutes) between each package download. > > > > I've found the cause for the slowness I'm seeing: for each file > > being downloaded, the guest spents at least 75 seconds trying to > > connect to the IPv6 address of ftp.NetBSD.org, before trying > > IPv4. I don't know if this is a NetBSD bug, or a slirp bug. > > Does it work better if you turn IPv6 off? E.g.: > > diff --git a/tests/vm/basevm.py b/tests/vm/basevm.py > --- a/tests/vm/basevm.py > +++ b/tests/vm/basevm.py > @@ -81,7 +81,7 @@ class BaseVM(object): > self._args = [ \ > "-nodefaults", "-m", "4G", > "-cpu", "max", > - "-netdev", "user,id=vnet,hostfwd=:127.0.0.1:0-:22", > + "-netdev", "user,id=vnet,hostfwd=:127.0.0.1:0-:22,ipv6=off", > "-device", "virtio-net-pci,netdev=vnet", > "-vnc", "127.0.0.1:0,to=20"] > if vcpus and vcpus > 1:
Yes, it is much better. Thanks! I will send a series disabling ipv6 in tests/vm/netbsd as a workaround. -- Eduardo