From nobody Sat Aug 05 18:27:34 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 4RJB013pytz4mNCL for ; Sat, 5 Aug 2023 18:27:45 +0000 (UTC) (envelope-from meloun.michal@gmail.com) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RJB0032Lcz4Y6w for ; Sat, 5 Aug 2023 18:27:44 +0000 (UTC) (envelope-from meloun.michal@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=iYNDkWIu; spf=pass (mx1.freebsd.org: domain of meloun.michal@gmail.com designates 2607:f8b0:4864:20::629 as permitted sender) smtp.mailfrom=meloun.michal@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pl1-x629.google.com with SMTP id d9443c01a7336-1bbd03cb7c1so20722105ad.3 for ; Sat, 05 Aug 2023 11:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691260062; x=1691864862; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:reply-to:user-agent:mime-version:date :message-id:sender:from:to:cc:subject:date:message-id:reply-to; bh=UUPUqLkgQfCmpRfTSaq46jRiI82utcVw2Od0d+KS1ys=; b=iYNDkWIu97oBfA4ejnpXvkW4AA2oqTmmYDCwbBmUJ7Jm4e3+0IVYqRo6I7AVsR8Jix KyF/L7cVYRxC8TV2mFTv+uBDIgz0+JMaq0+HNTgXaIE7izuTK5y4ptSOTJnGGvFDSh0H 57huPCJo8/uXhoEtlGv7JISzLlBqXpLzXPC4BYQV93J0qevckVOzdjZLgYyZQULCoJLh vBlrfgHb18PM/N1CJSETvHJ2z4F9aVxC39CufzVtn2mwRHi6IKLzMM2k8TYFxIDUa2LJ lJB5KYx1MfH4YjQzPUl7hdNn2Wr9XP9TeQo3gEW110vaTvtWOdic+uUU+tKVbB9TJusa 9Mmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691260062; x=1691864862; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:reply-to:user-agent:mime-version:date :message-id:sender:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=UUPUqLkgQfCmpRfTSaq46jRiI82utcVw2Od0d+KS1ys=; b=V8xHVt8hUskuh0t5z62KF0dPy6rHj3ZmpZrawmEn+Dd2Wo6NRYCWXgbB2YXT00sjYI dr1B4Eo3dGSv3htUF/a5SrrEx0Tp+xOhJoYakg2bNAcokoHwIjPwI7j2KfL5EnpGLMJ+ rNgaPN2SdWiwOqZuoAvFGJGY/Ag65NO3TNhog1bbv6CrWwHrlnZPa1+rJDus37Gpamie U5GQklALOFhT0MAyPjWcsMeIpgP0BmugJnCzE58hJUtC9fJuR1qWorM7s9ID3sPHhtF4 cNTOwmJtdf7uUi3yUmaK+gJuOxBAAb36fXuGUs5yG1o5TF1f6B6Rl8snHZZEeQgHn9ca vxig== X-Gm-Message-State: AOJu0YwHyV65y9d/OzTWY8h3oA/Uchf7yUb3l8/bRwLBICVXh0QSiKy3 B21jQECVoI8uiTpyXSvC6+7LZQX79Is= X-Google-Smtp-Source: AGHT+IE6106RefprCctuHxaabwnTiZ1jVtt0vFL2Oj8trpF3q5/LCknh/duDWJP3xFwlkwXJNxn0Aw== X-Received: by 2002:a17:903:18d:b0:1ba:fe63:6616 with SMTP id z13-20020a170903018d00b001bafe636616mr3973955plg.6.1691260062222; Sat, 05 Aug 2023 11:27:42 -0700 (PDT) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id y9-20020a17090322c900b001b2069072ccsm3813058plg.18.2023.08.05.11.27.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Aug 2023 11:27:41 -0700 (PDT) Message-ID: <466233a6-f904-f2f4-ac9e-7476965e97c2@gmail.com> Date: Sat, 5 Aug 2023 20:27:34 +0200 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 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Reply-To: meloun.michal@gmail.com Subject: Re: A native armv7 panic during kyua runs: sys/netinet6/exthdr:exthdr -> Fatal kernel mode data abort: 'Alignment Fault' on read To: freebsd-arm@freebsd.org References: Content-Language: cs, en-US From: Michal Meloun In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-1.76 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_SPAM_SHORT(0.23)[0.235]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_REPLYTO(0.00)[meloun.michal@gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::629:from]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_REPLYTO(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: - X-Rspamd-Queue-Id: 4RJB0032Lcz4Y6w Hi Mark, can you please try a this patch? https://github.com/strejda/tegra/commit/bd4390c5f6a8b66b2fc83966d4fadb945a19dc23 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. Michal On 05.08.2023 8:11, Mark Millard wrote: > On Aug 4, 2023, at 20:58, Warner Losh wrote: > >> It might make sense to work up a patch that skips this test on armv7 after filing a bug (the usual way).... >> >> Warner > > Actually, looking at the backtrace, it seems I've previously > listed the same sort of backtrace structure in: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271759 > > comment 12. Hans Petter Selasky had been working on that > bugzilla entry. I'll add a note that this time I got it > with the built-in EtherNet instead of the dongle used > previously --and that sys/netinet6/exthdr:exthdr is a > way of producing the panic. [Done.] > > In /usr/main-src/tests/sys/netinet6/exthdr.sh , commenting > out one line would disable the specific test (leading > whitespace might not be preserved below): > > atf_init_test_cases() > { > > # atf_add_test_case "exthdr" > } > > [FYI: All my kyua activity has been for FreeBSD main, > generally targeting contexts with some armv7 code > involved. It is associated with my having been an > tester of early lib32 drafts.] > > I already have another commented out line for an armv7 > panic (leading whitespace might not be preserved): > > # git -C /usr/main-src/ diff tests/sys/net/ > diff --git a/tests/sys/net/if_bridge_test.sh b/tests/sys/net/if_bridge_test.sh > index eb3a792df449..dcdac75103cd 100755 > --- a/tests/sys/net/if_bridge_test.sh > +++ b/tests/sys/net/if_bridge_test.sh > @@ -675,7 +675,7 @@ atf_init_test_cases() > atf_add_test_case "delete_with_members" > atf_add_test_case "mac_conflict" > atf_add_test_case "stp_validation" > - atf_add_test_case "gif" > +# atf_add_test_case "gif" > atf_add_test_case "mtu" > atf_add_test_case "vlan" > } > > In the original discovery, having if_bridge.ko already loaded was > important to getting the "gif" panic. > > But I've not yet put effort into isolating a cleaner/simpler test > than I got the failure with. Nor have a done a range of comparisons > of differing contexts yet. > > There are other armv7 related issues, one in particular > being: > > A) All the long timeouts [300s+] are for *.py style tests. (Lots of > these.) > > B) All the *.py style tests that do not have long timeout have one of: > > -> skipped: comment me to run the test > -> skipped: Current architecture 'armv7' not supported > __test_cases_list__ -> broken: Test program did not exit cleanly > __test_cases_list__ -> broken: Test case list wrote to stderr > > The are about 10 of the "comment me" ones and 1 each of the other > (B) ones, if I remember right. > > In other words, basically all the *.py based tests are broken or > skipped as kyua classifies things. > > I've no clue yet if (A) is tied to the ports': > > cryptography/hazmat/bindings/_openssl.abi3.so > > openssl 3 incompatibility or not. But I've only seen the > issue in armv7 contexts so far. > > I've spent time today on this issue but have made no progress > on identifying what leads to the kdump/truss-output being as > it is. > > If the *.py tests were working, I'd not be surprised to then > find more armv7 panics than is now possible via the kyua tests. > >> On Fri, Aug 4, 2023 at 12:59 AM Mark Millard wrote: >> While discovered via an attempted overall kyua run, the following is >> sufficient to get the crash in my native armv7 context: >> >> # /usr/bin/kyua test -k /usr/tests/Kyuafile sys/netinet6/exthdr:exthdr >> sys/netinet6/exthdr:exthdr -> Fatal kernel mode data abort: 'Alignment Fault' on read >> trapframe: 0xdfb97aa0 >> FSR=00000001, FAR=db43ab76, spsr=60000013 >> r0 =dfedd000, r1 =dfb97b34, r2 =00000000, r3 =00000000 >> r4 =00000000, r5 =00000000, r6 =db43ab76, r7 =db43ab66 >> r8 =c096383c, r9 =00000000, r10=db132400, r11=dfb97b60 >> r12=00000000, ssp=dfb97b30, slr=c0b4e2c0, pc =c04e6b70 >> >> panic: Fatal abort >> cpuid = 0 >> time = 1691131498 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self >> pc = 0xc065f414 lr = 0xc007db80 (db_trace_self_wrapper+0x30) >> sp = 0xdfb97858 fp = 0xdfb97970 >> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >> pc = 0xc007db80 lr = 0xc031a834 (vpanic+0x140) >> sp = 0xdfb97978 fp = 0xdfb97998 >> r4 = 0x00000100 r5 = 0x00000000 >> r6 = 0xc07c369a r7 = 0xc0b32e58 >> vpanic() at vpanic+0x140 >> pc = 0xc031a834 lr = 0xc031a6f4 (vpanic) >> sp = 0xdfb979a0 fp = 0xdfb979a4 >> r4 = 0xdfb97aa0 r5 = 0x00000013 >> r6 = 0xdb43ab76 r7 = 0x00000001 >> r8 = 0x00000001 r9 = 0xdfedd000 >> r10 = 0xdb43ab76 >> vpanic() at vpanic >> pc = 0xc031a6f4 lr = 0xc06849dc (abort_align) >> sp = 0xdfb979ac fp = 0xdfb979d8 >> r4 = 0x00000001 r5 = 0x00000001 >> r6 = 0xdfedd000 r7 = 0xdb43ab76 >> r8 = 0xdfb979a4 r9 = 0xc031a6f4 >> r10 = 0xdfb979ac >> abort_align() at abort_align >> pc = 0xc06849dc lr = 0xc0684a50 (abort_align+0x74) >> sp = 0xdfb979e0 fp = 0xdfb979f8 >> r4 = 0x00000013 r10 = 0xdb43ab76 >> abort_align() at abort_align+0x74 >> pc = 0xc0684a50 lr = 0xc06846a8 (abort_handler+0x45c) >> sp = 0xdfb97a00 fp = 0xdfb97a98 >> r4 = 0x00000000 r10 = 0xdb43ab76 >> abort_handler() at abort_handler+0x45c >> pc = 0xc06846a8 lr = 0xc0661cc8 (exception_exit) >> sp = 0xdfb97aa0 fp = 0xdfb97b60 >> r4 = 0x00000000 r5 = 0x00000000 >> r6 = 0xdb43ab76 r7 = 0xdb43ab66 >> r8 = 0xc096383c r9 = 0x00000000 >> r10 = 0xdb132400 >> exception_exit() at exception_exit >> pc = 0xc0661cc8 lr = 0xc0b4e2c0 (__pcpu) >> sp = 0xdfb97b30 fp = 0xdfb97b60 >> r0 = 0xdfedd000 r1 = 0xdfb97b34 >> r2 = 0x00000000 r3 = 0x00000000 >> r4 = 0x00000000 r5 = 0x00000000 >> r6 = 0xdb43ab76 r7 = 0xdb43ab66 >> r8 = 0xc096383c r9 = 0x00000000 >> r10 = 0xdb132400 r12 = 0x00000000 >> in6ifa_ifwithaddr() at in6ifa_ifwithaddr+0x30 >> pc = 0xc04e6b70 lr = 0xc04f9030 (ip6_input+0xd38) >> sp = 0xdfb97b68 fp = 0xdfb97c28 >> r4 = 0xdb43ab76 r5 = 0xdb43ab5e >> r6 = 0x00000000 r7 = 0xdb43ab66 >> ip6_input() at ip6_input+0xd38 >> pc = 0xc04f9030 lr = 0xc046d66c (netisr_dispatch_src+0xf8) >> sp = 0xdfb97c30 fp = 0xdfb97c58 >> r4 = 0xdb43ab00 r5 = 0x00000006 >> r6 = 0x00000007 r7 = 0xc0b49d50 >> r8 = 0xdafea0c0 r9 = 0xdb43ab00 >> r10 = 0x00000086 >> netisr_dispatch_src() at netisr_dispatch_src+0xf8 >> pc = 0xc046d66c lr = 0xc04641b0 (ether_demux+0x18c) >> sp = 0xdfb97c60 fp = 0xdfb97c78 >> r4 = 0x00000006 r5 = 0x00001201 >> r6 = 0xdb132400 r7 = 0x000000ff >> r8 = 0xdafea0c0 r9 = 0xdb43ab00 >> r10 = 0x00000086 >> ether_demux() at ether_demux+0x18c >> pc = 0xc04641b0 lr = 0xc0465880 (ether_nh_input+0x490) >> sp = 0xdfb97c80 fp = 0xdfb97ce0 >> r4 = 0xdb132400 r5 = 0xdb43ab00 >> r6 = 0xdb43ab50 r10 = 0x00000086 >> ether_nh_input() at ether_nh_input+0x490 >> pc = 0xc0465880 lr = 0xc046d66c (netisr_dispatch_src+0xf8) >> sp = 0xdfb97ce8 fp = 0xdfb97d10 >> r4 = 0xdb43ab00 r5 = 0x00000005 >> r6 = 0x0000000c r7 = 0xc0b49d30 >> r8 = 0xdafea0c0 r9 = 0xdb43ab00 >> r10 = 0xc098d18f >> netisr_dispatch_src() at netisr_dispatch_src+0xf8 >> pc = 0xc046d66c lr = 0xc04645c4 (ether_input+0x50) >> sp = 0xdfb97d18 fp = 0xdfb97d48 >> r4 = 0xdb43ab00 r5 = 0x00000000 >> r6 = 0x00008803 r7 = 0x00000000 >> r8 = 0xdafea0c0 r9 = 0xdb43ab00 >> r10 = 0xc098d18f >> ether_input() at ether_input+0x50 >> pc = 0xc04645c4 lr = 0xdffb3f08 ($a.10+0x108) >> sp = 0xdfb97d50 fp = 0xdfb97d78 >> r4 = 0xdb132400 r5 = 0xdaff8b00 >> r6 = 0xdaff8b10 r7 = 0x00000000 >> r8 = 0x00000000 r10 = 0xc098d18f >> $a.10() at $a.10+0x108 >> pc = 0xdffb3f08 lr = 0xc038cb2c (taskqueue_run_locked+0x1c4) >> sp = 0xdfb97d80 fp = 0xdfb97dd8 >> r4 = 0xe0145100 r5 = 0xdaff8b2c >> r6 = 0xe0145150 r7 = 0x00000001 >> r8 = 0x00000000 r9 = 0xdfb97d90 >> r10 = 0x00000001 >> taskqueue_run_locked() at taskqueue_run_locked+0x1c4 >> pc = 0xc038cb2c lr = 0xc038e4e4 (taskqueue_thread_loop+0x1b0) >> sp = 0xdfb97de0 fp = 0xdfb97e10 >> r4 = 0xe0145100 r5 = 0xe0145140 >> r6 = 0xc07af4c4 r7 = 0x00000000 >> r8 = 0xc098d18f r9 = 0x00000100 >> r10 = 0xc0b228a0 >> taskqueue_thread_loop() at taskqueue_thread_loop+0x1b0 >> pc = 0xc038e4e4 lr = 0xc02cdf0c (fork_exit+0xc0) >> sp = 0xdfb97e18 fp = 0xdfb97e38 >> r4 = 0xdfedd000 r5 = 0xc0b224e0 >> r6 = 0xc038e334 r7 = 0xdffc4f54 >> r8 = 0xdfb97e40 r9 = 0xc098d191 >> fork_exit() at fork_exit+0xc0 >> pc = 0xc02cdf0c lr = 0xc0661c5c (swi_exit) >> sp = 0xdfb97e40 fp = 0x00000000 >> r4 = 0xc038e334 r5 = 0xdffc4f54 >> r6 = 0xc0b45d84 r7 = 0xd73bcba0 >> r8 = 0x00000001 r10 = 0xc0b228a0 >> swi_exit() at swi_exit >> pc = 0xc0661c5c lr = 0xc0661c5c (swi_exit) >> sp = 0xdfb97e40 fp = 0x00000000 >> KDB: enter: panic >> [ thread pid 0 tid 100230 ] >> >> For reference: >> >> # uname -apKU >> FreeBSD OPiP2E-RPi2v1p1 14.0-CURRENT FreeBSD 14.0-CURRENT armv7 1400093 #6 main-n264334-215bab7924f6-dirty: Tue Jul 25 23:11:39 PDT 2023 root@CA72-16Gp-ZFS:/usr/obj/BUILDs/main-CA7-nodbg-clang/usr/main-src/arm.armv7/sys/GENERIC-NODBG-CA7 arm armv7 1400093 1400093 >> >> The OrangePi+ 2Ed was the type of system booted and tested. >> > > > === > Mark Millard > marklmi at yahoo.com > >