Date: Sun, 31 Jan 2021 13:45:36 -0800 From: Mark Millard <marklmi@yahoo.com> To: freebsd-ppc <freebsd-ppc@freebsd.org> Cc: John-Mark Gurney <jmg@funkthat.com> Subject: Re: Expected issue? Old PowerMac G5 [...] vs. USB [...] [RealTek EtherNet] devices (...) Message-ID: <EF3494BA-2B9C-43A5-931F-45313B3BDA7D@yahoo.com> In-Reply-To: <E79AA0EA-FAAE-412E-BB26-A66D9AB00AB8@yahoo.com> References: <E79AA0EA-FAAE-412E-BB26-A66D9AB00AB8@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[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. >=20 > Using a couple of USB EtherNet devices (with different > chip set families from different companies), I get > the like of: >=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 > when I plug in the device. The one way I've found to avoid that > is to boot using: >=20 > hw.usb.xhci.use_polling=3D1 >=20 > but this appears to have large performance consequences for > receiving data over the device. >=20 > (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.) >=20 > With the forced polling I get (for the device I originally > intended to test with): >=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 > 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. >=20 >=20 > 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=3D1 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=20 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=3D1 : 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=3D1 . For reference (with some text replaced): ue0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu = 1500 options=3D8000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE> ether ### inet6 ###%ue0 prefixlen 64 scopeid 0x4 inet6 ### prefixlen 64 autoconf inet 192.168.1.160 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=3D23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> So the crash appears to be RealTek-device specific in some way, not some sort of generic USB EtherNet problem. 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). =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?EF3494BA-2B9C-43A5-931F-45313B3BDA7D>