Date: Mon, 27 Jul 2020 21:01:30 -0700 From: Mark Millard <marklmi@yahoo.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: CFT: major update to if_ure (patch did not apply cleanly for head -r363510) (example PowerMac problem?) Message-ID: <6A801746-4FCA-450E-9A56-C8E06DF68C2D@yahoo.com> In-Reply-To: <FF15A935-F3C4-415A-A62B-69F412584229@yahoo.com> References: <D5A3AECA-96C8-4E16-8795-B590ED9D82E3.ref@yahoo.com> <D5A3AECA-96C8-4E16-8795-B590ED9D82E3@yahoo.com> <20200727012035.GS4213@funkthat.com> <F5CFD6E1-787B-4416-B666-86847166D99F@yahoo.com> <C2C302F7-7F36-450D-AF91-858008CBC5FA@yahoo.com> <78CB1756-28D7-4442-934D-9C4D2B37EC67@yahoo.com> <20200728014444.GY4213@funkthat.com> <B3042C56-23BB-4C18-AE44-BE22986F51B7@yahoo.com> <FF15A935-F3C4-415A-A62B-69F412584229@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[I figured out how it appeared to go faster than USB2.]
On 2020-Jul-27, at 20:07, Mark Millard <marklmi@yahoo.com> wrote:
> On 2020-Jul-27, at 19:07, Mark Millard <marklmi at yahoo.com> wrote:
>=20
>> On 2020-Jul-27, at 18:44, John-Mark Gurney <jmg at funkthat.com> =
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 <marklmi at yahoo.com> =
wrote:
>>>>=20
>>>>> On 2020-Jul-26, at 18:20, John-Mark Gurney <jmg at funkthat.com> =
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: <Unknown > 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: <Realtek USB 10/100/1000 LAN> at usbus2
>> ure0 numa-domain 0 on uhub2
>> ure0: <Realtek USB 10/100/1000 LAN, class 0/0, rev 2.10/30.00, addr =
2> on usbus2
>> miibus2: <MII bus> numa-domain 0 on ure0
>> rgephy0: <RTL8251/8153 1000BASE-T media interface> PHY 0 on miibus2
>> rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, =
1000baseT-FDX, 1000baseT-FDX-master, auto
>> ue0: <USB Ethernet> on ure0
>> ue0: Ethernet address: ###
>> ue0: link state changed to DOWN
>>=20
>> and:
>>=20
>> ue0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 =
mtu 1500
>> =
options=3D68009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTA=
TE,RXCSUM_IPV6,TXCSUM_IPV6>
>> ether ###
>> inet 192.168.1.149 netmask 0xffffff00 broadcast 192.168.1.255
>> media: Ethernet autoselect (1000baseT <full-duplex>)
>> status: active
>> nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>>=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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu =
1500
=
options=3D8009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTAT=
E>
###
inet 192.168.1.145 netmask 0xffffff00 broadcast 192.168.1.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=3D23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
ue0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu =
1500
=
options=3D68009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTA=
TE,RXCSUM_IPV6,TXCSUM_IPV6>
###
inet 192.168.1.149 netmask 0xffffff00 broadcast 192.168.1.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6A801746-4FCA-450E-9A56-C8E06DF68C2D>