From owner-freebsd-current@freebsd.org Tue Jul 28 03:07:20 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 080023792FB for ; Tue, 28 Jul 2020 03:07:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.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 4BG1n30HHmz3TVC for ; Tue, 28 Jul 2020 03:07:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: oaSV5x0VM1mgGOKerxA8mPw13I8QyWDjiFUt0Svgy07LSdtWJXX6sn30oyVW8sx w6.lXricD5VWhGYBhb7WTAq8gZWrF7xzZWLQYrmOE3oN9dDw0vm_byhfg2bFINDP4QPtA.YadUSF RMlJ3S4Zp1JNLkQhroyqK2RKT_k3mBj.Y6QLLb_roCCpVFdw.2JfOhn9nSZMz1hcpPKEjMKlJpjB QL5cB1EEvXNmDfI8HAdedBKK3hiafXtWdj2deXwEogPcrwNe92.HAdknCfM7iKZnBqpmDUbmqToX nNFJd16uQhoxyM8dPKjp60p9KSxojaDF_7l1pOK8NK4ENK7sy8jBP9zdP0HbAo3Q5DSgVKCQ4ESh FvCC3IKybSxUB6CpQ3EX0_8vp0pRbPFyvFVL09KdIX.Qh5JTXz3Dqe_Y._fLWmXxZojjsNt3g5Mp jcJO6e4NV8B1xdLI_O4ennHwuhW7ia8YVU2A0WNE0a_0K0S9TkzcJ7W1VbR2AGVnd03OnrTHZQzj xWUlOjXXNIGaydGZkhQc6bH4dOoktHaKqwfvaR9qkpinJoULDrbkny3GhktfG6n1WkUM1IGzV7ou bNHxc9EKpWmEV1Xmyi3it06vfX7k7cQ6dBno0naWfeAM.cDc7ToYt8honl35r_Dr3ZBqGR_v4Z52 mQEKiK6hqmqSEYgE4XtWRgJBXJMAVNvw8ux1UxKpSL4pUvKhGza_OTCj9gxCjv0wBgTjmPFPriYD UJxQR842KJSRBEKNyoX5tHSpkfTZ8mO7Dtc6yxa2LQu2A70VjzuXnq3B3_aTST1XM2ptiJdBr08q cTFhj89YjCGFk_VBtSKnbFNb.Gj.OV0u9pkIPFQmXQnPVzUKHcypI.H3r601syDT78uM9txFgTEj QxtJa6oaxztULyOnEOyYaj20pWmM_80R1t_2HXoSae8bA4mKfPxGR9eXbjiKg2Kp25DtKz5b4hwy RKLRWFsqBB4a1ib9vhxQT59Xr5JHKmrh7lRDo05fXLlIxYba5MDDJUYfgtRTa5oJcoN7TZj7nffs qvH4pf5Fw9GN6WCWuZtKjUSlxQT1XrSRYZzXRoRXRG6lGfgtyMfsPvTb06HhM298imtPvnvotNii EgwlCcSjezp96VlW3nkCjP2g61ASQejL5CrVR4e3hw58ZWqN2H56cs3qRlznk1rwkHlD_c_Qjkcs EcLtJyWCsGXWjDF9orO0BOo1vYArzrWr3CSqnSQ4Epqa2Nq1zplo5ayW01DYxkUaURwTPP7oZbyS SUy2OQsXm74i7AdEw3bmj0IZsUXxYaxsf5YCqDmAUvCmsNWVpYgOAMa48unn_cJb6sdGPCt5VP7R CmLCFaqsD.oS0fv.azjjrkITUr_czUo.oRaiwoMSknbh7sSQ3a7MizqQed_MHTV0ICkGice6iCSw _5_iAHdBmEpu05hO5gipekZpG8A5VDVhfoq2KhjMR5r.zYgj4mv_THmIzt_ft Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Tue, 28 Jul 2020 03:07:16 +0000 Received: by smtp429.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a849999a6070302c30ddb6e80bcd6fcb; Tue, 28 Jul 2020 03:07:15 +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 20:07:15 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: 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: 4BG1n30HHmz3TVC X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.03 / 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.48)[-0.476]; 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.045]; 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.69.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.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 03:07:20 -0000 On 2020-Jul-27, at 19:07, Mark Millard wrote: > 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 > # 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 31020 connected to 192.168.1.120 port = 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 113 MBytes 949 Mbits/sec 12 564 = KBytes =20 > [ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 98 549 = KBytes =20 > [ 5] 2.00-3.00 sec 113 MBytes 944 Mbits/sec 94 1.06 = MBytes =20 > [ 5] 3.00-4.00 sec 112 MBytes 942 Mbits/sec 96 719 = KBytes =20 > [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 98 883 = KBytes =20 > [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 93 439 = KBytes =20 > [ 5] 6.00-7.00 sec 112 MBytes 942 Mbits/sec 93 221 = KBytes =20 > [ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec 96 419 = KBytes =20 > [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 94 632 = KBytes =20 > [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec 97 175 = KBytes =20 > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 871 = sender > [ 5] 0.00-10.62 sec 1.10 GBytes 887 Mbits/sec = receiver >=20 > Server output: > ----------------------------------------------------------- > Server listening on 5201 > ----------------------------------------------------------- > Accepted connection from 192.168.1.149, port 45853 > [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.149 port = 31020 > [ ID] Interval Transfer Bitrate > [ 5] 0.00-1.00 sec 42.8 MBytes 359 Mbits/sec =20= > [ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec =20= > [ 5] 2.00-3.00 sec 112 MBytes 941 Mbits/sec =20= > [ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec =20= > [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec =20= > [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec =20= > [ 5] 6.00-7.00 sec 112 MBytes 941 Mbits/sec =20= > [ 5] 7.00-8.00 sec 112 MBytes 942 Mbits/sec =20= > [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec =20= > [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec =20= > [ 5] 10.00-10.62 sec 69.8 MBytes 941 Mbits/sec =20= > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate > [ 5] 0.00-10.62 sec 1.10 GBytes 887 Mbits/sec = receiver >=20 >=20 > iperf Done. 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? 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. I suppose another possibility is that it is an error that it appears to be going as fast as it appears above. > # 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 33527 connected to 192.168.1.120 port = 5201 > [ ID] Interval Transfer Bitrate > [ 5] 0.00-1.00 sec 14.2 MBytes 119 Mbits/sec =20= > [ 5] 1.00-2.00 sec 14.0 MBytes 118 Mbits/sec =20= > [ 5] 2.00-3.00 sec 13.9 MBytes 117 Mbits/sec =20= > [ 5] 3.00-4.00 sec 14.0 MBytes 118 Mbits/sec =20= > [ 5] 4.00-5.00 sec 14.1 MBytes 118 Mbits/sec =20= > [ 5] 5.00-6.00 sec 14.0 MBytes 118 Mbits/sec =20= > [ 5] 6.00-7.00 sec 14.0 MBytes 117 Mbits/sec =20= > [ 5] 7.00-8.00 sec 14.0 MBytes 118 Mbits/sec =20= > [ 5] 8.00-9.00 sec 14.0 MBytes 117 Mbits/sec =20= > [ 5] 9.00-10.00 sec 14.1 MBytes 118 Mbits/sec =20= > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.86 sec 140 MBytes 109 Mbits/sec 13654 = sender > [ 5] 0.00-10.00 sec 140 MBytes 118 Mbits/sec = receiver >=20 > Server output: > ----------------------------------------------------------- > Server listening on 5201 > ----------------------------------------------------------- > Accepted connection from 192.168.1.149, port 51685 > [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.149 port = 33527 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 2.21 MBytes 18.5 Mbits/sec 176 25.8 = KBytes =20 > [ 5] 1.00-2.00 sec 14.1 MBytes 118 Mbits/sec 1386 25.9 = KBytes =20 > [ 5] 2.00-3.00 sec 14.0 MBytes 118 Mbits/sec 1376 25.9 = KBytes =20 > [ 5] 3.00-4.00 sec 14.0 MBytes 117 Mbits/sec 1397 20.2 = KBytes =20 > [ 5] 4.00-5.00 sec 14.0 MBytes 118 Mbits/sec 1339 25.8 = KBytes =20 > [ 5] 5.00-6.00 sec 14.0 MBytes 118 Mbits/sec 1357 27.3 = KBytes =20 > [ 5] 6.00-7.00 sec 14.0 MBytes 118 Mbits/sec 1326 34.5 = KBytes =20 > [ 5] 7.00-8.00 sec 14.0 MBytes 117 Mbits/sec 1388 17.2 = KBytes =20 > [ 5] 8.00-9.00 sec 14.0 MBytes 118 Mbits/sec 1376 24.5 = KBytes =20 > [ 5] 9.00-10.00 sec 14.0 MBytes 117 Mbits/sec 1386 25.8 = KBytes =20 > [ 5] 10.00-10.86 sec 12.1 MBytes 118 Mbits/sec 1147 21.6 = KBytes =20 > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.86 sec 140 MBytes 109 Mbits/sec 13654 = sender >=20 >=20 > iperf Done. >=20 > Very asymmetric: send relatively fast, receive relatively slow. >=20 > 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. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)