From nobody Sat Aug 05 23:06:29 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RJJB04h1tz4Tsph for ; Sat, 5 Aug 2023 23:06:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RJJ9y4v3hz3YM6 for ; Sat, 5 Aug 2023 23:06:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=S6efZuh5; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691276804; bh=PjKnN5CcNdsF0joDre06TUSLyCBcXWvprQTs+StSd4c=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=S6efZuh5L67v0EAzKGSgJ9bUXKLMKbntEIj09U77Ou4NbB8MhW12mm5SOFK4JWI8m908DuAaXOr1pM7Z/ugsZMYAziz50TxXElOphrMbC625Mk2Jn48WEYuxEU55EQCKcQTkf0mqSftrAjaHSRoLBdCK3ZZntcDo/Spum70LJ6h1PsAsOlbX16muhimuNe8B8HTz9bhSx68Bde3mmlgOKbWeDckabSxnJCXdHiv8Ehg4CaAFtOlkiils8S7P9+JKItcCBm7dw6Vv194l2jjdrZ1xFPx8FZXC3c3MvC15YbxfULNz4CGhjBgf2M/SjjtuFX5H/IIqO1BNKrmEq3EaRQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691276804; bh=73C3mKVwdAGiQe3w2aeCn8kNbn1sWSyTrD0MerQpa6T=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=oE7uJU5Q7DtftHMEG/PX55jvantM5Audd1n2FWloW4isCbA40zyww4mtjMIGIlYfuF5iz8o5e1T8f0T913rv+n1sqbu8de8pUdUhOL6/uz2VSm40+J+OBK6PAjZvL2ZnWWDzvFQsY3ZDfki6PDz8OvJ1y+uzAMOrrTy+Y9gNCuNyG1d+vtZWw0cSIaT7VqReG9ILXbLZysAlswXdOdd0nW17mvUW+9zRbRcxO8wB6tc7Qe9NouRoJpmZV9XSsF+Cf6NFWRxMMWwwOGpr4M+/1NT42EwZelaG38NyQYoMLLeDfwgMe7F3Sa71ogNDNuTBatL5WWp7EAARe5BQZyDYBw== X-YMail-OSG: nRZAZcEVM1nn67a.JFhnPJ2PRUxhkzMaZJAf6anxWzUHcak2Da6G.X_P4JQKHwm TDb44Dxu8LHsamQtaEvG83E_1EXfVGBx_oSCsBBjs7NdFQS4g09bUBEEP5uhYI1DBZQgJ3TYRVKE AX0LAxQlq.PSY7r7QW5NAFdEwMUYogvO_U9B2rMVxU5EpIfHzfhs4Iac.DMHPTj3lZoIg8BFf68q rdVGXuAJ7ipBAkjzRFKPIY3wql6VfhMWXrSvVrs0bMcdsztZUqqEDjmu_eRyYy4zHNuhc6xTy9hU ymA6A4tf5cHkBTgv3RlgNruGDZVsdCrclwe0_wB5HiQZFnb3JjZe_I5EIC.OcZsxbvJUMsEc55BW HbPrbPthCFkNJWcTmlCClOWO8S6xbdamB7nHsaQptLxepdWiXfDjuwMDhaQVDEfRI2VBUVnpCIoF 7NegKxszUku9HVXduLonj.SIyqRCBV6fQF89x0bxZPFUZ5X.f_WOVHuVmLajhmFDT4hA6RRG0KW_ FKswLn76BQbtPRmxkfo108NqHVR_cPIvJUZHEJX3Pj.rL_Fb_MYUJAAto28noxOfadp69js2L53L k.q9dKB_Fn5alkKe5UMIDbBylphuFkZ_jSNIFRgps7QofLSFwS8lRt7l4_hFKwGARTLaluSSRW7Z 0QdmjCvm4bXJazDiTq3syLGLa.lYlasIbRZ8QSQWHNqELXgl3GPFaS09nUfKUuIwY3s3ivpJ5CIs SW2o12yIib_wyURedGGjCZ4y2eRIkbQtsuHzebv2ZKPSnEoac2Usn0gp8yitnGGVn.4mv29lhmb8 wZ9iWJr_3F.ZX5i.XK43DobpemODUthi8c9PESWipZkXIya54DQ3nwnX5zYYq2bH6RWsSXQy8JaZ dAOX6eVn.bvZ2vZiTE2fq9BGnBIcLwYCnnGezYYdDoel76oJtUR_7XYJ8LtQ2BFrB2DXpXc7GePm Ov0KIKR_Cv0yJygWG03g6wMhd77LQFS0SoXedONI68j6NW3cmPbgPLeoYV4MOkOP52eRS_Lu_.oE 8RekOjS90OVjsP1UDUvExRWk8q8sFq1rLwZp.DICNi4WYHTYUTvvKH3dWqoPdgGt0zDMUxS6uj7l M4LuWPT7SQDdHRgAQL6d8yxqHXsxCvK163LTgLIdpNCoUZnc2v9bppo3VKws_Ice6CJ9IqhZa_ta HOptj3B9CnmeKrOPONGrRqnFbCfRZ.KE8eo7KdasLCt49hwPyEloaifeMHc9wyp9_vU9un.GptwS fg22Qt_MPN4_dBoJD5db7AMHGBU0tqfrOuSVAFulX.LBospVQDafP3BObG8QawVw30Pb6KKJlpQq j5McKrL95LdjQEXLAgDZLT4PZlNnzAwgbfavQ0WW0Vd4CHtC3GEiZULE4ZxFu.10rEb942_PHUgC OCqBpXvHqgWjQ956rEEtwiu32ghoFX0uqsAdSyREIUESWQEczMjZFI.avvuFkGqIZUohbwAkID7M We06Xs.ltSuh7u8Mfq23i3OseeMsP1wLtwe3KacedSsxBvUetNgVrlFXSOxG8czl.U8AK3LZLags 01MqoDJLxVJAAfcXUDNmMYJca7d_56262a2WVHE8xCK1UybuSjkw67kjrtDfZjfKiU4S4AOvCXFO LYTtqprdUNjOxxnrJQo400m_q5vlizAslJ6FfBuxsxakx06tY_WJkTnp7jTlwiAdJAZc4RASYZ7T OoPY9VxcEZqZj7Dgbe9Mp16EvDABwHwR.6xEYchgVMn.8Si.x23sO1UcjWMCTg5MB.Wt9.oYZ7o5 WfyHC7FtPAxCjKRgS8n.BV6v7oXRQ65yqAvAPguZuNyKr7akZJEFC_4pHfd4.3RHkeotxWzO0eSa 7hv0OmCkZgXjvsk08bPrNBL7yj4GjkCpZwqAGqlTEDyd9X3YWKTSycwy_J4.xRk.mduyCvLRwv1L QEcbjVvvOPksVY0Wc2li_ZcqBq3YksvCae1Y.covKGy8ZyuTpacvv1nkZ7TodCAIHOn1wtyZsBwQ yloUH.3y_TNDOp6Ls5dsfEdlhLslgWLuMaAsqOOJtOd7jZZ0ZD7zYrcwdIGnGUJOQ8T.NushpNtv ginPJjtrcXh._LG.VpVUy1SciVIStw.zyQgrZn7omoEPZTaCw6_MmAGrVAz03ROP4UQhCdm1E3vC y0O_p3Y_QM32v0Gihp_imF2CJUV3drnxZfTzTqm19DK70hzvj7JRJ45XcVp1WOaMdTRS_t6OzgZ. 5QmWZyN2xS8sPKsQVmR2_I2.6ZReT_9J8GiPyI3bULGv2j8iVzl4Yz9pOA3AW1p.Y7Xdgr8lEgs0 - X-Sonic-MF: X-Sonic-ID: c016e4ea-df23-4b37-bd99-9838f0ef2210 Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Aug 2023 23:06:44 +0000 Received: by hermes--production-gq1-7d844d8954-457wn (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c02069b1532b846a71e4de077fb5be59; Sat, 05 Aug 2023 23:06:40 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: A native armv7 panic during kyua runs: sys/netinet6/exthdr:exthdr -> Fatal kernel mode data abort: 'Alignment Fault' on read From: Mark Millard In-Reply-To: <6F3ED262-F0EA-4FCA-AEF1-CD785E44E068@yahoo.com> Date: Sat, 5 Aug 2023 16:06:29 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <466233a6-f904-f2f4-ac9e-7476965e97c2@gmail.com> <8CDB7543-E21C-47BC-AB18-52D24ED855ED@yahoo.com> <6F3ED262-F0EA-4FCA-AEF1-CD785E44E068@yahoo.com> To: meloun.michal@gmail.com X-Mailer: Apple Mail (2.3731.700.6) X-Spamd-Result: default: False [-2.42 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.918]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4RJJ9y4v3hz3YM6 On Aug 5, 2023, at 14:40, Mark Millard wrote: > On Aug 5, 2023, at 14:04, Mark Millard wrote: >=20 >> On Aug 5, 2023, at 11:27, Michal Meloun = wrote: >>=20 >>> Hi Mark, >>> can you please try a this patch? >>> = https://github.com/strejda/tegra/commit/bd4390c5f6a8b66b2fc83966d4fadb945a= 19dc23 >>=20 >> I'll take a stab at testing it. >>=20 >> But I'll note that description of the patch is somewhat odd: >>=20 >> QUOTE >> Pack IP structures directly used for access packet data. >> All structures used to access data in byte buffers shall be marked >> as packed. Otherwise, this is undefined behavior - formally on >> every platform. >> END QUOTE >>=20 >> __packed (and whatever it might be a macro for) is not part of >> any vintage of the C standard, not even as explicitly >> implementation defined nor as explicitly undefined. (C23's >> "attribute specifier sequence" notation use would give an >> implementation defined status as an understand, but not via >> explicit identification of the concept of packed in the standard.) >> As far as the language is concerned, there is no guarantee that >> a code generator will ensure to break things up into aligned >> accesses with assembly of the overall value if the members are >> not aligned in the first place, __packed or not. Nor does the >> language guarantee pack of padding in the layout for __packed. >>=20 >> Past that, it is toolchain specific if __packed would avoid >> unaligned accesses for simple member access notation bytes >> yet also avoid having pad bytes. We will see for this context. >> (My history suggests a lack of overall uniformity in the >> interpretations given to declaring struct's as packed --or >> analogous wording for other languages that are not explicit >> about it.) >>=20 >>> I'm sorry, but I don't have the time or energy to fully test it... I = only hope the actual patch is much easier than the one listed in = PR271759. >>=20 >=20 > [Older history deleted.] >=20 > No notable change in behavior, I'm afraid . . . >=20 > sys/netinet6/exthdr:exthdr -> =20 > Fatal kernel mode data abort: 'Alignment Fault' on read > trapframe: 0xc51fbaa0 > FSR=3D00000001, FAR=3Ddaed4476, spsr=3D60000013 > r0 =3Ddaf787c0, r1 =3Dc51fbb34, r2 =3D00000000, r3 =3D00000000 > r4 =3D00000000, r5 =3D00000000, r6 =3Ddaed4476, r7 =3Ddaed4466 > r8 =3Dc0965c3c, r9 =3D00000000, r10=3Ddb0e4400, r11=3Dc51fbb60 > r12=3D00000000, ssp=3Dc51fbb30, slr=3Dc0b524c0, pc =3Dc04e8e78 >=20 > panic: Fatal abort > cpuid =3D 1 > time =3D 1691270886 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc =3D 0xc0661824 lr =3D 0xc007db80 = (db_trace_self_wrapper+0x30) > sp =3D 0xc51fb858 fp =3D 0xc51fb970 > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc =3D 0xc007db80 lr =3D 0xc031a834 (vpanic+0x140) > sp =3D 0xc51fb978 fp =3D 0xc51fb998 > r4 =3D 0x00000100 r5 =3D 0x00000000 > r6 =3D 0xc07c5a9a r7 =3D 0xc0b36e58 > vpanic() at vpanic+0x140 > pc =3D 0xc031a834 lr =3D 0xc031a6f4 (vpanic) > sp =3D 0xc51fb9a0 fp =3D 0xc51fb9a4 > r4 =3D 0xc51fbaa0 r5 =3D 0x00000013 > r6 =3D 0xdaed4476 r7 =3D 0x00000001 > r8 =3D 0x00000001 r9 =3D 0xdaf787c0 > r10 =3D 0xdaed4476 > vpanic() at vpanic > pc =3D 0xc031a6f4 lr =3D 0xc0686ddc (abort_align) > sp =3D 0xc51fb9ac fp =3D 0xc51fb9d8 > r4 =3D 0x00000001 r5 =3D 0x00000001 > r6 =3D 0xdaf787c0 r7 =3D 0xdaed4476 > r8 =3D 0xc51fb9a4 r9 =3D 0xc031a6f4 > r10 =3D 0xc51fb9ac > abort_align() at abort_align > pc =3D 0xc0686ddc lr =3D 0xc0686e50 (abort_align+0x74) > sp =3D 0xc51fb9e0 fp =3D 0xc51fb9f8 > r4 =3D 0x00000013 r10 =3D 0xdaed4476 > abort_align() at abort_align+0x74 > pc =3D 0xc0686e50 lr =3D 0xc0686aa8 (abort_handler+0x45c) > sp =3D 0xc51fba00 fp =3D 0xc51fba98 > r4 =3D 0x00000000 r10 =3D 0xdaed4476 > abort_handler() at abort_handler+0x45c > pc =3D 0xc0686aa8 lr =3D 0xc06640d8 (exception_exit) > sp =3D 0xc51fbaa0 fp =3D 0xc51fbb60 > r4 =3D 0x00000000 r5 =3D 0x00000000 > r6 =3D 0xdaed4476 r7 =3D 0xdaed4466 > r8 =3D 0xc0965c3c r9 =3D 0x00000000 > r10 =3D 0xdb0e4400 > exception_exit() at exception_exit > pc =3D 0xc06640d8 lr =3D 0xc0b524c0 (__pcpu+0x200) > sp =3D 0xc51fbb30 fp =3D 0xc51fbb60 > r0 =3D 0xdaf787c0 r1 =3D 0xc51fbb34 > r2 =3D 0x00000000 r3 =3D 0x00000000 > r4 =3D 0x00000000 r5 =3D 0x00000000 > r6 =3D 0xdaed4476 r7 =3D 0xdaed4466 > r8 =3D 0xc0965c3c r9 =3D 0x00000000 > r10 =3D 0xdb0e4400 r12 =3D 0x00000000 > in6ifa_ifwithaddr() at in6ifa_ifwithaddr+0x30 > pc =3D 0xc04e8e78 lr =3D 0xc04fb338 (ip6_input+0xd38) > sp =3D 0xc51fbb68 fp =3D 0xc51fbc28 > r4 =3D 0xdaed4476 r5 =3D 0xdaed445e > r6 =3D 0x00000000 r7 =3D 0xdaed4466 > ip6_input() at ip6_input+0xd38 > pc =3D 0xc04fb338 lr =3D 0xc046d66c = (netisr_dispatch_src+0xf8) > sp =3D 0xc51fbc30 fp =3D 0xc51fbc58 > r4 =3D 0xdaed4400 r5 =3D 0x00000006 > r6 =3D 0x00000001 r7 =3D 0xc0b4dd50 > r8 =3D 0xdaf9d900 r9 =3D 0xdaed4400 > r10 =3D 0x00000086 > netisr_dispatch_src() at netisr_dispatch_src+0xf8 > pc =3D 0xc046d66c lr =3D 0xc04641b0 (ether_demux+0x18c) > sp =3D 0xc51fbc60 fp =3D 0xc51fbc78 > r4 =3D 0x00000006 r5 =3D 0x00001201 > r6 =3D 0xdb0e4400 r7 =3D 0x000000ff > r8 =3D 0xdaf9d900 r9 =3D 0xdaed4400 > r10 =3D 0x00000086 > ether_demux() at ether_demux+0x18c > pc =3D 0xc04641b0 lr =3D 0xc0465880 (ether_nh_input+0x490) > sp =3D 0xc51fbc80 fp =3D 0xc51fbce0 > r4 =3D 0xdb0e4400 r5 =3D 0xdaed4400 > r6 =3D 0xdaed4450 r10 =3D 0x00000086 > ether_nh_input() at ether_nh_input+0x490 > pc =3D 0xc0465880 lr =3D 0xc046d66c = (netisr_dispatch_src+0xf8) > sp =3D 0xc51fbce8 fp =3D 0xc51fbd10 > r4 =3D 0xdaed4400 r5 =3D 0x00000005 > r6 =3D 0x00000003 r7 =3D 0xc0b4dd30 > r8 =3D 0xdaf9d900 r9 =3D 0xdaed4400 > r10 =3D 0xc098f58f > netisr_dispatch_src() at netisr_dispatch_src+0xf8 > pc =3D 0xc046d66c lr =3D 0xc04645c4 (ether_input+0x50) > sp =3D 0xc51fbd18 fp =3D 0xc51fbd48 > r4 =3D 0xdaed4400 r5 =3D 0x00000000 > r6 =3D 0x00008803 r7 =3D 0x00000000 > r8 =3D 0xdaf9d900 r9 =3D 0xdaed4400 > r10 =3D 0xc098f58f > ether_input() at ether_input+0x50 > pc =3D 0xc04645c4 lr =3D 0xdffb3f08 ($a.10+0x108) > sp =3D 0xc51fbd50 fp =3D 0xc51fbd78 > r4 =3D 0xdb0e4400 r5 =3D 0xdaff4000 > r6 =3D 0xdaff4010 r7 =3D 0x00000000 > r8 =3D 0x00000000 r10 =3D 0xc098f58f > $a.10() at $a.10+0x108 > pc =3D 0xdffb3f08 lr =3D 0xc038cb2c = (taskqueue_run_locked+0x1c4) > sp =3D 0xc51fbd80 fp =3D 0xc51fbdd8 > r4 =3D 0xdaff2100 r5 =3D 0xdaff402c > r6 =3D 0xdaff2150 r7 =3D 0x00000001 > r8 =3D 0x00000000 r9 =3D 0xc51fbd90 > r10 =3D 0x00000001 > taskqueue_run_locked() at taskqueue_run_locked+0x1c4 > pc =3D 0xc038cb2c lr =3D 0xc038e4e4 = (taskqueue_thread_loop+0x1b0) > sp =3D 0xc51fbde0 fp =3D 0xc51fbe10 > r4 =3D 0xdaff2100 r5 =3D 0xdaff2140 > r6 =3D 0xc07b18c4 r7 =3D 0x00000000 > r8 =3D 0xc098f58f r9 =3D 0x00000100 > r10 =3D 0xc0b268a0 > taskqueue_thread_loop() at taskqueue_thread_loop+0x1b0 > pc =3D 0xc038e4e4 lr =3D 0xc02cdf0c (fork_exit+0xc0) > sp =3D 0xc51fbe18 fp =3D 0xc51fbe38 > r4 =3D 0xdaf787c0 r5 =3D 0xc0b264e0 > r6 =3D 0xc038e334 r7 =3D 0xdffc4f54 > r8 =3D 0xc51fbe40 r9 =3D 0xc098f591 > fork_exit() at fork_exit+0xc0 > pc =3D 0xc02cdf0c lr =3D 0xc066406c (swi_exit) > sp =3D 0xc51fbe40 fp =3D 0x00000000 > r4 =3D 0xc038e334 r5 =3D 0xdffc4f54 > r6 =3D 0xc0b48d84 r7 =3D 0xd73bd3e0 > r8 =3D 0x00000001 r10 =3D 0xc0b268a0 > swi_exit() at swi_exit > pc =3D 0xc066406c lr =3D 0xc066406c (swi_exit) > sp =3D 0xc51fbe40 fp =3D 0x00000000 > KDB: enter: panic > [ thread pid 0 tid 100226 ] >=20 >=20 > I've just restored the sources involved but still have > the .diff I that got via github. >=20 By the way, your request lead me to looking at my material in: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271759 some more. I've concluded it is not obvious to me if my OrangePi+2Ed comments end up being evidence of an independent issue vs. evidence of there being more than potential if_ure issues involved. I ended up adding Comment 35: Hmm. Getting the problem on the built-in Ethernet did not involve if_ure from what I can tell, looking at the dmsg -a output: . . . awg0: mem 0x1c30000-0x1c3ffff irq 27 on = simplebus0 miibus0: on awg0 rgephy0: PHY 0 on = miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow rgephy1: PHY 1 on = miibus0 rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow . . . Autoloading module: if_ure ure0 on uhub6 ure0: = on usbus7 miibus1: on ure0 rgephy2: PHY 0 on miibus1 rgephy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto ue0: on ure0 if_ure would only be involved with the dongle (ure0), for which no Ethernet cable was attached. So I'm unsure if what I've reported for the OrangePi+2Ed context overall is: A) An independent problem. vs. B) Evidence that the original problem involves more than just potential if_ure issues. =3D=3D=3D Mark Millard marklmi at yahoo.com