* Python 2 and test/vm/netbsd (was Re: [Qemu-devel] [PULL 0/8] Python queue, 2019-06-07) @ 2019-10-16 3:00 Eduardo Habkost 2019-10-16 6:11 ` Python 2 and test/vm/netbsd Thomas Huth 0 siblings, 1 reply; 19+ messages in thread From: Eduardo Habkost @ 2019-10-16 3:00 UTC (permalink / raw) To: Peter Maydell Cc: Fam Zheng, Kevin Wolf, John Snow, QEMU Developers, Alex Bennée, Cleber Rosa, Philippe Mathieu-Daudé 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. -- Eduardo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Python 2 and test/vm/netbsd 2019-10-16 3:00 Python 2 and test/vm/netbsd (was Re: [Qemu-devel] [PULL 0/8] Python queue, 2019-06-07) Eduardo Habkost @ 2019-10-16 6:11 ` Thomas Huth 2019-10-16 8:25 ` Kamil Rytarowski 2019-10-16 22:41 ` Eduardo Habkost 0 siblings, 2 replies; 19+ messages in thread From: Thomas Huth @ 2019-10-16 6:11 UTC (permalink / raw) To: Eduardo Habkost, Peter Maydell Cc: Fam Zheng, Kevin Wolf, Alex Bennée, QEMU Developers, Philippe Mathieu-Daudé, Kamil Rytarowski, Gerd Hoffmann, Cleber Rosa, Marc-André Lureau, John Snow 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 I guess someone™ needs to bisect that regression, so we can fix that bug and finally include Gerd's patch... Thomas ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Python 2 and test/vm/netbsd 2019-10-16 6:11 ` Python 2 and test/vm/netbsd Thomas Huth @ 2019-10-16 8:25 ` Kamil Rytarowski 2019-10-16 10:59 ` Alex Bennée 2019-10-16 22:41 ` Eduardo Habkost 1 sibling, 1 reply; 19+ messages in thread From: Kamil Rytarowski @ 2019-10-16 8:25 UTC (permalink / raw) To: Thomas Huth, Eduardo Habkost, Peter Maydell Cc: Fam Zheng, Kevin Wolf, Alex Bennée, QEMU Developers, Philippe Mathieu-Daudé, Kamil Rytarowski, Gerd Hoffmann, Cleber Rosa, Marc-André Lureau, John Snow On 16.10.2019 08:11, 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 > > I guess someone™ needs to bisect that regression, so we can fix that bug > and finally include Gerd's patch... > > Thomas > Is this a regression in qemu? How to reproduce the problem? "make vm-build-netbsd V=1" ? I can have a look but I need to know exact specifics of the problem. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Python 2 and test/vm/netbsd 2019-10-16 8:25 ` Kamil Rytarowski @ 2019-10-16 10:59 ` Alex Bennée 2019-10-16 11:02 ` Thomas Huth 2019-10-16 12:23 ` Philippe Mathieu-Daudé 0 siblings, 2 replies; 19+ messages in thread From: Alex Bennée @ 2019-10-16 10:59 UTC (permalink / raw) To: Kamil Rytarowski Cc: Fam Zheng, Peter Maydell, Thomas Huth, Eduardo Habkost, Philippe Mathieu-Daudé, QEMU Developers, Marc-André Lureau, Kamil Rytarowski, Gerd Hoffmann, Cleber Rosa, Kevin Wolf, John Snow Kamil Rytarowski <n54@gmx.com> writes: > On 16.10.2019 08:11, 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 >> >> I guess someone™ needs to bisect that regression, so we can fix that bug >> and finally include Gerd's patch... >> >> Thomas >> > > Is this a regression in qemu? How to reproduce the problem? "make > vm-build-netbsd V=1" ? You'll need to apply the patch from that series: tests/vm: netbsd autoinstall, using serial (all the others got merged) > I can have a look but I need to know exact specifics of the problem. Make sure you've cleared out any cached images. As was mentioned in the thread it seems to be a little host dependant - some host systems it was working and some it was not. -- Alex Bennée ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Python 2 and test/vm/netbsd 2019-10-16 10:59 ` Alex Bennée @ 2019-10-16 11:02 ` Thomas Huth 2019-10-16 12:23 ` Philippe Mathieu-Daudé 1 sibling, 0 replies; 19+ messages in thread From: Thomas Huth @ 2019-10-16 11:02 UTC (permalink / raw) To: Alex Bennée, Kamil Rytarowski Cc: Fam Zheng, Peter Maydell, Eduardo Habkost, Philippe Mathieu-Daudé, QEMU Developers, Marc-André Lureau, Kamil Rytarowski, Gerd Hoffmann, Cleber Rosa, Kevin Wolf, John Snow On 16/10/2019 12.59, Alex Bennée wrote: > > Kamil Rytarowski <n54@gmx.com> writes: > >> On 16.10.2019 08:11, 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 >>> >>> I guess someone™ needs to bisect that regression, so we can fix that bug >>> and finally include Gerd's patch... >>> >>> Thomas >>> >> >> Is this a regression in qemu? How to reproduce the problem? "make >> vm-build-netbsd V=1" ? > > You'll need to apply the patch from that series: > > tests/vm: netbsd autoinstall, using serial Patch (mbox for applying with "git am") is still available in Patchew if you don't have it in your local qemu-devel folder anymore: http://next.patchew.org/QEMU/20190520124716.30472-13-kraxel@redhat.com/mbox Thomas ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Python 2 and test/vm/netbsd 2019-10-16 10:59 ` Alex Bennée 2019-10-16 11:02 ` Thomas Huth @ 2019-10-16 12:23 ` Philippe Mathieu-Daudé 1 sibling, 0 replies; 19+ messages in thread From: Philippe Mathieu-Daudé @ 2019-10-16 12:23 UTC (permalink / raw) To: Alex Bennée, Kamil Rytarowski Cc: Fam Zheng, Peter Maydell, Thomas Huth, Eduardo Habkost, QEMU Developers, Marc-André Lureau, Kamil Rytarowski, Gerd Hoffmann, Cleber Rosa, Kevin Wolf, John Snow On 10/16/19 12:59 PM, Alex Bennée wrote: > Kamil Rytarowski <n54@gmx.com> writes: >> On 16.10.2019 08:11, 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 >>> >>> I guess someone™ needs to bisect that regression, so we can fix that bug >>> and finally include Gerd's patch... >>> >>> Thomas >>> >> >> Is this a regression in qemu? How to reproduce the problem? "make >> vm-build-netbsd V=1" ? > > You'll need to apply the patch from that series: > > tests/vm: netbsd autoinstall, using serial > > (all the others got merged) > >> I can have a look but I need to know exact specifics of the problem. IIRC this is not a NetBSD specific issue, but the NetBSD image triggers the chardev bug reliably. > Make sure you've cleared out any cached images. As was mentioned in the > thread it seems to be a little host dependant - some host systems it was > working and some it was not. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Python 2 and test/vm/netbsd 2019-10-16 6:11 ` Python 2 and test/vm/netbsd Thomas Huth 2019-10-16 8:25 ` Kamil Rytarowski @ 2019-10-16 22:41 ` Eduardo Habkost 2019-10-17 22:05 ` Eduardo Habkost 1 sibling, 1 reply; 19+ messages in thread From: Eduardo Habkost @ 2019-10-16 22:41 UTC (permalink / raw) To: Thomas Huth Cc: Fam Zheng, Peter Maydell, Alex Bennée, QEMU Developers, Philippe Mathieu-Daudé, Marc-André Lureau, Kamil Rytarowski, Gerd Hoffmann, Cleber Rosa, Kevin Wolf, John Snow 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_2zG7JRX5uV4AaSSjXCSs4+A@mail.gmail.com/ Possibly this is the same issue we saw at: https://lore.kernel.org/qemu-devel/20190607034214.GB22416@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. -- Eduardo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Python 2 and test/vm/netbsd 2019-10-16 22:41 ` Eduardo Habkost @ 2019-10-17 22:05 ` Eduardo Habkost 2019-10-17 22:55 ` Eduardo Habkost 0 siblings, 1 reply; 19+ messages in thread From: Eduardo Habkost @ 2019-10-17 22:05 UTC (permalink / raw) To: Thomas Huth Cc: Fam Zheng, Peter Maydell, Alex Bennée, QEMU Developers, Philippe Mathieu-Daudé, Marc-André Lureau, Kamil Rytarowski, Gerd Hoffmann, Cleber Rosa, Kevin Wolf, John Snow 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_2zG7JRX5uV4AaSSjXCSs4+A@mail.gmail.com/ > > Possibly this is the same issue we saw at: > https://lore.kernel.org/qemu-devel/20190607034214.GB22416@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. -- Eduardo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Python 2 and test/vm/netbsd 2019-10-17 22:05 ` Eduardo Habkost @ 2019-10-17 22:55 ` Eduardo Habkost 2019-10-18 7:13 ` Thomas Huth 2019-10-18 10:44 ` Gerd Hoffmann 0 siblings, 2 replies; 19+ messages in thread From: Eduardo Habkost @ 2019-10-17 22:55 UTC (permalink / raw) To: Thomas Huth Cc: Fam Zheng, Peter Maydell, Alex Bennée, QEMU Developers, Philippe Mathieu-Daudé, Marc-André Lureau, Kamil Rytarowski, Gerd Hoffmann, Cleber Rosa, Kevin Wolf, John Snow 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_2zG7JRX5uV4AaSSjXCSs4+A@mail.gmail.com/ > > > > Possibly this is the same issue we saw at: > > https://lore.kernel.org/qemu-devel/20190607034214.GB22416@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. Output of `strace -e trace=network` below: 1571352260.348566 recvfrom(30, "~[\201\200\0\1\0\1\0\0\0\0\3ftp\6NetBSD\3org\0\0\1\0\1"..., 1500, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.5.30.160")}, [128->16]) = 48 <0.000016> 1571352260.349030 socket(AF_INET6, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_IP) = 31 <0.000041> 1571352260.349142 setsockopt(31, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 <0.000009> 1571352260.349179 setsockopt(31, SOL_SOCKET, SO_OOBINLINE, [1], 4) = 0 <0.000007> 1571352260.349207 setsockopt(31, SOL_TCP, TCP_NODELAY, [1], 4) = 0 <0.000008> 1571352260.349239 connect(31, {sa_family=AF_INET6, sin6_port=htons(80), sin6_flowinfo=htonl(67108864), inet_pton(AF_INET6, "2001:470:a085:999::21", &sin6_addr), sin6_scope_id=377348480}, 28) = -1 ENETUNREACH (Network is unreachable) <0.000 021> 1571352266.350112 socket(AF_INET6, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_IP) = 31 <0.000131> 1571352266.350603 setsockopt(31, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 <0.000183> 1571352266.350946 setsockopt(31, SOL_SOCKET, SO_OOBINLINE, [1], 4) = 0 <0.000047> 1571352266.351109 setsockopt(31, SOL_TCP, TCP_NODELAY, [1], 4) = 0 <0.000043> 1571352266.351260 connect(31, {sa_family=AF_INET6, sin6_port=htons(80), sin6_flowinfo=htonl(67108864), inet_pton(AF_INET6, "2001:470:a085:999::21", &sin6_addr), sin6_scope_id=377348480}, 28) = -1 ENETUNREACH (Network is unreachable) <0.000070> 1571352278.357962 socket(AF_INET6, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_IP) = 29 <0.000166> 1571352278.358524 setsockopt(29, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 <0.000046> 1571352278.358757 setsockopt(29, SOL_SOCKET, SO_OOBINLINE, [1], 4) = 0 <0.000046> 1571352278.358950 setsockopt(29, SOL_TCP, TCP_NODELAY, [1], 4) = 0 <0.000039> 1571352278.359103 connect(29, {sa_family=AF_INET6, sin6_port=htons(80), sin6_flowinfo=htonl(67108864), inet_pton(AF_INET6, "2001:470:a085:999::21", &sin6_addr), sin6_scope_id=377348480}, 28) = -1 ENETUNREACH (Network is unreachable) <0.000065> 1571352302.373056 socket(AF_INET6, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_IP) = 29 <0.000323> 1571352302.373909 setsockopt(29, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 <0.000162> 1571352302.374331 setsockopt(29, SOL_SOCKET, SO_OOBINLINE, [1], 4) = 0 <0.000159> 1571352302.374626 setsockopt(29, SOL_TCP, TCP_NODELAY, [1], 4) = 0 <0.000050> 1571352302.374857 connect(29, {sa_family=AF_INET6, sin6_port=htons(80), sin6_flowinfo=htonl(67108864), inet_pton(AF_INET6, "2001:470:a085:999::21", &sin6_addr), sin6_scope_id=377348480}, 28) = -1 ENETUNREACH (Network is unreachable) <0.000070> 1571352335.394568 socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_IP) = 29 <0.000091> 1571352335.394796 setsockopt(29, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 <0.000011> 1571352335.394848 setsockopt(29, SOL_SOCKET, SO_OOBINLINE, [1], 4) = 0 <0.000009> 1571352335.394883 setsockopt(29, SOL_TCP, TCP_NODELAY, [1], 4) = 0 <0.000008> 1571352335.394913 connect(29, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("199.233.217.201")}, 16) = -1 EINPROGRESS (Operation now in progress) <0.000055> 1571352335.587395 sendto(29, "", 0, 0, NULL, 0) = 0 <0.000220> 1571352335.589650 sendto(29, "GET /pub/pkgsrc/packages/NetBSD/"..., 81, 0, NULL, 0) = 81 <0.000088> -- Eduardo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Python 2 and test/vm/netbsd 2019-10-17 22:55 ` Eduardo Habkost @ 2019-10-18 7:13 ` Thomas Huth 2019-10-18 14:51 ` Eduardo Habkost 2019-10-18 10:44 ` Gerd Hoffmann 1 sibling, 1 reply; 19+ messages in thread From: Thomas Huth @ 2019-10-18 7:13 UTC (permalink / raw) To: Eduardo Habkost Cc: Fam Zheng, Peter Maydell, Samuel Thibault, Philippe Mathieu-Daudé, QEMU Developers, John Snow, Kamil Rytarowski, Gerd Hoffmann, Kevin Wolf, Cleber Rosa, Marc-André Lureau, Alex Bennée 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_2zG7JRX5uV4AaSSjXCSs4+A@mail.gmail.com/ >>> >>> Possibly this is the same issue we saw at: >>> https://lore.kernel.org/qemu-devel/20190607034214.GB22416@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: Thomas > Output of `strace -e trace=network` below: > > 1571352260.348566 recvfrom(30, "~[\201\200\0\1\0\1\0\0\0\0\3ftp\6NetBSD\3org\0\0\1\0\1"..., 1500, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.5.30.160")}, [128->16]) = 48 <0.000016> > 1571352260.349030 socket(AF_INET6, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_IP) = 31 <0.000041> > 1571352260.349142 setsockopt(31, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 <0.000009> > 1571352260.349179 setsockopt(31, SOL_SOCKET, SO_OOBINLINE, [1], 4) = 0 <0.000007> > 1571352260.349207 setsockopt(31, SOL_TCP, TCP_NODELAY, [1], 4) = 0 <0.000008> > 1571352260.349239 connect(31, {sa_family=AF_INET6, sin6_port=htons(80), sin6_flowinfo=htonl(67108864), inet_pton(AF_INET6, "2001:470:a085:999::21", &sin6_addr), sin6_scope_id=377348480}, 28) = -1 ENETUNREACH (Network is unreachable) <0.000 > 021> > 1571352266.350112 socket(AF_INET6, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_IP) = 31 <0.000131> > 1571352266.350603 setsockopt(31, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 <0.000183> > 1571352266.350946 setsockopt(31, SOL_SOCKET, SO_OOBINLINE, [1], 4) = 0 <0.000047> > 1571352266.351109 setsockopt(31, SOL_TCP, TCP_NODELAY, [1], 4) = 0 <0.000043> > 1571352266.351260 connect(31, {sa_family=AF_INET6, sin6_port=htons(80), sin6_flowinfo=htonl(67108864), inet_pton(AF_INET6, "2001:470:a085:999::21", &sin6_addr), sin6_scope_id=377348480}, 28) = -1 ENETUNREACH (Network is unreachable) <0.000070> > 1571352278.357962 socket(AF_INET6, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_IP) = 29 <0.000166> > 1571352278.358524 setsockopt(29, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 <0.000046> > 1571352278.358757 setsockopt(29, SOL_SOCKET, SO_OOBINLINE, [1], 4) = 0 <0.000046> > 1571352278.358950 setsockopt(29, SOL_TCP, TCP_NODELAY, [1], 4) = 0 <0.000039> > 1571352278.359103 connect(29, {sa_family=AF_INET6, sin6_port=htons(80), sin6_flowinfo=htonl(67108864), inet_pton(AF_INET6, "2001:470:a085:999::21", &sin6_addr), sin6_scope_id=377348480}, 28) = -1 ENETUNREACH (Network is unreachable) <0.000065> > 1571352302.373056 socket(AF_INET6, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_IP) = 29 <0.000323> > 1571352302.373909 setsockopt(29, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 <0.000162> > 1571352302.374331 setsockopt(29, SOL_SOCKET, SO_OOBINLINE, [1], 4) = 0 <0.000159> > 1571352302.374626 setsockopt(29, SOL_TCP, TCP_NODELAY, [1], 4) = 0 <0.000050> > 1571352302.374857 connect(29, {sa_family=AF_INET6, sin6_port=htons(80), sin6_flowinfo=htonl(67108864), inet_pton(AF_INET6, "2001:470:a085:999::21", &sin6_addr), sin6_scope_id=377348480}, 28) = -1 ENETUNREACH (Network is unreachable) <0.000070> > 1571352335.394568 socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_IP) = 29 <0.000091> > 1571352335.394796 setsockopt(29, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 <0.000011> > 1571352335.394848 setsockopt(29, SOL_SOCKET, SO_OOBINLINE, [1], 4) = 0 <0.000009> > 1571352335.394883 setsockopt(29, SOL_TCP, TCP_NODELAY, [1], 4) = 0 <0.000008> > 1571352335.394913 connect(29, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("199.233.217.201")}, 16) = -1 EINPROGRESS (Operation now in progress) <0.000055> > 1571352335.587395 sendto(29, "", 0, 0, NULL, 0) = 0 <0.000220> > 1571352335.589650 sendto(29, "GET /pub/pkgsrc/packages/NetBSD/"..., 81, 0, NULL, 0) = 81 <0.000088> > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Python 2 and test/vm/netbsd 2019-10-18 7:13 ` Thomas Huth @ 2019-10-18 14:51 ` Eduardo Habkost 0 siblings, 0 replies; 19+ messages in thread From: Eduardo Habkost @ 2019-10-18 14:51 UTC (permalink / raw) To: Thomas Huth Cc: Fam Zheng, Peter Maydell, Samuel Thibault, Philippe Mathieu-Daudé, QEMU Developers, John Snow, Kamil Rytarowski, Gerd Hoffmann, Kevin Wolf, Cleber Rosa, Marc-André Lureau, Alex Bennée 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_2zG7JRX5uV4AaSSjXCSs4+A@mail.gmail.com/ > >>> > >>> Possibly this is the same issue we saw at: > >>> https://lore.kernel.org/qemu-devel/20190607034214.GB22416@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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Python 2 and test/vm/netbsd 2019-10-17 22:55 ` Eduardo Habkost 2019-10-18 7:13 ` Thomas Huth @ 2019-10-18 10:44 ` Gerd Hoffmann 2019-10-18 14:29 ` Eduardo Habkost 1 sibling, 1 reply; 19+ messages in thread From: Gerd Hoffmann @ 2019-10-18 10:44 UTC (permalink / raw) To: Eduardo Habkost Cc: Fam Zheng, Peter Maydell, Thomas Huth, Philippe Mathieu-Daudé, QEMU Developers, John Snow, Kamil Rytarowski, Kevin Wolf, Cleber Rosa, Marc-André Lureau, Alex Bennée Hi, > > 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. Ah, that nicely explains why it worked just fine for me. First, I have a local proxy configured so the installer isn't going to connect to ftp.NetBSD.org directly. Second I have IPv6 connectivity. > I don't know if this is a NetBSD bug, or a slirp bug. Both I'd say ... First, by default slirp should not send IPv6 router announcements to the user network if the host has no IPv6 connectivity. Second, the recommended way to connect is to try ipv4 and ipv6 in parallel, then use whatever connects first. Web browsers typically do it that way. wget and curl don't do that though, they try one address after the other, and I guess this is where the delay comes from ... cheers, Gerd ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Python 2 and test/vm/netbsd 2019-10-18 10:44 ` Gerd Hoffmann @ 2019-10-18 14:29 ` Eduardo Habkost 2019-10-18 14:58 ` Philippe Mathieu-Daudé 0 siblings, 1 reply; 19+ messages in thread From: Eduardo Habkost @ 2019-10-18 14:29 UTC (permalink / raw) To: Gerd Hoffmann Cc: Fam Zheng, Peter Maydell, Thomas Huth, Philippe Mathieu-Daudé, QEMU Developers, John Snow, Kamil Rytarowski, Kevin Wolf, Cleber Rosa, Marc-André Lureau, Alex Bennée On Fri, Oct 18, 2019 at 12:44:39PM +0200, Gerd Hoffmann wrote: > Hi, > > > > 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. > > Ah, that nicely explains why it worked just fine for me. First, I have > a local proxy configured so the installer isn't going to connect to > ftp.NetBSD.org directly. Second I have IPv6 connectivity. > > > I don't know if this is a NetBSD bug, or a slirp bug. > > Both I'd say ... > > First, by default slirp should not send IPv6 router announcements > to the user network if the host has no IPv6 connectivity. > > Second, the recommended way to connect is to try ipv4 and ipv6 in > parallel, then use whatever connects first. Web browsers typically > do it that way. wget and curl don't do that though, they try one > address after the other, and I guess this is where the delay comes > from ... In addition to that, the connect() error should be generating a ICMP6_UNREACH message, and I'd expect the NetBSD guest to notice it instead of waiting for timeout. -- Eduardo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Python 2 and test/vm/netbsd 2019-10-18 14:29 ` Eduardo Habkost @ 2019-10-18 14:58 ` Philippe Mathieu-Daudé 2019-10-18 16:00 ` Samuel Thibault 0 siblings, 1 reply; 19+ messages in thread From: Philippe Mathieu-Daudé @ 2019-10-18 14:58 UTC (permalink / raw) To: Eduardo Habkost, Gerd Hoffmann, Samuel Thibault Cc: Fam Zheng, Peter Maydell, Thomas Huth, John Snow, QEMU Developers, Kamil Rytarowski, Kevin Wolf, Cleber Rosa, Marc-André Lureau, Alex Bennée On 10/18/19 4:29 PM, Eduardo Habkost wrote: > On Fri, Oct 18, 2019 at 12:44:39PM +0200, Gerd Hoffmann wrote: >> Hi, >> >>>> 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. >> >> Ah, that nicely explains why it worked just fine for me. First, I have >> a local proxy configured so the installer isn't going to connect to >> ftp.NetBSD.org directly. Second I have IPv6 connectivity. >> >>> I don't know if this is a NetBSD bug, or a slirp bug. >> >> Both I'd say ... >> >> First, by default slirp should not send IPv6 router announcements >> to the user network if the host has no IPv6 connectivity. >> >> Second, the recommended way to connect is to try ipv4 and ipv6 in >> parallel, then use whatever connects first. Web browsers typically >> do it that way. wget and curl don't do that though, they try one >> address after the other, and I guess this is where the delay comes >> from ... > > In addition to that, the connect() error should be generating a > ICMP6_UNREACH message, and I'd expect the NetBSD guest to notice > it instead of waiting for timeout. Is this missing in SLiRP? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Python 2 and test/vm/netbsd 2019-10-18 14:58 ` Philippe Mathieu-Daudé @ 2019-10-18 16:00 ` Samuel Thibault 2019-10-18 16:41 ` Eduardo Habkost 2019-10-22 13:10 ` Samuel Thibault 0 siblings, 2 replies; 19+ messages in thread From: Samuel Thibault @ 2019-10-18 16:00 UTC (permalink / raw) To: Philippe Mathieu-Daudé Cc: Fam Zheng, Peter Maydell, Thomas Huth, Eduardo Habkost, John Snow, QEMU Developers, Kamil Rytarowski, Gerd Hoffmann, Kevin Wolf, Cleber Rosa, Marc-André Lureau, Alex Bennée Philippe Mathieu-Daudé, le ven. 18 oct. 2019 16:58:00 +0200, a ecrit: > On 10/18/19 4:29 PM, Eduardo Habkost wrote: > > On Fri, Oct 18, 2019 at 12:44:39PM +0200, Gerd Hoffmann wrote: > > > Hi, > > > > > > > > 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. > > > > > > Ah, that nicely explains why it worked just fine for me. First, I have > > > a local proxy configured so the installer isn't going to connect to > > > ftp.NetBSD.org directly. Second I have IPv6 connectivity. > > > > > > > I don't know if this is a NetBSD bug, or a slirp bug. > > > > > > Both I'd say ... > > > > > > First, by default slirp should not send IPv6 router announcements > > > to the user network if the host has no IPv6 connectivity. > > > > > > Second, the recommended way to connect is to try ipv4 and ipv6 in > > > parallel, then use whatever connects first. Web browsers typically > > > do it that way. wget and curl don't do that though, they try one > > > address after the other, and I guess this is where the delay comes > > > from ... > > > > In addition to that, the connect() error should be generating a > > ICMP6_UNREACH message, and I'd expect the NetBSD guest to notice > > it instead of waiting for timeout. > > Is this missing in SLiRP? It was implemented at the time of introduction of IPv6 in SLIRP. Perhaps NetBSD has a slightly different behavior which makes the implementation fail to notice the error. Samuel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Python 2 and test/vm/netbsd 2019-10-18 16:00 ` Samuel Thibault @ 2019-10-18 16:41 ` Eduardo Habkost 2019-10-22 13:16 ` Samuel Thibault 2019-10-22 13:10 ` Samuel Thibault 1 sibling, 1 reply; 19+ messages in thread From: Eduardo Habkost @ 2019-10-18 16:41 UTC (permalink / raw) To: Samuel Thibault Cc: Fam Zheng, Peter Maydell, Thomas Huth, Alex Bennée, QEMU Developers, John Snow, Kamil Rytarowski, Gerd Hoffmann, Kevin Wolf, Cleber Rosa, Marc-André Lureau, Philippe Mathieu-Daudé [-- Attachment #1: Type: text/plain, Size: 2095 bytes --] On Fri, Oct 18, 2019 at 06:00:19PM +0200, Samuel Thibault wrote: > Philippe Mathieu-Daudé, le ven. 18 oct. 2019 16:58:00 +0200, a ecrit: > > On 10/18/19 4:29 PM, Eduardo Habkost wrote: > > > On Fri, Oct 18, 2019 at 12:44:39PM +0200, Gerd Hoffmann wrote: > > > > Hi, > > > > > > > > > > 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. > > > > > > > > Ah, that nicely explains why it worked just fine for me. First, I have > > > > a local proxy configured so the installer isn't going to connect to > > > > ftp.NetBSD.org directly. Second I have IPv6 connectivity. > > > > > > > > > I don't know if this is a NetBSD bug, or a slirp bug. > > > > > > > > Both I'd say ... > > > > > > > > First, by default slirp should not send IPv6 router announcements > > > > to the user network if the host has no IPv6 connectivity. > > > > > > > > Second, the recommended way to connect is to try ipv4 and ipv6 in > > > > parallel, then use whatever connects first. Web browsers typically > > > > do it that way. wget and curl don't do that though, they try one > > > > address after the other, and I guess this is where the delay comes > > > > from ... > > > > > > In addition to that, the connect() error should be generating a > > > ICMP6_UNREACH message, and I'd expect the NetBSD guest to notice > > > it instead of waiting for timeout. > > > > Is this missing in SLiRP? > > It was implemented at the time of introduction of IPv6 in SLIRP. Perhaps > NetBSD has a slightly different behavior which makes the implementation > fail to notice the error. If anybody is interested in investigating it, a network traffic dump generated by `-object filter-dump` is attached. -- Eduardo [-- Attachment #2: dump.pcap.gz --] [-- Type: application/gzip, Size: 1908 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Python 2 and test/vm/netbsd 2019-10-18 16:41 ` Eduardo Habkost @ 2019-10-22 13:16 ` Samuel Thibault 2019-10-22 13:05 ` Kamil Rytarowski 0 siblings, 1 reply; 19+ messages in thread From: Samuel Thibault @ 2019-10-22 13:16 UTC (permalink / raw) To: Eduardo Habkost Cc: Fam Zheng, Peter Maydell, Thomas Huth, Alex Bennée, QEMU Developers, John Snow, Kamil Rytarowski, Gerd Hoffmann, Kevin Wolf, Cleber Rosa, Marc-André Lureau, Philippe Mathieu-Daudé Eduardo Habkost, le ven. 18 oct. 2019 13:41:43 -0300, a ecrit: > On Fri, Oct 18, 2019 at 06:00:19PM +0200, Samuel Thibault wrote: > > It was implemented at the time of introduction of IPv6 in SLIRP. Perhaps > > NetBSD has a slightly different behavior which makes the implementation > > fail to notice the error. > > If anybody is interested in investigating it, a network traffic > dump generated by `-object filter-dump` is attached. The dump does show the Destination Unreachable icmp message, so it seems it's the guest which does not notice it for some reason. Samuel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Python 2 and test/vm/netbsd 2019-10-22 13:16 ` Samuel Thibault @ 2019-10-22 13:05 ` Kamil Rytarowski 0 siblings, 0 replies; 19+ messages in thread From: Kamil Rytarowski @ 2019-10-22 13:05 UTC (permalink / raw) To: Samuel Thibault, Eduardo Habkost Cc: Fam Zheng, Peter Maydell, Thomas Huth, Alex Bennée, QEMU Developers, John Snow, Kamil Rytarowski, Gerd Hoffmann, Kevin Wolf, Cleber Rosa, Marc-André Lureau, Philippe Mathieu-Daudé On 22.10.2019 15:16, Samuel Thibault wrote: > Eduardo Habkost, le ven. 18 oct. 2019 13:41:43 -0300, a ecrit: >> On Fri, Oct 18, 2019 at 06:00:19PM +0200, Samuel Thibault wrote: >>> It was implemented at the time of introduction of IPv6 in SLIRP. Perhaps >>> NetBSD has a slightly different behavior which makes the implementation >>> fail to notice the error. >> >> If anybody is interested in investigating it, a network traffic >> dump generated by `-object filter-dump` is attached. > > The dump does show the Destination Unreachable icmp message, so it seems > it's the guest which does not notice it for some reason. > > Samuel > I will try to investigate it on the NetBSD kernel level. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Python 2 and test/vm/netbsd 2019-10-18 16:00 ` Samuel Thibault 2019-10-18 16:41 ` Eduardo Habkost @ 2019-10-22 13:10 ` Samuel Thibault 1 sibling, 0 replies; 19+ messages in thread From: Samuel Thibault @ 2019-10-22 13:10 UTC (permalink / raw) To: Philippe Mathieu-Daudé Cc: Fam Zheng, Peter Maydell, Thomas Huth, Eduardo Habkost, John Snow, QEMU Developers, Kamil Rytarowski, Gerd Hoffmann, Kevin Wolf, Cleber Rosa, Marc-André Lureau, Alex Bennée Samuel Thibault, le ven. 18 oct. 2019 18:00:19 +0200, a ecrit: > Philippe Mathieu-Daudé, le ven. 18 oct. 2019 16:58:00 +0200, a ecrit: > > On 10/18/19 4:29 PM, Eduardo Habkost wrote: > > > In addition to that, the connect() error should be generating a > > > ICMP6_UNREACH message, and I'd expect the NetBSD guest to notice > > > it instead of waiting for timeout. > > > > Is this missing in SLiRP? > > It was implemented at the time of introduction of IPv6 in SLIRP. Perhaps > NetBSD has a slightly different behavior which makes the implementation > fail to notice the error. It definitely is there in tcp_input(): on tcp_fconnect() error an ICMP6_UNREACH message is sent. I can confirm that this works with a Linux host and Linux guest. Samuel ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2019-10-22 13:18 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-10-16 3:00 Python 2 and test/vm/netbsd (was Re: [Qemu-devel] [PULL 0/8] Python queue, 2019-06-07) Eduardo Habkost 2019-10-16 6:11 ` Python 2 and test/vm/netbsd Thomas Huth 2019-10-16 8:25 ` Kamil Rytarowski 2019-10-16 10:59 ` Alex Bennée 2019-10-16 11:02 ` Thomas Huth 2019-10-16 12:23 ` Philippe Mathieu-Daudé 2019-10-16 22:41 ` Eduardo Habkost 2019-10-17 22:05 ` Eduardo Habkost 2019-10-17 22:55 ` Eduardo Habkost 2019-10-18 7:13 ` Thomas Huth 2019-10-18 14:51 ` Eduardo Habkost 2019-10-18 10:44 ` Gerd Hoffmann 2019-10-18 14:29 ` Eduardo Habkost 2019-10-18 14:58 ` Philippe Mathieu-Daudé 2019-10-18 16:00 ` Samuel Thibault 2019-10-18 16:41 ` Eduardo Habkost 2019-10-22 13:16 ` Samuel Thibault 2019-10-22 13:05 ` Kamil Rytarowski 2019-10-22 13:10 ` Samuel Thibault
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.