Date: Mon, 1 Feb 2021 14:28:54 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-ppc <freebsd-ppc@freebsd.org> Subject: Re: Expected issue? Old PowerMac G5 [...] vs. USB [...] [RealTek EtherNet] devices (...) Message-ID: <20210201222854.GV31099@funkthat.com> In-Reply-To: <1C53A656-75ED-4E7C-9FB0-6C605BCDEC14@yahoo.com> References: <E79AA0EA-FAAE-412E-BB26-A66D9AB00AB8@yahoo.com> <EF3494BA-2B9C-43A5-931F-45313B3BDA7D@yahoo.com> <20210201194702.GU31099@funkthat.com> <1C53A656-75ED-4E7C-9FB0-6C605BCDEC14@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Millard wrote this message on Mon, Feb 01, 2021 at 13:34 -0800:
> 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.]
> >>
> >> 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.)
>
> 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).
I think that it should just work.. I haven't looked at the dcons code,
but IIRC, it should... If not, it should be easy to fix to make it
work..
> >> 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...
>
> 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.
Then why bother w/ xhci? Since that should apply only to USB3
controllers... If your mac isn't USB3 compatible, shouldn't be
detected/probed/used, and you should only have ehci...
This is why I was puzzled, tweaking xhci implies that the system is
USB3 capable...
(if xhci changes USB2 behavior, then it needs to be renamed)...
> > [...]
> >
> >> 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..
>
> 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.
Have you verified that it works w/ other operating systems on the Mac?
Could it be that the device itself isn't compatible w/ the USB2
controller on the mac?
Have you tried to add in a USB controller card and use that instead of
the onboard USB controller?
> > 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.
Yeah, I haven't heard of any, (though I've only worked on it for less
than a year)...
> 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.
Yeah, dcons is a good choice, and the good thing is that short of a
complete system bus crash, you'll be able to at least get the latest
logs off of the system...
> >> 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).
>
> The poudriere build finished but it was building 32-bit powerpc
> ports for FreeBSD:14. I've still got FreeBSD:13 ports for
> 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 .
+1
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210201222854.GV31099>