Re: Expected issue? Old PowerMac G5 [...] vs. USB [...] [RealTek EtherNet] devices (...)

Mark Millard wrote this message on Sun, Jan 31, 2021 at 13:45 -0800:
> [I provide some older context before the new material.]
> 
> On 2020-Jul-27, at 19:47, Mark Millard <marklmi at yahoo.com> wrote:
> 
> > Context: head -r363590 based context, non-debug build.
> > 
> > Using a couple of USB EtherNet devices (with different
> > chip set families from different companies), I get
> > the like of:
> > 
> > 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
> > 
> > when I plug in the device. The one way I've found to avoid that
> > is to boot using:
> > 
> > hw.usb.xhci.use_polling=1
> > 
> > but this appears to have large performance consequences for
> > receiving data over the device.
> > 
> > (The only reason I've tried this on a PowerMac G5 is as a test
> > for a Realtek driver update that John-Mark Gurney has produced
> > and requested testing of: PowerPC is the only Big Endian type
> > of context that I have access to. Going the other way, the only
> > powerpc families that I have access to are in old PowerMacs.
> > The above is not limited to Realtek chipsets.)
> > 
> > With the forced polling I get (for the  device I originally
> > intended to test with):
> > 
> > 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>
> > 
> > I will note that the USB device is USB3 capable but supports
> > use on USB2 as well. This was also true of the other device
> > that I tried that had a different chip set.
> > 
> > 
> > I do not know if some other types of USB devices also have
> > such problems on old PowerMacs (or powerpc64 more generally).
> 
> Newer context: Both old 2-socke-t/2-cores-each PowerMac G5s
> now suffer Heat Deaths when used for much. So this is tied
> to attempting to switch to another variant of the G5s that
> happens to be accessible. But I think the end result is
> reporting a new problem.
> 
> Well, I tried using the 2-socket/1-core-each PowerMac G5 but
> discovered that its gem0 gets regular device timeouts after
> a while, making EtherNet useless via gem0. This lead to again
> looking at using USB based EtherNet on this old PowerMac G5.
> 
> So I tried plugging one of the RealTek USB ethernet devices,
> with hw.usb.xhci.use_polling=1 in place at boot. The result
> was an immediate, slient death in that the console display
> stopped responding.
> 
> For reference:
> 
> # ~/fbsd-based-on-what-freebsd-main.sh 
> merge-base: 3f43ada98c89bce5ae416e203ba0e81595a5cd88
> merge-base: CommitDate: 2021-01-29 19:46:24 +0000
> e124d7d5fc88 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context.
> 3f43ada98c89 (freebsd/main, freebsd/HEAD, pure-src, main) Catch up with 6edfd179c86: mechanically rename IFCAP_NOMAP to IFCAP_MEXTPG.
> FreeBSD FBSDG5L2 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n244523-e124d7d5fc88 GENERIC64vtsc-NODBG  powerpc powerpc64 1400003 1400003
> 
> I doubt that plugging in a USB "RTL8251/8153 1000BASE-T
> media interface" should crash the PowerMac G5, but it
> does, and does so in a way that leaves no access to find
> evidence with. (I've no serial console for any PowerMac.)
> 
> 
> So I tried a non-RealTek USB3 capable EtherNet device, both
> with and without hw.usb.xhci.use_polling=1 :
> 
> axge0 numa-domain 0 on uhub4
> axge0: <NetworkInterface> on usbus4
> miibus1: <MII bus> numa-domain 0 on axge0
> rgephy0: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 3 on miibus1
> rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
> ue0: <USB Ethernet> on axge0
> ue0: Ethernet address: 00:05:1b:af:1a:21
> ue0: link state changed to DOWN
> ue0: link state changed to UP
> 
> So far it seems to be working just fine. I'm using it
> without hw.usb.xhci.use_polling=1 .

Is the axge a USB3 or USB3 device?  The driver attached to both...

[...]

> So the crash appears to be RealTek-device specific in some
> way, not some sort of generic USB EtherNet problem.

My guess is that there's a USB3 issue..  Because an endianness
issue in the driver would cause it to not attach or misbehave, it should
not cause a hard lock..

I assume it was a hard lock enough that you were unable to break into
ddb?  Without more information, it will be impossible for me to debug
this.

> I've no clue if the gem0 issue is HW, SW, or some mix, but
> its failure is not as big of a deal as crashing just from
> plugging in a USB device.
> 
> 
> Note: The G5 is doing a poudriere-based build that may take it
> days, with llvm building yet to start. I have 2 ssh sessions
> going, one session is running my variant of top and the other
> is running poudriere(-devel).

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[email protected]"