Date: Mon, 1 Feb 2021 13:34:43 -0800 From: Mark Millard <marklmi@yahoo.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: freebsd-ppc <freebsd-ppc@freebsd.org> Subject: Re: Expected issue? Old PowerMac G5 [...] vs. USB [...] [RealTek EtherNet] devices (...) Message-ID: <1C53A656-75ED-4E7C-9FB0-6C605BCDEC14@yahoo.com> In-Reply-To: <20210201194702.GU31099@funkthat.com> References: <E79AA0EA-FAAE-412E-BB26-A66D9AB00AB8@yahoo.com> <EF3494BA-2B9C-43A5-931F-45313B3BDA7D@yahoo.com> <20210201194702.GU31099@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Feb-1, at 11:47, John-Mark Gurney <jmg at funkthat.com> wrote: > Mark Millard wrote this message on Sun, Jan 31, 2021 at 13:45 -0800: >> [I provide some older context before the new material.] >>=20 >> On 2020-Jul-27, at 19:47, Mark Millard <marklmi at yahoo.com> wrote: >>=20 >>> 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). >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> For reference: >>=20 >> # ~/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 >>=20 >> 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.) I'm working on seeing if I can get Firewire/dcons based access going in hopes of getting more evidence that way. I hope that such can be done via a 32-bit PowerMac G4 against the 64-bit PowerMac G5: it looks like the only other G5 no longer can reliably boot (overheating that fast now). >> So I tried a non-RealTek USB3 capable EtherNet device, both >> with and without hw.usb.xhci.use_polling=3D1 : >>=20 >> 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 >>=20 >> So far it seems to be working just fine. I'm using it >> without hw.usb.xhci.use_polling=3D1 . >=20 > Is the axge a USB3 or USB3 device? The driver attached to both... The axge, like all my USB Ethernet devices, is USB3 capable but is supposed to support use in USB2 contexts. The PowerMac, of course, is old and only has USB2. > [...] >=20 >> So the crash appears to be RealTek-device specific in some >> way, not some sort of generic USB EtherNet problem. >=20 > 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.. Both the axge and the ure are USB3 capable devices that are supposed to support use in USB2 contexts. The axge works but the ure leads to the crash. > 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. Yep. I CC'd you mostly so if if any other similar reports came in that you would know of my context's prior failure. I am working on seeing if I can get Firewire/dcons to operate in hopes of getting some information about the crash. If I get that going and get some more information, I'll report it with you CC'd again. >> 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. >>=20 >>=20 >> 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). >=20 The poudriere build finished but it was building 32-bit powerpc ports for FreeBSD:14. I've still got FreeBSD:13 ports for=20 64-bit. If I end up needing a FreeBSD:14 gdb/kgdb I'll end up needing to do another round of port builds since no build for powerpc64 is running according to pkg-status.freebsd.org . The last build that completed normally was for FreeBSD:13 . =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?1C53A656-75ED-4E7C-9FB0-6C605BCDEC14>