Re: CFT: major update to if_ure (patch did not apply cleanly for head -r363510) (example PowerMac problem?)

From: Mark Millard <marklmi_at_yahoo.com>
Date: Mon, 27 Jul 2020 20:07:15 -0700
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)
> 
> # 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       
> [  5]   1.00-2.00   sec   112 MBytes   941 Mbits/sec   98    549 KBytes       
> [  5]   2.00-3.00   sec   113 MBytes   944 Mbits/sec   94   1.06 MBytes       
> [  5]   3.00-4.00   sec   112 MBytes   942 Mbits/sec   96    719 KBytes       
> [  5]   4.00-5.00   sec   112 MBytes   941 Mbits/sec   98    883 KBytes       
> [  5]   5.00-6.00   sec   112 MBytes   941 Mbits/sec   93    439 KBytes       
> [  5]   6.00-7.00   sec   112 MBytes   942 Mbits/sec   93    221 KBytes       
> [  5]   7.00-8.00   sec   112 MBytes   941 Mbits/sec   96    419 KBytes       
> [  5]   8.00-9.00   sec   112 MBytes   941 Mbits/sec   94    632 KBytes       
> [  5]   9.00-10.00  sec   112 MBytes   941 Mbits/sec   97    175 KBytes       
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ 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
> 
> 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                  
> [  5]   1.00-2.00   sec   112 MBytes   941 Mbits/sec                  
> [  5]   2.00-3.00   sec   112 MBytes   941 Mbits/sec                  
> [  5]   3.00-4.00   sec   112 MBytes   941 Mbits/sec                  
> [  5]   4.00-5.00   sec   112 MBytes   941 Mbits/sec                  
> [  5]   5.00-6.00   sec   112 MBytes   941 Mbits/sec                  
> [  5]   6.00-7.00   sec   112 MBytes   941 Mbits/sec                  
> [  5]   7.00-8.00   sec   112 MBytes   942 Mbits/sec                  
> [  5]   8.00-9.00   sec   112 MBytes   941 Mbits/sec                  
> [  5]   9.00-10.00  sec   112 MBytes   941 Mbits/sec                  
> [  5]  10.00-10.62  sec  69.8 MBytes   941 Mbits/sec                  
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bitrate
> [  5]   0.00-10.62  sec  1.10 GBytes   887 Mbits/sec                  receiver
> 
> 
> 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                  
> [  5]   1.00-2.00   sec  14.0 MBytes   118 Mbits/sec                  
> [  5]   2.00-3.00   sec  13.9 MBytes   117 Mbits/sec                  
> [  5]   3.00-4.00   sec  14.0 MBytes   118 Mbits/sec                  
> [  5]   4.00-5.00   sec  14.1 MBytes   118 Mbits/sec                  
> [  5]   5.00-6.00   sec  14.0 MBytes   118 Mbits/sec                  
> [  5]   6.00-7.00   sec  14.0 MBytes   117 Mbits/sec                  
> [  5]   7.00-8.00   sec  14.0 MBytes   118 Mbits/sec                  
> [  5]   8.00-9.00   sec  14.0 MBytes   117 Mbits/sec                  
> [  5]   9.00-10.00  sec  14.1 MBytes   118 Mbits/sec                  
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ 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
> 
> 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       
> [  5]   1.00-2.00   sec  14.1 MBytes   118 Mbits/sec  1386   25.9 KBytes       
> [  5]   2.00-3.00   sec  14.0 MBytes   118 Mbits/sec  1376   25.9 KBytes       
> [  5]   3.00-4.00   sec  14.0 MBytes   117 Mbits/sec  1397   20.2 KBytes       
> [  5]   4.00-5.00   sec  14.0 MBytes   118 Mbits/sec  1339   25.8 KBytes       
> [  5]   5.00-6.00   sec  14.0 MBytes   118 Mbits/sec  1357   27.3 KBytes       
> [  5]   6.00-7.00   sec  14.0 MBytes   118 Mbits/sec  1326   34.5 KBytes       
> [  5]   7.00-8.00   sec  14.0 MBytes   117 Mbits/sec  1388   17.2 KBytes       
> [  5]   8.00-9.00   sec  14.0 MBytes   118 Mbits/sec  1376   24.5 KBytes       
> [  5]   9.00-10.00  sec  14.0 MBytes   117 Mbits/sec  1386   25.8 KBytes       
> [  5]  10.00-10.86  sec  12.1 MBytes   118 Mbits/sec  1147   21.6 KBytes       
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bitrate         Retr
> [  5]   0.00-10.86  sec   140 MBytes   109 Mbits/sec  13654             sender
> 
> 
> iperf Done.
> 
> Very asymmetric: send relatively fast, receive relatively slow.
> 
> 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)
Received on Tue Jul 28 2020 - 01:07:20 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:24 UTC