From owner-freebsd-ppc@freebsd.org Mon Feb 1 21:34:52 2021 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B11E4537BB6 for ; Mon, 1 Feb 2021 21:34:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DV1SC4wF7z3GFQ for ; Mon, 1 Feb 2021 21:34:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612215289; bh=ONoTHptmSZfDizFclFIS5EvEstnKEr8TJZKCDgMoDqk=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=bQU+r73kfqCaW8fZ6dzGKmFjxjc94Ij0qpMVhFC0mGL6X4qwPBpi9luhgRKZqCHNXtygBX9GiKaEgHLrXbNfpdqx0J+zZOjuJRaJFPMylCuhQmXTsxoY032Wa/6jdEGw/UNXWXuIcVLIc3m1s/4/yqWiS3dqd2cRopEih2EQ8l7DbzJ84JxXQiHt8DL2IvUnoi3zJ8SfMpxYfOJFnd+o5T9JtXdT5tGn15YsZRT+k0t005orA0vNwC2TercpgGn8cyAhv8VpCMQPM5g6KN+RieFA+WqJj5we37Aaf43IVeas9Yc43+HBZpWOHMKvBdowQrGturqsV36et4zFw6bS5g== X-YMail-OSG: pcpAFXIVM1mHkP1lUvnd_TSEu8RbY_KAr6n2BKQC_NfsrnRPSU8cfrxGBEvw3uF 5GILMSalum.pwxkL8JB_O5XIBzxD.tNZA31IMau3cUNDvn8heMtBas7hI7g.1yvdWeicMlj.8qia d.VwxnacepEfTV6vTWboinG2DHQYaCDoSzebssEV4zkJieKWts.4GKw18cuKLoneZ5E_Cu7cWvMY vn44FuEOAS3uHARGb7Fo648AU_nnxnbmToXx1ZZbaIA8WQ.fMSeL5JCA7IBAztnWsMITYnt6yVIR 7iFGrQxSnodeDeObWAKMWyRL3mB83tCBh629zuXs4a5zDdMKN8ZLoNo9OP4EEg1mLFCdhjATKgqF KE9wToldOt0p1X_UhEn5A1ksQek.WkZItfD5uw5iCpABouOxnHKBMYjla0s.HvFLNMoPLOuCKFIZ bbqZgFbv.gYLzIfOZcgt_b02NI7F_1JT5XLoRIJHiKo.tBwNQ_6lDb0zuVT8AtraAthms9Bo0Fa. okP_yhHgG2IFlHCnidjetE6Zh_nLCbZHRolBXn7rfKKhde30QKQr37.RNsZiAa7Nnqj6TFf7T9YF MuTQ2UH2Z3NKYGXYCV01WkiJCIzig7RDYf44PhNcEtOHc2A5NJUScBQeAV7psbUfd6OfZ0m_eiGy MwRHq4FX.q8KocMnK1wzaDyAl2VAfRCwEhuRhBtR1oRWGfOoCqS1SgME9liT1Bn8IC2QT.Jrjalq Qzc.02ofYpMwalncthOn3S_e3x8n5Qi9na6VEgfAJ6kfRP52Hp1Yjd6SMX7fzaLybGM46rjA.CBe I6TbtWpvDyHjB3HwmQEtnV3W9K1SVX1Vq0wqZxgc3yo.WxlZ9fMSftxXeOJXKYAZ7UGx0n6QIPTu QaM3Iib0ddIQGdqBdgZX.JgblUrLs3_A.AYmHG7WkFjfnodEYMtqh3SO3Nyrw_JTtZ5MdGl8iOMP Ce5lbBfEk_pIf2Ie7NXQ8O8I_S7d0kA1GmgHg44PLV7NIBgOU9aUIQkDobA3iLBCQjgQOJ0oFHSI 5WZjU8TrQosuN2NOxSxIQ35_rFg_HI2ARDrhtmrAuTZ3xwW3O.Ko_fJSVQuOh9cNL3TnkcnCtyKp 8c84E0ZhJgIXh5ge67qUQRjAAVO4N8Umfrvd0Bjsij3MqK9ksCjiINOz4ZEyVUjSfiFkixMV3pTX QGUTsfc91AJfsxPWYaVUUy90qSApgXrLPL9_XkuvB8etm.puak9CZU7hMNswC8XK7GPQu5EAoEg4 6_WV5USpH3.7YzFsJa8IXFNG9z0nkIq_ErmNEKnKVQE6zSxnHoPeIyzGwrAe5ywtcHoT7xtrLRFX OO1IKFR8ApHmkU0M7jhUv8x2BZCEW6ODg5FqEpbvKeAOs5cZ6nEOmI3n4AmZGgxRWo6OTNK9gx1Y Aav4hjxlcypq0bbvU2bLxV4_Yb9cPxAKg2_IBqQ0WoRxFB6moGVaCCFBo431.g9y6icWJQ8I7BxK SKIMik4ugc5Omhnjb95O6XFcy.hxrR0vxpgF5DJqUmHzPADDhGL4XBXCxhatBDcbZjZ__tlQ1pzE EwG3P0WKo8GgylLAiYtOPK0PCNG2aeCIo2nSIaGbANvJNir099WKzKnVQheOK8Q.eusnt6DnZ1k5 0JCX2p_SVW_fxooHXA8zHpwaTQRFjMPq_JWjwCyKLYakevUG8KJgdi3vx5l1pR0Z_tph4FCtiig4 d1l1DYoJ3GRGxzl70QRJcQB8Fk2KOnZ6Vka7Zbl_j5WQ.5rjtKgbKpbXrzj2.1P6IniFnOhkC0fs js7zWz3HQNLCwlhoeb_Qb6WIWxBObIYEsnPNE0Jih15Y75q66wJ9INfX_Ug6iOI9BtCAQ9o9tlj9 0OLyFbTqZjls.yKIK839zpK5_cMPzMTjXYthLcfYLXVZvCY0B3kCOOCsmAVezM8rQLzmSGQVaOr7 wqichahYH30X8iuyZ0mCkV2Nhsnd3.LeIjsHmETNILfv1vNE.swh9YtYUE6CzuVXJlT_9nYnI1Lk grqiT3EBOUvafjXYAM1cA6fIO0JbNJhsvaJx6ak__fw3NpRQFBjVyCeDas5Il0oBgDJQWQITzOn1 MyVEbXOxOsf2PYNc0AXwWircGT2eurrRcq9CZVFK4xLWV3tyrGXvCfQqYi7ke806OXP8TlpnTyPf 0SRRLvCSf2BjGw.QKxMslY_rI0ltV.aAYv2K4drywvLEeSDWR8x6vcPdaTSWGgsNhEcA.qbkJjF9 WWe7dwWIXsw2lxdAEmc7Y3e0st_tTxi7YfbJadAvjXSCh6iScXUvvceVTcJS00H496dGKtsQaebY 5qzjPxwqOGt_CYle1Ke8C86YlO1DDR7U03MoxRIpGO4IDHK_TtcgNgHgB8OyuErLvwPT7_vOAdkn bd5MbXI51aqUqYEnYSIkmHrnvnsalDKwPnh2tTktQiyk8ph2Hxl8tUAlcWxKAl3DM_..B.uZ2dtJ Kl2nYn4DIGOe3Php1Q.P_ERCz2ZLZJtzMNDB1fmjxvHnsPWssFFuQDINawe1YZfoob2Qpz56JivW PU1vk8RobW7Olj4GREYGB3gcFx9ykPIRhEK5hvdJG3SdpvYdphyNOgXF3jwsPT4j8zlXfGB_K8F8 MqBHfXQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Mon, 1 Feb 2021 21:34:49 +0000 Received: by smtp402.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f72139355311cba72726f67b2ad1f9d9; Mon, 01 Feb 2021 21:34:45 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Expected issue? Old PowerMac G5 [...] vs. USB [...] [RealTek EtherNet] devices (...) From: Mark Millard In-Reply-To: <20210201194702.GU31099@funkthat.com> Date: Mon, 1 Feb 2021 13:34:43 -0800 Cc: freebsd-ppc Content-Transfer-Encoding: quoted-printable Message-Id: <1C53A656-75ED-4E7C-9FB0-6C605BCDEC14@yahoo.com> References: <20210201194702.GU31099@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DV1SC4wF7z3GFQ X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.64.206:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.64.206:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ppc] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 21:34:52 -0000 On 2021-Feb-1, at 11:47, John-Mark Gurney 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 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: 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: at usbus2 >>> ure0 numa-domain 0 on uhub2 >>> ure0: on usbus2 >>> miibus2: numa-domain 0 on ure0 >>> rgephy0: PHY 0 on miibus2 >>> rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto >>> ue0: on ure0 >>> ue0: Ethernet address: ### >>> ue0: link state changed to DOWN >>>=20 >>> and: >>>=20 >>> ue0: flags=3D8843 metric 0 = mtu 1500 >>> = options=3D68009b >>> ether ### >>> inet 192.168.1.149 netmask 0xffffff00 broadcast 192.168.1.255 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> nd6 options=3D29 >>>=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: on usbus4 >> miibus1: numa-domain 0 on axge0 >> rgephy0: 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: 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)