CFT: major update to if_ure (patch did not apply cleanly for head -r363510) (example PowerMac problem?)
Mark Millard
marklmi at yahoo.com
Tue Jul 28 04:01:36 UTC 2020
[I figured out how it appeared to go faster than USB2.]
On 2020-Jul-27, at 20:07, Mark Millard <marklmi at yahoo.com> wrote:
> On 2020-Jul-27, at 19:07, Mark Millard <marklmi at yahoo.com> wrote:
>
>> On 2020-Jul-27, at 18:44, John-Mark Gurney <jmg at funkthat.com> wrote:
>>
>>> 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:
>>>>
>>>>> On 2020-Jul-26, at 18:20, John-Mark Gurney <jmg at funkthat.com> wrote:
>>>>>
>>>>>> 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):
>>>>>>
>>>>>> Ok, updated it to be relative to r363583...
>>>>>>
>>>>>> 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..
>>>>>
>>>>> 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:
>>>>>
>>>>> 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=2, 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=2, 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=2, 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=2, 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
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> (It also has 2 GigaBit EtherNet ports of its own so I'm not
>>>>> likely to use a USB device outside special testing.)
>>>>>
>>>>
>>>> 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.
>>>>
>>>> It does prevent my testing the patch on the G5.
>>>
>>> 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.
>>>
>>> Thanks for trying though, maybe someone on the -powerpc list knows
>>> of a fix for that.
>>>
>>
>> Turns out that having:
>>
>> hw.usb.xhci.use_polling=1
>>
>> in /boot/loader.conf allowed the old PowerMac context to
>> get:
>>
>> 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
>>
>> and:
>>
>> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>> options=68009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE,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=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>>
>> So, with that context, . . .
>> (the two directions are widely mismatched)
>>
>> . . .
>
> 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.
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=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE>
###
inet 192.168.1.145 netmask 0xffffff00 broadcast 192.168.1.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=68009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE,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=29<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
[ 5] 1.00-2.00 sec 15.6 MBytes 131 Mbits/sec 4 111 KBytes
[ 5] 2.00-3.00 sec 15.7 MBytes 131 Mbits/sec 4 101 KBytes
[ 5] 3.00-4.00 sec 15.6 MBytes 131 Mbits/sec 5 84.1 KBytes
[ 5] 4.00-5.00 sec 15.6 MBytes 131 Mbits/sec 3 62.7 KBytes
[ 5] 5.00-6.00 sec 15.7 MBytes 131 Mbits/sec 5 39.9 KBytes
[ 5] 6.00-7.00 sec 15.7 MBytes 131 Mbits/sec 5 34.2 KBytes
[ 5] 7.00-8.00 sec 15.7 MBytes 131 Mbits/sec 3 9.98 KBytes
[ 5] 8.00-9.00 sec 15.6 MBytes 131 Mbits/sec 4 15.7 KBytes
[ 5] 9.00-10.00 sec 15.6 MBytes 131 Mbits/sec 4 123 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 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
[ 5] 1.00-2.00 sec 15.7 MBytes 131 Mbits/sec
[ 5] 2.00-3.00 sec 15.6 MBytes 131 Mbits/sec
[ 5] 3.00-4.00 sec 15.6 MBytes 131 Mbits/sec
[ 5] 4.00-5.00 sec 15.6 MBytes 131 Mbits/sec
[ 5] 5.00-6.00 sec 15.6 MBytes 131 Mbits/sec
[ 5] 6.00-7.00 sec 15.6 MBytes 131 Mbits/sec
[ 5] 7.00-8.00 sec 15.6 MBytes 131 Mbits/sec
[ 5] 8.00-9.00 sec 15.7 MBytes 131 Mbits/sec
[ 5] 9.00-10.00 sec 15.6 MBytes 131 Mbits/sec
[ 5] 10.00-10.98 sec 15.3 MBytes 131 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 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
[ 5] 1.00-2.00 sec 13.5 MBytes 114 Mbits/sec
[ 5] 2.00-3.00 sec 13.5 MBytes 114 Mbits/sec
[ 5] 3.00-4.00 sec 13.5 MBytes 113 Mbits/sec
[ 5] 4.00-5.00 sec 13.6 MBytes 114 Mbits/sec
[ 5] 5.00-6.00 sec 13.5 MBytes 113 Mbits/sec
[ 5] 6.00-7.00 sec 13.5 MBytes 113 Mbits/sec
[ 5] 7.00-8.00 sec 13.5 MBytes 113 Mbits/sec
[ 5] 8.00-9.00 sec 13.5 MBytes 113 Mbits/sec
[ 5] 9.00-10.00 sec 13.4 MBytes 113 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 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
[ 5] 1.00-2.00 sec 13.7 MBytes 115 Mbits/sec 1242 34.4 KBytes
[ 5] 2.00-3.00 sec 13.5 MBytes 113 Mbits/sec 1291 27.3 KBytes
[ 5] 3.00-4.00 sec 13.5 MBytes 114 Mbits/sec 1242 34.5 KBytes
[ 5] 4.00-5.00 sec 13.5 MBytes 113 Mbits/sec 1302 25.8 KBytes
[ 5] 5.00-6.00 sec 13.6 MBytes 114 Mbits/sec 1249 27.3 KBytes
[ 5] 6.00-7.00 sec 13.4 MBytes 113 Mbits/sec 1285 21.6 KBytes
[ 5] 7.00-8.00 sec 13.5 MBytes 113 Mbits/sec 1238 33.0 KBytes
[ 5] 8.00-9.00 sec 13.6 MBytes 114 Mbits/sec 1260 31.6 KBytes
[ 5] 9.00-10.00 sec 13.5 MBytes 113 Mbits/sec 1256 25.9 KBytes
[ 5] 10.00-10.84 sec 11.3 MBytes 112 Mbits/sec 1101 18.8 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 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.
>> . . .
>>
>> Very asymmetric: send relatively fast, receive relatively slow.
Not after the above problem avoidance: now both relatively slow
for hw.usb.xhci.use_polling=1 use.
>> I've not tried hw.usb.xhci.use_polling=1 in any other context. So,
>> for all I know, the results of using such could be expected.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-current
mailing list