From owner-freebsd-current@freebsd.org Tue Jul 28 04:01:36 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D233937C0BA for ; Tue, 28 Jul 2020 04:01:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BG2zg4zGzz3YDp for ; Tue, 28 Jul 2020 04:01:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: rnvaxDQVM1kNHRayVtjT4iU9uvzlABgeg3eAzN5vaB60o2_RWEdKrHk03OKoVbg uFp9E32xglUDWkhaINvN6t3.314KX25uzQOjChep59zGqrGp1HWKnR6tmJyhAdaxKYpJAMcHJ2a5 dj15hecJ.HisxD6gKzsjHUvjEO.5ypG41EeBEz_vqysl9kX2WVWt.qMw5jw93aB5Hrgm2d93_sxf ghyWy_YpdynKd.KIiMbjMhUN9rQy0sW76cwyCuBZpZwNIGloPBPIqyllm0rmnUEF1.sccGC63UOl ly2Q1AIot_sN3pWa5AK7JrS2wV2nZh0s09qLU2BPxud5yoGj7ono_k8gyaIVml88PQN2IKquf_b6 09Ihu0e9nlnGVPUkBkj26qdkUregCr8_gIryhGMzYI0h_fpxs8ELhNZNBHvMTEq9H3cTKfmPvCn8 Mt0B8lm5LIgZKGsx55yXMEKd6KM__i5RAl_Tu1dELPg0_7geGMMBtvb4fz06yV5nd1O7o76S8rTZ FMZLcreJJ2nKy2uoOzI_9aSgf349_CI6BotGGnpihySgnmXQjdrxW.QyL5eWK8AT0NVzl5t0CtPu TrIhei9w6fbceilJqYajH2cAxtSYcT6r3PIKTPAeRsyT0LIW23fW6bslPPSVK4H6Dxhmw5qbx3._ Bjn.GxbiKh35KtdB14wiAhT6JIP0m4x1.so13Cyp01pzUfXZsh9Abft04WdpbaWlbW8anipwEYu9 9Plha1KgufQlghCQR47CL9nR6_s5GTY.RGAZicDUzaLqKspXJsPT7yBJvw6lR4bPgDstXLq1lvxN j0Yq2HOx5cb9JdfrtKbme8tYhr01q8mQjGxzMG9NCRlZiN_5T84iMEYYNVdKLbIJqESyL7XCSzDD X_3SlZmQ136YtoKqMQkEVlVTZ4q8qkedKlDDzSrFqusAdhUdYS1cgRmBOVSThPiVXi_Xz_dFx_OK EIi2NZlApSThJHXJkztV4dUk3nMol3Lipo1TTqpJfCAbVKuCXjLshPGwo9xiCSKibf5ryTtL1ceD 433yxPYd1n4gfDNKhNCRGQJuMmLwXg6cCai8TaKB7fy75GWRCjsSlaTEtL8CxGv1xV0deVpGJEHu AHp79yLH.eKZ0XEHtO7YaLb60n0.6X2HiWaOonZrXTOyNxXIzwJC1ZDOkvky.UvSTOtn70j0OreZ i2kBOi7gKjSacWlSI4CcUl4..PF8dNifoy_DB5QUXrcMO3zYTDrJ7jtaZx6HYvoKd4OlvmYbdTOq muyrJ9pV2Absu8y1BsVgE97tOoPi7..M2fVOFQbcuUaWhIs1WcoCkxERlP9UB9d8zrvLTJlytP4P RRfx4cAGSTJG201CfFTgH.5ezuYfF4Exavjf8b9IEBtBKnojN7mTS0iNQv6t6Lk3KoRv1lAOKngK 4bdT.G5uJZYsrt3RT7p15ZKxTKe9nQU7Hq0LjcpMbF3yrXZ.40NLSYBmL7HSdiw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Tue, 28 Jul 2020 04:01:34 +0000 Received: by smtp426.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 88e30c8ecd1ee56ab4902892c2524ddd; Tue, 28 Jul 2020 04:01:30 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: CFT: major update to if_ure (patch did not apply cleanly for head -r363510) (example PowerMac problem?) From: Mark Millard In-Reply-To: Date: Mon, 27 Jul 2020 21:01:30 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <6A801746-4FCA-450E-9A56-C8E06DF68C2D@yahoo.com> References: <20200727012035.GS4213@funkthat.com> <78CB1756-28D7-4442-934D-9C4D2B37EC67@yahoo.com> <20200728014444.GY4213@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4BG2zg4zGzz3YDp X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.48 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.92)[-0.923]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.05)[-1.046]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.01)[-1.007]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.84:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 04:01:36 -0000 [I figured out how it appeared to go faster than USB2.] On 2020-Jul-27, at 20:07, Mark Millard wrote: > On 2020-Jul-27, at 19:07, Mark Millard wrote: >=20 >> On 2020-Jul-27, at 18:44, John-Mark Gurney = wrote: >>=20 >>> Mark Millard wrote this message on Mon, Jul 27, 2020 at 17:15 -0700: >>>> On 2020-Jul-27, at 16:43, Mark Millard = wrote: >>>>=20 >>>>> On 2020-Jul-26, at 18:20, John-Mark Gurney = wrote: >>>>>=20 >>>>>> Mark Millard wrote this message on Sat, Jul 25, 2020 at 19:13 = -0700: >>>>>>> For reference for what applying the patch >>>>>>> reported (see Hunk #14): >>>>>>=20 >>>>>> Ok, updated it to be relative to r363583... >>>>>>=20 >>>>>> I had made a white spcae commit to if_ure.c, but hadn't made the >>>>>> patch relative to it after that commit.. should work now.. >>>>>=20 >>>>> I updated an old PowerMac G5 (2 sockets/2 cores each) to >>>>> head -r363590 with the update patch and tjen plugged in the >>>>> USB EtherNet device. The result (extracted from dmesg -a) >>>>> was: >>>>>=20 >>>>> usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) >>>>> usbd_setup_device_desc: getting device descriptor at addr 2 = failed, USB_ERR_TIMEOUT >>>>> usbd_req_re_enumerate: addr=3D2, set address failed! = (USB_ERR_TIMEOUT, ignored) >>>>> usbd_setup_device_desc: getting device descriptor at addr 2 = failed, USB_ERR_TIMEOUT >>>>> usbd_req_re_enumerate: addr=3D2, set address failed! = (USB_ERR_TIMEOUT, ignored) >>>>> usbd_setup_device_desc: getting device descriptor at addr 2 = failed, USB_ERR_TIMEOUT >>>>> usbd_req_re_enumerate: addr=3D2, set address failed! = (USB_ERR_TIMEOUT, ignored) >>>>> usbd_setup_device_desc: getting device descriptor at addr 2 = failed, USB_ERR_TIMEOUT >>>>> usbd_req_re_enumerate: addr=3D2, set address failed! = (USB_ERR_TIMEOUT, ignored) >>>>> usbd_setup_device_desc: getting device descriptor at addr 2 = failed, USB_ERR_TIMEOUT >>>>> ugen2.2: at usbus2 (disconnected) >>>>> uhub_reattach_port: could not allocate new device >>>>>=20 >>>>> Unfortunately, I'd not tried a PowerMac with the type of >>>>> device before the update. I do not know if the above is >>>>> new behavior or not. >>>>>=20 >>>>> The PowerMac is big-endian, which is what got me to think >>>>> about trying it there. The PowerMac is also 64-bit running >>>>> a 64-bit FreeBSD. Its USB is 2.0. >>>>>=20 >>>>> (It also has 2 GigaBit EtherNet ports of its own so I'm not >>>>> likely to use a USB device outside special testing.) >>>>>=20 >>>>=20 >>>> I tried what normally shows as an axge0, but >>>> trying on the PowerMac G5. It got the same sort >>>> of messages as above. The problem does not seem >>>> to be tied to your patch. >>>>=20 >>>> It does prevent my testing the patch on the G5. >>>=20 >>> Yeah, I was going to say that the above messages are before any of >>> may changes get run, so it's unlikely a problem w/ my patch... >>> If the USB device can't get an address on the bus, then it can't >>> even ask what type of device it is to load the driver. >>>=20 >>> Thanks for trying though, maybe someone on the -powerpc list knows >>> of a fix for that. >>>=20 >>=20 >> Turns out that having: >>=20 >> hw.usb.xhci.use_polling=3D1 >>=20 >> in /boot/loader.conf allowed the old PowerMac context to >> get: >>=20 >> ugen2.2: at usbus2 >> ure0 numa-domain 0 on uhub2 >> ure0: on usbus2 >> miibus2: numa-domain 0 on ure0 >> rgephy0: PHY 0 on miibus2 >> rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto >> ue0: on ure0 >> ue0: Ethernet address: ### >> ue0: link state changed to DOWN >>=20 >> and: >>=20 >> ue0: flags=3D8843 metric 0 = mtu 1500 >> = options=3D68009b >> ether ### >> inet 192.168.1.149 netmask 0xffffff00 broadcast 192.168.1.255 >> media: Ethernet autoselect (1000baseT ) >> status: active >> nd6 options=3D29 >>=20 >> So, with that context, . . . >> (the two directions are widely mismatched) >>=20 >> . . . >=20 > The above is very odd for USB2 since USB2 is limited to > 480Mbits/sec, if I understand right. May be it is a mode > of use that is not getting data to send from USB > regularly at all, say internally generated data or > constant/repeated data only loaded from USB once? >=20 > If yes, then comparing to receiving is not useful and > it need not be useful for comparing to data that does > come from USB transfers. >=20 > I suppose another possibility is that it is an error > that it appears to be going as fast as it appears > above. I isolated the problem: it was not really using 192.168.1.149, but instead 192.168.1.145 (the builtin bge0). This is despite the -N and what the output reported. FYI: bge0: flags=3D8843 metric 0 mtu = 1500 = options=3D8009b ### inet 192.168.1.145 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT ) status: active nd6 options=3D23 ue0: flags=3D8843 metric 0 mtu = 1500 = options=3D68009b ### inet 192.168.1.149 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT ) status: active nd6 options=3D29 After using: # ifconfig bge0 down things behaved with speeds that USB2 can handle: # iperf3 -c 192.168.1.120 -B 192.168.1.149 --get-server-output Connecting to host 192.168.1.120, port 5201 [ 5] local 192.168.1.149 port 62507 connected to 192.168.1.120 port = 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 15.9 MBytes 133 Mbits/sec 2 115 KBytes = =20 [ 5] 1.00-2.00 sec 15.6 MBytes 131 Mbits/sec 4 111 KBytes = =20 [ 5] 2.00-3.00 sec 15.7 MBytes 131 Mbits/sec 4 101 KBytes = =20 [ 5] 3.00-4.00 sec 15.6 MBytes 131 Mbits/sec 5 84.1 KBytes = =20 [ 5] 4.00-5.00 sec 15.6 MBytes 131 Mbits/sec 3 62.7 KBytes = =20 [ 5] 5.00-6.00 sec 15.7 MBytes 131 Mbits/sec 5 39.9 KBytes = =20 [ 5] 6.00-7.00 sec 15.7 MBytes 131 Mbits/sec 5 34.2 KBytes = =20 [ 5] 7.00-8.00 sec 15.7 MBytes 131 Mbits/sec 3 9.98 KBytes = =20 [ 5] 8.00-9.00 sec 15.6 MBytes 131 Mbits/sec 4 15.7 KBytes = =20 [ 5] 9.00-10.00 sec 15.6 MBytes 131 Mbits/sec 4 123 KBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 157 MBytes 131 Mbits/sec 39 = sender [ 5] 0.00-10.98 sec 157 MBytes 120 Mbits/sec = receiver Server output: ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.1.149, port 42844 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.149 port = 62507 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 424 KBytes 3.48 Mbits/sec =20 [ 5] 1.00-2.00 sec 15.7 MBytes 131 Mbits/sec =20 [ 5] 2.00-3.00 sec 15.6 MBytes 131 Mbits/sec =20 [ 5] 3.00-4.00 sec 15.6 MBytes 131 Mbits/sec =20 [ 5] 4.00-5.00 sec 15.6 MBytes 131 Mbits/sec =20 [ 5] 5.00-6.00 sec 15.6 MBytes 131 Mbits/sec =20 [ 5] 6.00-7.00 sec 15.6 MBytes 131 Mbits/sec =20 [ 5] 7.00-8.00 sec 15.6 MBytes 131 Mbits/sec =20 [ 5] 8.00-9.00 sec 15.7 MBytes 131 Mbits/sec =20 [ 5] 9.00-10.00 sec 15.6 MBytes 131 Mbits/sec =20 [ 5] 10.00-10.98 sec 15.3 MBytes 131 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate And: # iperf3 -R -c 192.168.1.120 -B 192.168.1.149 --get-server-output Connecting to host 192.168.1.120, port 5201 Reverse mode, remote host 192.168.1.120 is sending [ 5] local 192.168.1.149 port 61744 connected to 192.168.1.120 port = 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 13.7 MBytes 115 Mbits/sec =20 [ 5] 1.00-2.00 sec 13.5 MBytes 114 Mbits/sec =20 [ 5] 2.00-3.00 sec 13.5 MBytes 114 Mbits/sec =20 [ 5] 3.00-4.00 sec 13.5 MBytes 113 Mbits/sec =20 [ 5] 4.00-5.00 sec 13.6 MBytes 114 Mbits/sec =20 [ 5] 5.00-6.00 sec 13.5 MBytes 113 Mbits/sec =20 [ 5] 6.00-7.00 sec 13.5 MBytes 113 Mbits/sec =20 [ 5] 7.00-8.00 sec 13.5 MBytes 113 Mbits/sec =20 [ 5] 8.00-9.00 sec 13.5 MBytes 113 Mbits/sec =20 [ 5] 9.00-10.00 sec 13.4 MBytes 113 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.84 sec 135 MBytes 105 Mbits/sec 12652 = sender [ 5] 0.00-10.00 sec 135 MBytes 113 Mbits/sec = receiver Server output: ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.1.149, port 12490 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.149 port = 61744 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 2.25 MBytes 18.9 Mbits/sec 186 30.1 KBytes = =20 [ 5] 1.00-2.00 sec 13.7 MBytes 115 Mbits/sec 1242 34.4 KBytes = =20 [ 5] 2.00-3.00 sec 13.5 MBytes 113 Mbits/sec 1291 27.3 KBytes = =20 [ 5] 3.00-4.00 sec 13.5 MBytes 114 Mbits/sec 1242 34.5 KBytes = =20 [ 5] 4.00-5.00 sec 13.5 MBytes 113 Mbits/sec 1302 25.8 KBytes = =20 [ 5] 5.00-6.00 sec 13.6 MBytes 114 Mbits/sec 1249 27.3 KBytes = =20 [ 5] 6.00-7.00 sec 13.4 MBytes 113 Mbits/sec 1285 21.6 KBytes = =20 [ 5] 7.00-8.00 sec 13.5 MBytes 113 Mbits/sec 1238 33.0 KBytes = =20 [ 5] 8.00-9.00 sec 13.6 MBytes 114 Mbits/sec 1260 31.6 KBytes = =20 [ 5] 9.00-10.00 sec 13.5 MBytes 113 Mbits/sec 1256 25.9 KBytes = =20 [ 5] 10.00-10.84 sec 11.3 MBytes 112 Mbits/sec 1101 18.8 KBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.84 sec 135 MBytes 105 Mbits/sec 12652 = sender iperf Done. So do not necessarily believe the -B IP-ADDR or local IP-ADDR reporting if there is an alternative active, at least for sending data. >> . . . >>=20 >> Very asymmetric: send relatively fast, receive relatively slow. Not after the above problem avoidance: now both relatively slow for hw.usb.xhci.use_polling=3D1 use. >> I've not tried hw.usb.xhci.use_polling=3D1 in any other context. So, >> for all I know, the results of using such could be expected. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)