From nobody Sun Jul 30 04:54:55 2023 X-Original-To: freebsd-current@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 4RD8FF6MPDz4pkLb for ; Sun, 30 Jul 2023 04:55:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (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 4RD8FD3FNzz4JVv for ; Sun, 30 Jul 2023 04:55:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=sqZxPoaY; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.82 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=1690692909; bh=hJ4W5DARohQtXekRZZdF+LY1PVuj5tnLNAPVLA8Thxc=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=sqZxPoaYpg3u7Ma1zfQ2ya17DKX1pR+VAvPbPDHWXTYsFmL3fbYIUirFvdpfBxNKq1M2LiTM/p0WjKEZ1CenEBHfomThKcgprBscMlGcf8NZWgJ6bE7WsPCsR0CUZ5U2rxNEsgjq5KdRWA6282VE2TSc704qCUSedq5jrhrXVsDQYGk+uH/EKP9DGEKawtB9Ndktqh4HYIQQYiBkMYgaENe+o5r8evuaKT2o4RUMXLRPrU91HKTXc+HRqAysz5BIVoZfW1cB0dIm5pnAaKMnixWlg95Hs+0w7LHXXDd1rw9NkyzZ0LAAipYlVXgpJmPk3WC9U+DLrmRbFfkYeaPqRw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1690692909; bh=ukER8oLTWnpbQeEmFymtCU3fgi+LA1Qm6Z0D94DBfOX=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=TSTSQsFILCS+ikZAI4GjjbAEdga30KJBJHdyK4Y+cuCWY/QaVZSnu6yPs1/EhXqDXFAigu2Mot069n0yCydpJGzY8xADSeJbeBf/sQwyF4RIqnKzEgcDT7HLYnzrTiYRJ3hHlxljnSxia0aou5NVD+EfU9KYR93V7zutkrBf97Dz6nyQLLo1hvilqxF7XEnYIW9BJn4fJ01uPYsXQZTExa/2SgCfyyjA/MT2arwr2B56XRiENwJqR6MOiNbPiwEAyozCovWkyQezWKAl4S3jzzk6nTlb5yYvkojvQU2JdXQhYllh357I5wq/W8Izs9vStjAHcVFY9bKsBWULOtEVgg== X-YMail-OSG: iEet3YEVM1k9ZkEzgZILgi_GknOGJVPlQG8tHUcr2r5peVUPSGeF.gpG0Z6SZIA 5jjovtpw_1iH.8ynT6YIn.6ZRNX4RffKvpq88nwmlZ9FWs51_xL9TyzAr7wVh0i3YyBkGsIwW6l9 hnzufKEyO99ghIpnp_5CmQuGS6C49Z7E5kxzbMuQNOGZk2nkKcJCFxj04wqTTvVR9CXH112mPazG H1zsDSqIWEyoHFYVB2YeVjTdvu85Edn1mqwL_EKg8zhpMo6axz4DBw5lgFG8sJymN0Yc47uiTlth P9bZbKwT2HLjtC0HfQQ.VJyuVVVqm4Cp1Ge1BquLTvkms3HuvTti..8cdl_A849zdSDFnVvH49OX xqpI7Z_VlzLBxveC260RoaBz56JUPabsp.Wb.neFV.1y2FLtZKcQMZNy6cYdcEm7br0hS9sgcqk3 WlOY4v4pj8SuptSxvAUc2uP54PtoPpf4BAfU7NcskgBBKuvzhNx4OTE7rkpDvXsSNpC.yQFDyF.Q UIMd3OeVk8QTCJG0ttzEbGhmdX4DCCQPKJHO6RTbYr4RS0FW1eapZhziMWkC0BlkrsOIRJYmXtUM 3EOIFQh6HLBwKUfVF0WxR7z1jx.dsDTU0y80RbTh5TTMTGhVtGmdYIV58gqB5b8R6ISUu8rlnwVO rXmu3bHneTmc3whah1dS9BS0PMrnfMvv6B14d9BV7QT9tyw61qW9zyxxYb0404gtWYfss09l3EuQ nXKkUtcCIcizds7CXpc87hhWWjoRIMvA82ATdIqtqeRg0HTwbtxWXm_URm_4g59NToOjR.yYWP61 d6CbW07a.WNmzstt5P3kCNeouSw7BYKMMySLPXHghYrf..CVwNK57GMMvCqB_cy7NCPL4YSL2_I4 Z06GRpbSyDrDM6BQot2zjE2.B..nkhh5qkKJbEpLr5nuoKU_E6v.WUqbrTHhMsLizFR3mMhlPrN0 2m6f6gcHcb8o1JNw15bw.KnzV9vH3VzaxI5_ZJsirq3fcbts71VB4mvTPGxxJj05FAoNs4waVDBP HMv2mkaI.6BGkAhY6bH0CTwm3LQ_EIA7JogWpKl3UiWPQfeZ0jwvr0Xb9n8syu4QJPqNIaMvA5dc 3ESK7cwwkOTtT659uEkXzZYfFy6BMIOlBrH4ptrRNREwnCGTCnJtb0h_AqeFxxg3RkpPn0Grn1Jz e68n4i3bcSLhW8l2OMPvRdEQAO35kXn5kV7f4Jb_HXJbj.h2obYdhAKx5aUJe8XMy2aZPng6TBq9 RcP2w1n5NIh0lYlFIU2o.LNVGH5Xe9ZKPqOZ.pmvYO08dKrdos0FS0bS_kjsYOTlBDmmntRWI0UK WBMtC.5vD0Z2JalrVDjC45aUY2EapMfv2RCXDJksCew44pJRdJBy3LgMoLd.IN.eSoE8wciQ8W5g MaCx2nfqycWRtMe1qjCrSnL7LNABxNNTcMs7OFDZOLwMTyp3GRvj32XgsmhImNlwIJibZo2QL0pX l_hEGCN4qR__KmtDjQ0N0n_ZCvu2kaPzlXwz1DbUliQKzRuYMdgcddW9QD9djSj2JMvBiClBOn33 njDIh278dVo1zNWBnSf1BLg9icwfV7rMiR33K6X18XEGPcT9XpfOJP0yeMHGLLorJqHy.UjisCv3 vCj67OsgEJ9CYXkEaXFJXnMQ69m2J2TTd1vzQAYWC0DHFROUcFycxuRTsWqS_Xkx1JYeas.DCCAu 1.HknRWfhxhrYV_bSJXHUTfP0oZreys4tevr.v7B7GAnIOUM2N8myz1yLK4ozzLWay1NvfDWQFb7 jPPDRVhCW8SAGuMnZnKE6wkgrYx.pySlGUX316XLY2pfVSRRzqxI447zXq.8pv3z4jpxxyZYi7W_ 5QhkZnU9FjCEOG4voSYP1B7fEr7x0J9FLk0kIMcLQCghhnuzRmnMUNU9QuUPBz96SZeoM0S6Fd4l pChEXOmOD6uoUoBOBz8k4x4ry79PogFXmNceuOuR5uY_HveEgUaYfNWAhbi.ZGr4yc0fHwUcB0VK RMZWIjjooCABx22nWinXIbhnVZYixchDzmeeKCF.axJkfUYpCMAMqteUvaIfI90aZ84T46V8abSY LFH_Vr.fNx7viRr6U4CWbk5EVYsbm3ZEGDoTN7PMP5KcShgRDYMmE6nnrUOs2HQmgG_oFMDJx34T T76vMe2NgSokPWlJaT2G8lCtbNNZfzmq6eaVpLz1iodekAPOX6VOMa9lcGCK03gtdJSFCwhpB6xK HvBxVB2k58xgGnXudL5K.QQsoxmDYuRC9j_XegsqQpYtFYmg1xYgORdEiMrwfZELd4GAcW8sClFQ - X-Sonic-MF: X-Sonic-ID: 77326888-25a6-4a32-9e4a-dba15a80eb12 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sun, 30 Jul 2023 04:55:09 +0000 Received: by hermes--production-bf1-7c4db57b6-vlnps (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4659ebd3072a8fb8f7ff6fb5c2e2d285; Sun, 30 Jul 2023 04:55:07 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: FYI for aarch64/armv7 lib32: armv7 kyua test sys/net/if_bridge_test:gif with preloaded if_bridge.ko still panics in my style of testing Message-Id: <6ED951F4-E08A-4448-A748-C80DE8515AED@yahoo.com> Date: Sat, 29 Jul 2023 21:54:55 -0700 Cc: FreeBSD ARM List , Current FreeBSD To: Mike Karels X-Mailer: Apple Mail (2.3731.700.6) References: <6ED951F4-E08A-4448-A748-C80DE8515AED.ref@yahoo.com> X-Spamd-Result: default: False [-1.45 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_SPAM_MEDIUM(0.21)[0.212]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-0.17)[-0.165]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from]; BLOCKLISTDE_FAIL(0.00)[98.137.64.82:server fail]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.82:from] X-Rspamd-Queue-Id: 4RD8FD3FNzz4JVv X-Spamd-Bar: - I finally got around to testing lib32 some more, first trying the panic case that I'd gotten in early testing. The below is without any special lib32 patching for testing, just my normal non-debug environment updated to a lib32-present aarch64 FreeBSD vintage. Reminder: /usr/obj/DESTDIRs/main-CA7-chroot/ contains an armv7 installworld distrib-dirs distribution DB_FROM_SRC=3D1 result. (It also has various ports installed.) # ~/prekyua-kldloads.sh . . . # env \ > LD_32_LIBRARY_PATH=3D/usr/obj/DESTDIRs/main-CA7-chroot/lib\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/lib\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/libexec/rtld-elf\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libxo\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/csu/dynamiclib\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libc/tls\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libc/stdlib\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libthr/dlopen\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib\ > = :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages\ > = :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/lib-dynload\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/perl5/5.32/mach/CORE\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/perl5/5.32/mach/auto = \ > PATH=3D/usr/obj/DESTDIRs/main-CA7-chroot/sbin\ > :/usr/obj/DESTDIRs/main-CA7-chroot/bin\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/sbin\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/bin\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/sbin\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/bin\ > :/usr/obj/DESTDIRs/main-CA7-chroot/root/bin \ > /usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua test \ > -k /usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/Kyuafile = sys/net/if_bridge_test:gif sys/net/if_bridge_test:gif -> Jul 29 21:29:16 CA72-16Gp-ZFS = dhclient[56641]: epair0a: not found Jul 29 21:29:16 CA72-16Gp-ZFS dhclient[56641]: exiting. Fatal data abort: x0: 0xffffa0275306c560 x1: 0xffffa027f9d053d2 x2: 0x000000000000002a x3: 0xffffa0275306c560 x4: 0xffffa027f9d053fc x5: 0xffffa0275306c58a x6: 0x3ec2ffffffffffff x7: 0x010006085ba958bc x8: 0x000000000000002a x9: 0x000000000000002a x10: 0x0008010006085ba9 x11: 0x58bc3ec201000406 x12: 0x0000016433c65ba9 x13: 0x026433c600000000 x14: 0x00000000000000ff x15: 0x000000000000289f x16: 0xffff0002d056b370 (_DYNAMIC + 0x370) x17: 0xffff000000598110 (m_dup + 0x0) x18: 0xffff0002801e94a0 x19: 0x0000000000000001 x20: 0x0000000000000000 x21: 0x0000000000000000 x22: 0xffff000000d95000 (vop_spare3_desc + 0x18) x23: 0xffffa0275306c500 x24: 0xffffa0275306c500 x25: 0x00000000000000a0 x26: 0x0000000000000002 x27: 0x0000000000000000 x28: 0xffffa0275306c500 x29: 0xffff0002801e94c0 sp: 0xffff0002801e94a0 lr: 0xffff000000598308 (m_dup + 0x1f8) elr: 0xffff000000598160 (m_dup + 0x50) spsr: 0x0000000020000045 far: 0x000000000000001c esr: 0x0000000096000004 panic: vm_fault failed: 0xffff000000598160 error 1 cpuid =3D 14 time =3D 1690691356 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x30 vpanic() at vpanic+0x13c panic() at panic+0x44 data_abort() at data_abort+0x2fc handle_el1h_sync() at handle_el1h_sync+0x14 --- exception, esr 0x96000004 m_dup() at m_dup+0x50 bridge_input() at bridge_input+0x17c gif_input() at gif_input+0x2dc in_gif_input() at in_gif_input+0x5c encap_input() at encap_input+0xfc encap4_input() at encap4_input+0x30 ip_input() at ip_input+0x5ac netisr_dispatch_src() at netisr_dispatch_src+0xf8 ether_demux() at ether_demux+0x14c ether_nh_input() at ether_nh_input+0x39c netisr_dispatch_src() at netisr_dispatch_src+0xf8 ether_input() at ether_input+0x50 epair_tx_start_deferred() at epair_tx_start_deferred+0x110 taskqueue_run_locked() at taskqueue_run_locked+0x198 taskqueue_thread_loop() at taskqueue_thread_loop+0x130 fork_exit() at fork_exit+0x88 fork_trampoline() at fork_trampoline+0x14 KDB: enter: panic [ thread pid 0 tid 1028122 ] Stopped at kdb_enter+0x44: str xzr, [x19, #3328] For reference: # uname -apKU FreeBSD CA72-16Gp-ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT aarch64 1400093 = #102 main-n264334-215bab7924f6-dirty: Wed Jul 26 02:02:48 PDT 2023 = root@CA72-16Gp-ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400093 1400093 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jul 30 15:17:43 2023 X-Original-To: freebsd-current@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 4RDQ3n2vWXz4p8HS for ; Sun, 30 Jul 2023 15:17:53 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RDQ3g70yDz4JJd for ; Sun, 30 Jul 2023 15:17:51 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1690730272; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=FwsdZpnSJxkgLS1RcB4Ua4TK6BjN0gb0iYnViPBapk4=; b=MVYc+1/k1dPvI8ioZJ+mCx2AtFI1agRxce75nHG0b1hby0LMdeoyKmOvNn5wjc1IuOedX/ WN2pNSluF6VRMn1A7cC5A46C0QiFtDHS5MnsRS5DF6SrRvL+wEEpz8H3CT1VuSeyQyIKj2 1jcbPLDYTnXD0hVtuf0arLVyg+x38bXIIh9+SQCclmdadMq/OS/80iUhCnZ4gMMknPN/64 7gnf8NXFir5DyHvACfGVtog5tKnPGdgHdCbWItT751L+45rfRMEGPYgjOqF0O6suLWYkCQ rkM7NNXPncz+h5qYZGZygCqi5byCg2wE9VKqn32oip24MmJBicFPwIjGw7ifBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1690730272; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=FwsdZpnSJxkgLS1RcB4Ua4TK6BjN0gb0iYnViPBapk4=; b=qysbFhgELKEx/X/TWKZKgDirr4uQNWXEV5eQq+ackiAMPlboNTi9jkB7cLYO5dDeC4xYSK bdgmPLMFb0FKbp/V3jEnF7zFqjA7edYrBSLtY8xheFwukVd+jLCOfgIutL0ay6il7XAo2Z sGJNLGEX2Hfew2YWMvtSVjbM9mImseKtUNSE+DnUpT7juYxg1DPBg187BrQpGCPjcGBDv3 YcZeHnjXykmsysU2DeH85HPSWHbkgt9t+6cvmD2b+8ycDIL5sQgIuzsDn++eeXcYs6qBp5 G4uP9wQVv5eeJdgmovqHi9BH8r3Kz8tCkxr9hVRocNYwNQa5/8WdCAveePCwOQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1690730272; a=rsa-sha256; cv=none; b=wkj0bVCW1Rk2sp2ji0/3Tiwb9zVOX95TCAxIVyM0/KOsfOPtlA0UGv83jO+GQu23JGrw/e eMdH7fFepRM86Q/SKa9kHk9E2Etj7ISEgJRXpnQWNisexiHM25HeUm/QhR1QIIp6y7pFlN 9tm2nbnU4RV2KINjOeA0it63VkD0ExRc+AWvpMeTx/Yd4PzDHCGeLelwUheSIkicPfMlfM BQcP4TPmMoF6/v4BR487gIVN2MlFlsuyDUoX65nyHeTtkPQp/NI/p26/pvt+43T/JODEjW lO21emwT7hJZJDqEW9Y3R2VzYl+F6FA8RukCVUPGt1oD99gmkJWtqPBtT5O4Ww== Received: from [192.168.1.10] (80-42-66-93.dynamic.dsl.as9105.com [80.42.66.93]) (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) (Authenticated sender: grahamperrin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RDQ3f2CWqz16Bq for ; Sun, 30 Jul 2023 15:17:49 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Message-ID: <62d300c8-2c3e-58fa-334e-23a17962279a@freebsd.org> Date: Sun, 30 Jul 2023 16:17:43 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.13.1 To: FreeBSD CURRENT Content-Language: en-US From: Graham Perrin Subject: Unreliability with DHCP Organization: FreeBSD Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Vl03Tqn9B1qz056ReDSd9oA8" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Vl03Tqn9B1qz056ReDSd9oA8 Content-Type: multipart/mixed; boundary="------------oU6hlYKmQh0c3Lk9TINI1Cyp"; protected-headers="v1" From: Graham Perrin To: FreeBSD CURRENT Message-ID: <62d300c8-2c3e-58fa-334e-23a17962279a@freebsd.org> Subject: Unreliability with DHCP --------------oU6hlYKmQh0c3Lk9TINI1Cyp Content-Type: multipart/alternative; boundary="------------48ZDuw9jm6zFH4IL0acpjpdA" --------------48ZDuw9jm6zFH4IL0acpjpdA Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 MS4gU2xlZXAgKHN1c3BlbmQpIHdoaWxzdCBjb25uZWN0ZWQgdG8gb25lIG5ldHdvcmsNCg0K Mi4gY29ubmVjdCB0byBhIG5ldHdvcmsgZWxzZXdoZXJlDQoNCjMuIHdha2UgKHJlc3VtZSku DQoNClJlc3VsdDoNCg0KL2V0Yy9yZXNvbHYuY29uZiBmcmVxdWVudGx5IGNvbnRhaW5zIG91 dGRhdGVkIGluZm9ybWF0aW9uLiBJbiBzb21lIA0KKG1heWJlIGFsbCkgc3VjaCBjYXNlcywg dGhlIElQdjQgaW5ldCBhZGRyZXNzIGlzIG91dGRhdGVkOyBhbmQgc28gb24uDQoNCldoaWNo IC9ldGMvcmMuZC8gZmlsZShzKSBzaG91bGQgSSBhdHRlbXB0IHRvIGZpeD8NCg0KSSBpbWFn aW5lIHVzaW5nIHRoZSByZXN1bWUga2V5d29yZCwgd2hpY2ggaXMgY3VycmVudGx5IHVzZWQg Ynkgb25seSBvbmUgDQpzY3JpcHQ6DQoNCiUgcmNvcmRlciAtayByZXN1bWUgL2V0Yy9yYy5k LyoNCi9ldGMvcmMuZC9udHBkDQolDQoNCg0KSSByb3V0aW5lbHkgcnVuIHRoZSBjb21tYW5k IGJlbG93IHRvIHdvcmsgYXJvdW5kIHRoZSBidWcgKGFuZCBvYnNlcnZlIA0KdGhlIHN0YXRl cyBvZiB0aGluZ3MpIOKAkyBydW4gX2FmdGVyXyB0aGUgYnVnIGJpdGVzLiBJJ2QgcHJlZmVy IGEgZml4LCB0byANCnByZXZlbnQgdGhlIGJpdGVzLg0KDQpscyAvdmFyL3J1bi9yZXNvbHZj b25mL2ludGVyZmFjZXMvIDsgcm91dGUgZGVsZXRlIGRlZmF1bHQgOyBpZmNvbmZpZyANCnds YW4wIGRvd24gJiYgaWZjb25maWcgZW0wIGRvd24gJiYgc2xlZXAgNSA7IGxzIA0KL3Zhci9y dW4vcmVzb2x2Y29uZi9pbnRlcmZhY2VzLyA7IGlmY29uZmlnIGVtMCB1cCAmJiBzbGVlcCAx NQ0KOyBscyAvdmFyL3J1bi9yZXNvbHZjb25mL2ludGVyZmFjZXMvIDsgY2F0IC9ldGMvcmVz b2x2LmNvbmYgOyBwaW5nIC1jIDIgDQotNCBmcmVzaHBvcnRzLm9yZw0KDQo= --------------48ZDuw9jm6zFH4IL0acpjpdA Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

1. Sleep (suspend) whilst connected to one network

2. connect to= a network elsewhere

3. wake (resume).

Result:

/etc/resolv.c= onf frequently contains outdated information. In some (maybe all) such cases, the IPv4 inet address is outdated; and so on.

Which /etc/rc.d/ file(s) should I attempt to fix?

I imagine using the resume keyword, which is currently used by only one script:

% rcorder -k resume /etc/rc.d/*
/etc/rc.d/ntpd
%


I routinely run the command below to work around the bug (and observe the states of things) =E2=80=93 run _after_ the bug bites. I'd prefer a fix, to prevent= the bites.

ls /var/run/resolvconf/interfaces/ ; route delete default ; ifconfig wlan0 down && ifconfig em0 down && sleep 5 ; ls /var/run/resolvconf/interfaces/ ; ifconfig em0 up && sleep 15
; ls /var/run/resolvconf/interfaces/ ; cat /etc/resolv.conf ; ping -c 2 -4 freshports.org

--------------48ZDuw9jm6zFH4IL0acpjpdA-- --------------oU6hlYKmQh0c3Lk9TINI1Cyp-- --------------Vl03Tqn9B1qz056ReDSd9oA8 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmTGfxgFAwAAAAAACgkQt2dIb0oY1AtG Pg//TRTpulK/Ux2KggmQuhjJ20sxAJ0TZb2M6tpplpFc3B3bqBvzo4gct/OzrBae0ycnbq/e7JQj h8vfIrqJzEWDVT2PP8Ks7MFOBoh3z3nh7LtKjAYSS7r7y3jmZSVq2187QPX4cHc4sUpFlYVVW4Dp eWWNS2iyjN+7qb59nDTeODLiYz3ssn/kEpPJIOBBlW7wXAqRsR6u03vmpZmgvG6bbWE35lyWxGYS 6kepN8s2O+lXaubCD/ZKGgzDXhEDAdcZqqTarZ1L16bW+3sCEg5hUlVaU0+CJVBnprLFvpGvkLrG 6whHxsGIq6CetKIbhSF9Ka0Uym7iW+o53NnyzPRn/0gPK0tW9m0rpUm95nTwNa7spmbgu4i0HbZV Le5hDyTdEckeawHl6XkSIpLWDeN10d8YZpTcc75mwK4DphF4NOKbUU+1TOUXdihn8le98J8iMsYE KpN6vgMsJU7EVWD5+8A2WMZk2GXwJn5/2TcZ0Y1LJhSBiwknn58UGwSANpdZd83d5fr5NmhUwoRQ i8yMopr3VW4TjvlfNC834eIQnrattm/oONemnIwLiflO4+Dn23DG0u1q1HzI5gd8N8m6URG12p8C 4/he9wJqXsoPA88riIP4IrN72lMW+JuPFDRkOFp7paK5LM4GpwuwX8gx9SZHRKdzWtayAiIjtHQ5 iqg= =E4o/ -----END PGP SIGNATURE----- --------------Vl03Tqn9B1qz056ReDSd9oA8-- From nobody Tue Aug 1 01:16:52 2023 X-Original-To: freebsd-current@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 4RFHJt4lrjz4pdwJ for ; Tue, 1 Aug 2023 01:17:08 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (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 4RFHJb1m4Xz42jw for ; Tue, 1 Aug 2023 01:17:03 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=b6Tq5zoj; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::22e as permitted sender) smtp.mailfrom=rick.macklem@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-oi1-x22e.google.com with SMTP id 5614622812f47-3a43cbb432aso3746839b6e.3 for ; Mon, 31 Jul 2023 18:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690852622; x=1691457422; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=pAWIA5K2zZJz3/lUJIn9YATCisJRJbG26BiMdpwKiqc=; b=b6Tq5zoj4db9nanVE71yUibQ0w/PrZEqwAZdQZsWf0dH9rWDBRyNUkejALQX7Pqm98 9KB9mHrfBpBLv3fD4LYFoLWf/s/E5B3gjyiFvaE25m7VsoCM9DosnVR23vPj/r0BpQr1 2Pty331NwIoQwa0l9NBlG6JUH79BE6IdXDZrWy+mPIGzst/R6R0XWS7F/2jBhlFaSW4w 5EwnZQopr1yfS0y7FOKL8xZya/XMxg24h04va5EP0eMrt6y+Yz5Xv9+icRf1uEGNxcQB 9mHffwczhPpK19VaLuU/kbzqMdIQf2cWcqH91RuXMKK8Umvut5tyIUxl8cRwdQK4n9LE FW0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690852622; x=1691457422; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=pAWIA5K2zZJz3/lUJIn9YATCisJRJbG26BiMdpwKiqc=; b=HoHlGOHBshy10KMFgW+TZMthM+/509AUIleogQW5lOMHU0qJvPAM72acdjtiXoWuIL tNpf5eg+Rf7e5CtZ73ebQ8Q6BxYCSfNXWn94d6B24b2BVGy04Fj2u61n8uJiStWE6CAE BCKi9qydigoiUT+VPCMKUc+XjK275o9RDuybQc9IueR15FxyhWzyI+sD3LNNZkA+tVYH gcfVH2jydOqLEFGYF3tk71f/+yWy71xJGhHqAAVeG4VhFYKqU6CCHS0ZSj0m4BN9K/gK 0c7QldxFpuJga20JYD8voGcBm4gE+Ni2IfO1IQIJD/GmCsF1EVxxvpLVy7KTfZTvAY4p EEaQ== X-Gm-Message-State: ABy/qLaL/CPf+giwyk/jSJDtoP5525xDXP6Cilr5X9DaACy91KkIIffO 2GfU/KqgnnU5dTG6qKTlvyBQ3e3Ev10z8LvJWZngBM8AfA== X-Google-Smtp-Source: APBJJlG67qpXAqs9hHEYWtRN0Cl7buAHi+ckn2YXBKUFM67TGa8ilvEl9n3I7FVh1mgq7ApDKAIfnYT8s/YI58BcuYU= X-Received: by 2002:a05:6808:203:b0:3a4:8086:bb9f with SMTP id l3-20020a056808020300b003a48086bb9fmr12124037oie.18.1690852621759; Mon, 31 Jul 2023 18:17:01 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Rick Macklem Date: Mon, 31 Jul 2023 18:16:52 -0700 Message-ID: Subject: Review of patch that uses "volatile sig_atomic_t" To: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-3.25 / 15.00]; NEURAL_HAM_SHORT(-0.99)[-0.992]; NEURAL_HAM_LONG(-0.94)[-0.937]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_MEDIUM(-0.32)[-0.319]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; 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)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::22e:from]; ARC_NA(0.00)[]; TAGGED_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4RFHJb1m4Xz42jw X-Spamd-Bar: --- Hi, I just put D41265 up on phabricator. It is a trivial change to mountd.c that defines the variable set by got_sighup() (the SIGHUP handler) as static volatile sig_atomic_t instead of static int I did list a couple of reviewers, but if you are familiar with this C requirement, please take a look at it and review it. Thanks, rick ps: I was unaware of this C requirement until Peter Eriksson reported it to me yesterday. Several of the other NFS related daemons probably need to same fix, which I will do after this is reviewed. From nobody Tue Aug 1 06:05:19 2023 X-Original-To: freebsd-current@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 4RFPk3068Pz4prVj for ; Tue, 1 Aug 2023 06:05:47 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RFPjT6hfNz4Nsj; Tue, 1 Aug 2023 06:05:33 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1690869934; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CBUhqarDV5UFS2xfJTCgRo6eoEXQ720J3E7d9+e1Q/8=; b=ul0VotGWbddJzpfobzOdkouk0tvr9+m8AKPlf48z/i/fUxFGJS6xfwleJNOOcbtD+jM/U4 j0LMHbup9qAlGYtVjkMahzMg+GqBGnlb9NuVtcwX965RT+E67Nk1RvorOo2BZ+MZcgWN/r sRrAWj3kiR5Pc0d+DtIj3KsG4GbIOWPR2WZrOAwVTiVlA5TkcTajOMva26gdpkKybaIiEf kICXO4jFoMhiIW2dFHvn3vsd+Wr7T+G2BvZxSfoXz6aQnIMv7YeWRgM5XAPA/84S2CpDnM xMYKn8BA1SqZon6YakfhP/jALmJ5JRYYrT0AiNCQSiurlJB7C95Sc9ddeGuohQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1690869934; a=rsa-sha256; cv=none; b=KHAWrRF2b7TUzrdnNxk+QRwxMkfCePy9v4boUA0Vy24ArEJwHvomFSPefyKkfobv6MRU6r CsBMKzm5XFrQGbaaUtKY4i+mp1V8wpUPJxmjH8FCwCcm05pUke5M/R82chJfXI5Pol8Nlb CbUH6/uRfCmj8VshdQlO2adOzgPQpEZVm+f+J/9ct3CfIy3EO6v3mNBrEtvJYdKKgSSklA 0ueaP3DtzKfI0U5jogfSnL265Bfm7DpIymrqb6VRTlBeOpDfw2mDGGEl1TdRn7qlH1Y1dy ZeNki6CTC37FKvneTD7DFPl9fdjjwXD/oxCViQtrpVlB5l3vDVnWKJtL4YygxA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1690869934; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CBUhqarDV5UFS2xfJTCgRo6eoEXQ720J3E7d9+e1Q/8=; b=ZmS6RF+ZfbfSnwo03aaMebea0nWL/mQJrmRqR0FdKwcq6Wrpks/4GO7dAGYPveLo7qzCkD 0BqZIWB4jNGrAxH64mtSrILKdwfJhvkDMQ2DdlSN6ON7u/AvmhF4Ceb8FqzhFSdkWBAWLR P3ntrWaYmeIiWWy+piZa9lNckuXKquTYWe8EI10O6ly87M8Lh1Bwm8MEfITM9v2MsJCNCU dN6gRJ5Rzj6FJGykoOyBDJ3rJvAWUNBUxd175benjCjgWsR2E2VBz52NWMzT+6RqXuy0j7 1l5LpeLztI0yXiC5D1UPaY9i7D25woEZZXBsYm5yIHQzHqvAIToe/epu9et2WA== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RFPjT2FKwzcG9; Tue, 1 Aug 2023 06:05:33 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtpclient.apple (host86-141-212-56.range86-141.btcentralplus.com [86.141.212.56]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 2589A8869; Tue, 1 Aug 2023 07:05:31 +0100 (BST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Chisnall List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: Review of patch that uses "volatile sig_atomic_t" Date: Tue, 1 Aug 2023 07:05:19 +0100 Message-Id: References: Cc: FreeBSD CURRENT In-Reply-To: To: Rick Macklem X-Mailer: iPad Mail (20F75) Hi, This bit of the C spec is a bit of a mess. There was, I believe, a desire to= return volatile to its original use and make any use of volatile other than= MMIO discouraged. This broke too much legacy code and so now it=E2=80=99s a= confusing state. The requirements for volatile are that the compiler must not elide loads or s= tores and may not narrow them (I am not sure if it=E2=80=99s allowed to wide= n them). Loads and stores to a volatile variable may not be reordered with r= espect to other loads or stores to the same object but *may* be reordered wi= th respect to any other accesses. The sig_atomic_t typedef just indicates an integer type that can be loaded a= nd stored with a single instruction and so is immune to tearing if updated f= rom a signal handler. There is no requirement to use this from signal handle= rs in preference to int on FreeBSD (whether other types work is implementati= on defined and int works on all supported architectures for us). The weak ordering guarantees for volatile mean that any code using volatile f= or detecting whether a signal has fired is probably wrong if if does not inc= lude a call to automic_signal_fence(). This guarantees that the compiler wil= l not reorder the load of the volatile with respect to other accesses. In pr= actice, compilers tend to be fairly conservative about reordering volatile a= ccesses and so it probably won=E2=80=99t break until you upgrade your compil= er in a few years time. My general recommendation is to use _Atomic(int) (or ideally a enum type) fo= r this. If you just use it like a normal int, you will get sequentially cons= istent atomics. On a weakly ordered platform like Arm this will include some= more atomic barrier instructions but it will do the right thing if you add a= dditional threads monitoring the same variable later. In something like moun= td, the extra performance overhead from the barriers is unlikely to be measu= rable, if it is then you can weaken the atomicity (sequentially consistent u= nless specified otherwise is a good default in C/C++, for once prioritising c= orrectness over performance). David > On 1 Aug 2023, at 06:14, Rick Macklem wrote: >=20 > =EF=BB=BFHi, >=20 > I just put D41265 up on phabricator. It is a trivial > change to mountd.c that defines the variable set > by got_sighup() (the SIGHUP handler) as > static volatile sig_atomic_t > instead of > static int >=20 > I did list a couple of reviewers, but if you are familiar > with this C requirement, please take a look at it and > review it. >=20 > Thanks, rick > ps: I was unaware of this C requirement until Peter Eriksson > reported it to me yesterday. Several of the other NFS > related daemons probably need to same fix, which I will > do after this is reviewed. >=20 From nobody Tue Aug 1 06:22:12 2023 X-Original-To: freebsd-current@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 4RFQ5d5w9rz4psNf for ; Tue, 1 Aug 2023 06:22:39 +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 4RFQ564qW7z4Q6y for ; Tue, 1 Aug 2023 06:22:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=cuv1dJMq; 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=1690870948; bh=a9fPu+ZAKieAFj0ZPMMSV6WB0MSERjWgfcHOXLIrr+M=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=cuv1dJMqTHk0skRhcDlTo3KAPDfPIaJyQ6ZXwqcLf4Y1aYHpq5p3Qjqvdtm3+WnLukzDi8/5qim6/FxKyYbhzwGbv2vbWF4rXA/yKFRd7Qdf30HVwbmBJyX0YI1zPwmgOwJowH+FuE4WNDvMaCh/OyeiZ3p3FtBJIjoRC/ugA4YFHcJjM7CnmZ5ieuMdudU7PSPH7rZ0H8oSc1/7DYbcGPVaE9Uq0ezgKjEKvBLHe6fM9BEFC0M36UGjcTfBhRLOSWjHVyuwHF+a+586L5tbH6yZha4bJABqFEG514qlw8QPgJMulOB3LgEbQia5ZiwHuMPrEYFrHTVCBFhPVfsTmA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1690870948; bh=G6UVpurdUMl7May2NLod9aJSOtZP8KnUqMBNHPAuFxi=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=TsbQQdTTKaebSljxIOPcVjUuEgyi6y/WeJoIHK6agKTbft0MSwNLTgC6d6IIZ15p+HbUMDB4oZJCi/bKBpKEvDoPyPz1AAdlMRIuN+jiHk/pMk9DKqnhKJ603MxlO8SlYR5XRnnZbHq0wQQkg5M0ChLvIdYOgjAQCuFxAgb8EIhIrTAczlLSAFkoGBjL1huVowTu56niqCU2NRd0YkQT+CbBFrY9NKKL+wGSvg463/VbagV0whz+acbSS6i5orH7yWFIfOUB1ssre4AADfLcvNCIINjitV7V+LjVGvIanGVIOtVdNUEjYm54jZHkH8Vwyaj4Kej6B4eXBlNCZ0LOgg== X-YMail-OSG: H3uUgTMVM1k5a2mZm1wbpJMAT9GCA23BLHBl.0EaXVdtCqlfH5lgIQdgLpy2b.a G7_u61FsY7bujdru8Ydg9c3_KmxXvMmj2.0d_bG0YECrKc.VuQ7NHVlu2RoxpwoaU_U5iIkyjA97 xLzfwr3XZ9KVr45z4YG5Nn7noRPMBOJEEn3i6oi2JlVUk7.69m..vUlyhkZrWlkD9DTuP3YFKe23 ieDt.pV762O.YJZS2irHMXdEPacmMkFkIlEc03lxekB2g.ewxmjH0NVzaoLkOdvUbieywfgRhMyz WEte5AO7vzPPZeKDySjlJA0KgsCIfAL4X9SIA3_uGRnb6uO.XqllGaD1NU9tVQefUeZGFHRTexTA 7grm9UNiWRf3MDskOzhzGt_SnaoIuj.bgiZcGcVGK0PWgnl6tAZ9LEfZPMyu2BGc.x2JnHi5dwIY YbDi10FqxQpV5SvsKnixRO1xKHKpuvpzvGos6INAZ2VpCQQ9LSkBoFGysYq36H.zXL98PU1SJHIu JdsIKU77gB2IKANkKFufSJ2DJthPvoJJLXCxqhWOvhr4dJHw6PPjZ6mdVXL_BJgEjBqVtpVhh5.8 2c02hiAuuruTFZZFJ4ltqCcirLkNH5TkECiBMFR3EyjaznAE199XwtaOd5P7eD290_RspimDT.sT zMA32r88QZvJMlEnPSg.bBJpl84GwFLZmFxgav9mRcEYsf5uQRRpKG9uWFhLgAxDZ2xQtywy40sZ LKA8P.P_HfhQXcohAc8aKa41lZ3GTR_5vq_.rfcYKrrJt6VC1lrZQaLwQ.4k3qxH_3jSKjSb_BLY BAOP1H8NDlZv9SfE0wMT6ZAiNWfUXW2fUKZjoOL2mLKFEmhfTdclO8dbvWV.XbF4BTnXYcDEZSrO .LDavFJ6kln.FFimNOweaDDnBugAU3vxiSfQSEEX62ncvLllozz2bkm.6ceQJtvvcmqsGB71fnu4 r1Q45G_P.HcECiLUeaHHPdm9Xz2fchBwvJ3UdYQll0sVFBjdSfWSUzh4ezA1ZsXcY100RZ9cl7cv TbV3..5eW62EDb_fHNbYbaVJtaZhqdxOtm4hmpwef9.b87V.5ufTo7rCMZtc34WPJWxYyXp.LhyK WfhhwHXvUt1K_GXF7WuZYcxXYiiFe8s26zS85ydxL57lVWMb3HPabCP4NT_9RMpygvr4Rkpb1QSv RH64PwXNoWSggrZuDWvH5O5sOT_qtbOL6V4jvPumvhZJSnweroo0eNXF4kxXOBV1j0o8vPfQg4b4 hWELsVUD5TnfVs8ynR3Fbv5stG8AhpL2tUUZEx4whIq4may.btKmFcW0O.esc4DHUJgqJLcZxKRe WaArHhMSd2DEBR5PBFadZCGffTq.SKmmQSUbMLOpE_u4n8XF6fhVUD_rk7O7mjje2.IHXUGh_MhG Ws7LfTTCuwqNKx9Hyb8Qfdpd3H8c0yZhMaLI5xmYxVk_wagi.LphNG19ene_oOrCfSTqxS8v9ZNX AbxG_iQefebQmIhm5EMRsKRAymCRlFbYQSK.Xogv4SLxB8so4bgO9rgoDYIq5eKQV7EUT9_nkQ7y GYIFM7xeWRUz0PNKKiOlNhJypuQxuFJOtTZ58T_9bj43_1IWqx_rkEGDK8EgaAGYm9AibiRVctJc 4IoR5W8Bfo9a.UovP4IvZODlLwpWAYH6sXQHoZw7K1ttfmcVNZlUNGxDYJDzHC62fmMAYBJ5MZNJ um_jvTtXhss9k6K1E42kbHtIMsMagz.egf1df1H725skt2mwJ30MtYoPsDt3aTHnqnWGvnzcsV0z 2_LE_psepng2yNnlLbwgPe4yxhqECrAJRJOoLguSSjdYKtXYc2IWvHjZZQmi_OcCY3JUlLES_zw7 KKFxIiFJC5z4_2W0F2F7coXY2Nhh4LvVLn6bVlI0_vJXvbagju0FvhJwogKRgc6caS0DHrtdhCyn PsGwfrnLoNvBou3IgHrTw2b7LUnxnWhr3CpwQkT3sTrHTRUxG0Pbx7ngL5I6UdqDTpCBKUhiPbrS YWVgQOr880MdqB6X1cOxsRBoMP7eskzSW8yxtgh.dlQRJ0x7wpc0rKg_hjD43gWb1WRhXk7s_5QB jc3UH1.KnEuznUnqibpWXkfIFgGVfRbpM9Zn4soKGCIOcoS6sYrpSDoyuHKNYrw2zI5gHGruTlnf gfXbDW6wCFfLiMVEJT5UIiTvOFi87w.AgwYpF4pIlf7X10fn3LPpt6TNuBn_eCnE08UgkzDxwAH7 YBKDpZtDtgOlCiDzT80Xe84SXDmYG.OnPTPWb7E.Qsf7agvIVXAVvDVloXoFnkvRmeV1yi3H_RA- - X-Sonic-MF: X-Sonic-ID: c03e088d-a119-4326-9ef8-e69afd8d9536 Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Tue, 1 Aug 2023 06:22:28 +0000 Received: by hermes--production-bf1-7c4db57b6-49kxr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9df8b633e57ef1bd49d2b8418a583c3e; Tue, 01 Aug 2023 06:22:25 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: aarch64 lib32 vs. armv7 mdconfig behavior: "mdconfig: ioctl(/dev/mdctl): Inappropriate ioctl for device" Message-Id: <49479F21-3CCD-469F-BF23-FF332D8EF0E8@yahoo.com> Date: Mon, 31 Jul 2023 23:22:12 -0700 To: Mike Karels , FreeBSD ARM List , Current FreeBSD X-Mailer: Apple Mail (2.3731.700.6) References: <49479F21-3CCD-469F-BF23-FF332D8EF0E8.ref@yahoo.com> X-Spamd-Result: default: False [-2.52 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_SHORT(-1.00)[-0.997]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-0.02)[-0.023]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from] X-Rspamd-Queue-Id: 4RFQ564qW7z4Q6y X-Spamd-Bar: -- Not via a chroot'd context, but using the files from a directory tree that allows an armv7 chroot: # /usr/obj/DESTDIRs/main-CA7-chroot/sbin/mdconfig -s40m mdconfig: ioctl(/dev/mdctl): Inappropriate ioctl for device This sort of thing messes up the operation of the likes of the /usr/tests/sbin/growfs/legacy_test logic: #! /usr/local/bin/perl # $FreeBSD$ use strict; use warnings; use POSIX; use Test::More tests =3D> 19; use Fcntl qw(:DEFAULT :seek); . . . SKIP: { skip "Cannot test without UID 0", 19 if $<; chomp(my $md =3D `mdconfig -s40m`); like($md, qr/^md\d+$/, "Created $md with size 40m") or die; $unit =3D substr $md, 2; . . . Other ioctl complaints: sys/aio/aio_test:md_kq -> failed: ioctl MDIOCATTACH failed: = Inappropriate ioctl for device sys/aio/aio_test:md_poll -> failed: ioctl MDIOCATTACH failed: = Inappropriate ioctl for device sys/aio/aio_test:md_signal -> failed: ioctl MDIOCATTACH failed: = Inappropriate ioctl for device sys/aio/aio_test:md_suspend -> failed: ioctl MDIOCATTACH failed: = Inappropriate ioctl for device sys/aio/aio_test:md_thread -> failed: ioctl MDIOCATTACH failed: = Inappropriate ioctl for device sys/aio/aio_test:md_waitcomplete -> failed: ioctl MDIOCATTACH failed: = Inappropriate ioctl for device sys/aio/aio_test:vectored_md_poll -> failed: ioctl MDIOCATTACH failed: = Inappropriate ioctl for device For reference: # uname -apKU FreeBSD CA78C-WDK23-ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT aarch64 = 1400093 #5 main-n264334-215bab7924f6-dirty: Wed Jul 26 02:13:44 PDT 2023 = = root@CA78C-WDK23-ZFS:/usr/obj/BUILDs/main-CA78C-nodbg-clang/usr/main-src/a= rm64.aarch64/sys/GENERIC-NODBG-CA78C arm64 aarch64 1400093 1400093 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Aug 1 06:42:20 2023 X-Original-To: freebsd-current@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 4RFQXK216cz4psx6 for ; Tue, 1 Aug 2023 06:42:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.148]) (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 4RFQXG59bKz3C8x for ; Tue, 1 Aug 2023 06:42:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ZR+EC8Qq; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.148 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=1690872156; bh=C3sOZNqChWqRfuu6BH30J7qpjUsS1CwpLCWDPHedAKM=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=ZR+EC8QqkBxCXEZxO+42EKMjSBfFPZF0V1leUGAoKWSmY1swPO2HejPASKmpSwQVFjtUeo09VGNK/BfGm+g69kXOfD6tOAO9LAaueZgx0II253pqTfQY/qHUAOL07XrzeefTsNTgzpymBnLOA/bzEVcQ1waFIaczUBvnvN9peZYTDw7KLv7bxOi2zrVuzRZibpASkF2mjNEfEis9CCk58VIxiKT+weh1oIADYGMf/s60TZ8Oc7F+vdqaIwNAD/3O2fU35oY0++rmvo8iOv5iVhNkuOkDq7+/ALKE39AsFIfKeqgAOLPFcH0q1LgNxYMu0sA9O8rzZbz1+ElLhVSoxQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1690872156; bh=9B/b34mr0TXUWWe4lf2UC5h+xzkyse5uMUA4cebmbR+=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=hWN7tPJUkWk43kylb16TK5M96Aq0sMlB/a9H01arqWd1wvq7t6obvgblEiwJLGHa6bIrfuCsdTDfYYIs5ojPmD6t9Lo8ihh59075Y92wImYQJXDD7cyqkbQmAbfIuwVHsncMZ8GCi+5hH2VNwvKeXzYVv08tDSqwJKSUJ+0qsgbZNnjQGjBgN71xVXfeZ8Pa7ywYSn11nZtRWLnaIDN99kCrDKsRg51erkJCV6hcg+34JLTDvmKOY66Tlwf9CFXr+WUF9xiqCL6WHPGeJPIgWLK2Pdp1aSsEgCCl36koylXWKJVcAewj9g/qVHRR1e4FtsFLBwFq+vN+kzVq+A9JAQ== X-YMail-OSG: KqD42twVM1lJLAI0vV6gsz2469xugU29Tx3.b3ilqQt_FbxCLQIhpobI762knvx n0KUxF4elkD1NTFuAPqb6ngpxPcf9_QOoElVJAKmpgpFssUWPYTOlV3bVLBIFZAfoz00c6PdYjkU h3ZKyiTNBBhS8oxkycai8YfB83HfoNRpdODNBed5ywt1u6L8yexhkIKjkMzsfnAoGSs6qOGHGf7i 36Xr0ievzbebZ3cxVeF2ZivZx5Zc3aqt3YuQhwkWkx2y4_Q46JS_vq173VYeN7cPBk0tWtvHx_xa aVFMZ.TvzDmtjCaODL9NeRKfX3D7eiH699DIRzEcI4VPhm4Jh3hlegaEXlfDyE0VR6QBy8ZI_bXh 9TkuLIU3sj2l8RU3ZUknFPgluMVoIt1Mvf.aHN6FfYQeqBn.kqJotrtWrW_tnKUYmROJ.X216a.w ZhiHQc7IxqV2bZFwfhyrRH63Q97SHT3bvlUmX2n9ZWPONeFiv_aK0AJ6lPBEvJJ875_SSu5x6AOn L3PMZksBxRwWdvw17iE74BlIm4Wmn5cSMkc37g6T4nvWuc2NVL.DVPAcbE2X84gno6LZxg2ZKnwl soR4qKCbNGRfkaNFKgtKrOcDf8UEUPa.fLV3FocINgrQ_Wm0eLxHdYMoGPAFpHboSzED.s4CJgCR WDIxQCMNikPc8SQNsen30n133N4P4Y8AyP8Mu4cjXpcSxTal6vgr0NLBqH4AWkMRHEvY0DCU.oO5 WAgv4jxTwq45zVkJa2Wq0vEmQEQ.wzNX2Bc613x6ScdDWOQbiS_YT4JvnINXIC6R1X5C600BS04_ nTF3gRh57xQuy5cF2A8BmZlJfxm77GfixstsRWFlqlhGhYEEGgRwI0uhKfVYbNHkGyhQ8LMs2I3K OellDkogiqAK9CZp8xWCj2sf0YQgclfF70BrSE7QTlCvhuel_8wI9yPOlOu3eHu2oYFsI1ipdo6D mpPrvAAXdABsiaexeilBRARA668JHQh62OFE5ZuzkNusWN3bRk10b3Oai9gcC7U5Wxlk.p2OmXgi tTheAL.CxmOM017TF6V6qQpkIhAgwEsiKduUVtu1PR.nMYOKK0bSbrRBJHF7sNz5yszU9SznyUBF Eg0zwxb_6v86CEuMmTqXxF9zghWmvfMFBGbZv3IEUxSKO3.zyNPUliidW2fyqMReWDb5obHlPhx5 PqD.q6vD9BkFbZgaNo8UmCv7B.2T59d.kGRItATwdieHlyRcUJeilpnjXZ7DvLR_s2PnUCQRG2b1 .dH8hg0IJ0BsIh.BB_Hcec4at8qzF_pqCtfGuk8.pcsf2pftAnEKfCOsVZbVkVxvJ70wZYCDMOYe RlRomAU8XiHPtJ6Y8sWRwHuUnLqcoadQ43ZAQnQJvIlW8GSUYC1HFwRehIKl8st7OSNfr.cSNEu4 YPMLfC9N5OWoeOvNwISUEuaS0jEFjcElN3AB_FPAiXbG.9TfNGXnHBNmu__LIHxMcVtL4EsnaHRJ uVk1Mo2OUqcXB8dLBsXlB32fQC4GVvuxcs23Hk_fEUTc3auKSHzfiQOmtGt28orpJakt6KPozc4V ucX9wh0oH8aXIu1hLpEjwnRIc1uvlbLg0V33aO.wT6dkkxtmDqo5QDnBKSd2pv9EJzIQlJyvdW17 bbw.IPj7Yfmm.BS6inEerVjne8V6cvRRUh8M._JSx9OUTy7GCxG2KYZBP_lsTNMqZ63tr67UFAru 9K3dKCxMB0EYIefZUGFVNiwvCiJ605Pknd6ij1reyXRoZk5ifxGufyCfls0LXxltHtcZYnwHLV9c Xm5U7geLEExJNpipGGZAyQJzRa3c5RpX7RzOZuXc5LKO02.6_tB6raq3XZxekCndP0WniW1HJqKg 3xd3E_Ky_OTTRp.rU.J4FfP8G5Z6Jthg6cMAyv10I4F0lVs_US6AoWnjY7AmyI.fkBnjIpl.EE4d wuCnBUjjOl5_2CRFYwbIsplUYAHCSUrVewE69bKMtq6_q5Rw5a5BU7WCB88Lx57mh0K3MLIcpWzW cQaWGPttb8Pgkk34IVCG0fIu2Z7SUOddAYQqn0hxmu8T7gmETVWp__RXHGmFrpGasTGDIHlgwwsp .FabAl__5YOtkeMYELq4GZLkVLiro_01NG97oRuvGvlffu8AigeWsV_92dC_.Bv6KKDAZwKxBtT2 kObDSS.TPpdnRQy1S8fIjpLIvvpl5poaYknYrlEXN9YA1JwcX1PFhP5pueqFpnoFuJTp7E85Vzf3 XDUHkkaBM.sAX55tBOLpAsutMA1cDUFqgbEw6oWR.TvN.bIXmTWvDM1lYzWLLOpw4V9gY_I9GMQ- - X-Sonic-MF: X-Sonic-ID: 2e69fc3f-baba-4f70-a915-ae0d36e0e955 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Tue, 1 Aug 2023 06:42:36 +0000 Received: by hermes--production-bf1-7c4db57b6-wcllk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 01062b1ecdfa67f9dcea08f65f217b62; Tue, 01 Aug 2023 06:42:32 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: aarch64 lib32 vs. armv7 mdconfig behavior: "mdconfig: ioctl(/dev/mdctl): Inappropriate ioctl for device" Date: Mon, 31 Jul 2023 23:42:20 -0700 References: <49479F21-3CCD-469F-BF23-FF332D8EF0E8@yahoo.com> To: Mike Karels , FreeBSD ARM List , Current FreeBSD In-Reply-To: <49479F21-3CCD-469F-BF23-FF332D8EF0E8@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3731.700.6) X-Spamd-Result: default: False [-3.10 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-0.996]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; NEURAL_HAM_LONG(-0.61)[-0.608]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.148:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.148:from] X-Rspamd-Queue-Id: 4RFQXG59bKz3C8x X-Spamd-Bar: --- On Jul 31, 2023, at 23:22, Mark Millard wrote: > Not via a chroot'd context, but using the files from a > directory tree that allows an armv7 chroot: >=20 > # /usr/obj/DESTDIRs/main-CA7-chroot/sbin/mdconfig -s40m > mdconfig: ioctl(/dev/mdctl): Inappropriate ioctl for device >=20 > This sort of thing messes up the operation of the likes > of the /usr/tests/sbin/growfs/legacy_test logic: >=20 > #! /usr/local/bin/perl > # $FreeBSD$ >=20 > use strict; > use warnings; > use POSIX; > use Test::More tests =3D> 19; > use Fcntl qw(:DEFAULT :seek); > . . . > SKIP: { > skip "Cannot test without UID 0", 19 if $<; >=20 > chomp(my $md =3D `mdconfig -s40m`); > like($md, qr/^md\d+$/, "Created $md with size 40m") or die; > $unit =3D substr $md, 2; > . . . >=20 >=20 > Other ioctl complaints: >=20 > sys/aio/aio_test:md_kq -> failed: ioctl MDIOCATTACH failed: = Inappropriate ioctl for device > sys/aio/aio_test:md_poll -> failed: ioctl MDIOCATTACH failed: = Inappropriate ioctl for device > sys/aio/aio_test:md_signal -> failed: ioctl MDIOCATTACH failed: = Inappropriate ioctl for device > sys/aio/aio_test:md_suspend -> failed: ioctl MDIOCATTACH failed: = Inappropriate ioctl for device > sys/aio/aio_test:md_thread -> failed: ioctl MDIOCATTACH failed: = Inappropriate ioctl for device > sys/aio/aio_test:md_waitcomplete -> failed: ioctl MDIOCATTACH = failed: Inappropriate ioctl for device > sys/aio/aio_test:vectored_md_poll -> failed: ioctl MDIOCATTACH = failed: Inappropriate ioctl for device >=20 >=20 > For reference: >=20 > # uname -apKU > FreeBSD CA78C-WDK23-ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT aarch64 = 1400093 #5 main-n264334-215bab7924f6-dirty: Wed Jul 26 02:13:44 PDT 2023 = = root@CA78C-WDK23-ZFS:/usr/obj/BUILDs/main-CA78C-nodbg-clang/usr/main-src/a= rm64.aarch64/sys/GENERIC-NODBG-CA78C arm64 aarch64 1400093 1400093 Adding more examples of ioctl failure contexts . . . sys/netpfil/pf/ioctl/validation:clrtstats -> failed: Request with size = -1 failed=20 is actually at least associated with a ioctl use: ATF_TC_BODY(clrtstats, tc) { struct pfioc_table io; struct pfr_table tbl; int flags; COMMON_HEAD(); flags =3D 0; common_init_tbl(&tbl); bzero(&io, sizeof(io)); io.pfrio_flags =3D flags; io.pfrio_buffer =3D &tbl; io.pfrio_esize =3D sizeof(tbl); /* Negative size. This will succeed, because = the kernel will not copy * tables than it has. */ io.pfrio_size =3D -1; if (ioctl(dev, DIOCRCLRTSTATS, &io) !=3D 0) atf_tc_fail("Request with size -1 failed "); DIOCGETSRCNODES, DIOCRGETTABLES, DIOCRGETTSTATS, and DIOCRSETTFLAGS are similar and get the notice as well. The earlier aio_test examples are from: static int aio_md_setup(void) { int error, fd, mdctl_fd, unit; char pathname[PATH_MAX]; struct md_ioctl mdio; char buf[80]; =20 ATF_REQUIRE_KERNEL_MODULE("aio"); =20 mdctl_fd =3D open("/dev/" MDCTL_NAME, O_RDWR, 0); ATF_REQUIRE_MSG(mdctl_fd !=3D -1, "opening /dev/%s failed: %s", MDCTL_NAME, strerror(errno)); =20 bzero(&mdio, sizeof(mdio)); mdio.md_version =3D MDIOVERSION; mdio.md_type =3D MD_MALLOC; mdio.md_options =3D MD_AUTOUNIT | MD_COMPRESS; mdio.md_mediasize =3D GLOBAL_MAX; mdio.md_sectorsize =3D 512; strlcpy(buf, __func__, sizeof(buf)); mdio.md_label =3D buf; if (ioctl(mdctl_fd, MDIOCATTACH, &mdio) < 0) { error =3D errno; errno =3D error; atf_tc_fail("ioctl MDIOCATTACH failed: %s", = strerror(errno)); } . . . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Aug 1 08:25:39 2023 X-Original-To: freebsd-current@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 4RFSqn1JcKz4py6D for ; Tue, 1 Aug 2023 08:26:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.148]) (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 4RFSqX2p24z3MMg for ; Tue, 1 Aug 2023 08:25:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=teKQulOb; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.148 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=1690878357; bh=7r2Njw3yZjak5Gg0oYlfu1T1xASa5l9Lv6Wtqli7CCQ=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=teKQulObUujESI60Su4oGCWmeiJy4oxr8leeqIViTZCHSLBFcDw7mj3m5WZToOVzQ2lO5L3HmPPihFjJ/VEjIzuP3VaErvle9ces+TmXbXlNeCEyss8T7QnBWHH8Jbnoh+dC5pTGS2QdsmTg66f+C7cOqWqaYQgDo818z21jMXPrTL847OMJBWxV1LxQmswxR9vO/dWeXI3GA/g3bKuZ04Mamvm74Vqogl9Yjn/ITmbIkAfvzOPaEsjhqSEFJ66mEj/2n9CNUbUvqhXpUW2ahk2QyymsuB29lC8LU9jB+C/s44JirK1Lw9f3XH6r3TPTAFhfNXOF9fwz9b4jmHY90g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1690878357; bh=13yFiuTbnn5UDIYLbVuxzw9YqY9fE0tBrjqOwlscMCO=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=FfZ9SN/IAO3Qk1NVzQt2z1PHXE9gmgx7AI2ROp3sp3BRTjZPWG0VB0G3txDQLsa/ZO75H2esnwO/nZzVPNq07DI/7203fLqNJvxAWCkc4AK8UXKoBMOweAbrt/bDEK349LPXkKGg2QtvspnTRStQ5D+Mj8YlSDJW3YrLprN40smKSoQzNA1jr06XE3YF3Lz0GB/xfLKgDx8p/07QPCVfNzM4dPWaYipyhOrN2/1Rme6h4WNToj/2R7vFR2ehiUhNAU4P5sK1Lp1Z2x5q79CtOETQRU73ad/MCBsEAXYSdE8Zfi0fBasUhzr5vCYLZLF2ZNSn+k2HJ2P+fNQx1VZAIw== X-YMail-OSG: j22BC5YVM1kahSVwpRpzyZiREhBbSEWznR7TVf2RH4LnhxeSp.x9F.ZOgvFiHZZ X5IHbLtcFGF1JhGdZMHDIKzQiMIK8lF8Dexd970n4nEuo6P2NFqC.FKAOxFOLDvJuGdYUZfDqvWI TYBu5TsZdNOhOV.7zOUgJcUmz5w_wydqDFR6y3nzItpUpb3BMuuvXGxAOn9r1hMOyQQdWCEwtU06 txC4bIQbj13MDXuEr4J8fIKxbR.R1YVLR_Ev2kVBsYFCl1HvwrhXvJxqDOcd7GjcapsRgsfye4PJ aSI8EvlqGjV6F_S5P7NtmhKS_tOX._dDB5byZyt9MtKyJUQBM11bAuziDVLszAvyRK.KCpcARhyb utWTmQl109fSgzD66EpodrW0G8NETdnBQM0uFBsacxSrTll0EeoKy.LSHN44qTcUMg3Ks8U5refC NSz2w1f1EUCCqrMhYTakBkoktlEOjffvnxTclTL08Pb5bcuGAdGzD_FPE18RCTv5xXpEV6kE1i5c YY7JQd.nWuzAxYsgn2Q7CGml2TDsyTFZosEzZtN9KIAROifUZIXwNHpPrF_ajyliUHLsva6sWTV. 5eaWIptdgzroGJLiOGmUXIwnMDPEWHU51FnAXkE8bFDuVGW_t0HsFEaTX8hcrRDM8CitPAgWz0j6 KFwPtBrRlQZn2o823ViNN2K6U143KairyYkWFjUdkQX42FRCkB1ibbrTkObsAcwF5vYoDN3MXBlz l.3z4BRnLnTtmfTupaJ923hXJVtpauo_xKDi5Pc6xNR5gruCaY_a7MKwRPRDQrFfP8EbYgTwmlBn 3smLOS5_gruFqKL0thYmi2oKxNj6vGLECJvfXjWexqa5njDMpOor2JqrfL5qHkTu9Y3W.J4reU5_ MnAABiMj9asBCxw.mnle1skgwMLtc4hSG_VTM1.p..cEg96rP.qkJ0NznOty25x.qAm1k1OH7Wy6 j7KrVMhS2aGSdd1ue9wqXapkyP9wIbUjyFDa9IJks403MA4BaMMxkIqcfQkkrIRubIy4ojYpMN1a lu8eUz4biy_0cR0U96LcHlsFOMFFJy0TvFDvaYZu.nF3zLSBDTM4ZtdC_vi7273j5SHYELjTjlyS lClMxVs6wlHbbHXHA6LSt3k8lLPM67v.AOcmex3Ofhkvs4A4xCGVgKobNfninTUUjVNHaKEiJyKr hNY3.5YDP.JSQKKlrveWTRQNsTnWjHrN_tC8tjXA9xMygeFqfwwTh3IfZ5QegwLp65xlsbCLi05k tJWNURVCvbyfbF7lFVyQEoH1ZWtX2O5rALBixaz_RcwQLhTDhmYFgeI4ypAgUjtbk0lbQijHmUOU T0hNmyktKjmIkvHc1USi7ioRzCgTsQv0dndKn0cZH04JEFodTPkyYS4njpzh6pbDYW8rlzap_oaL 9kO63sD5bOF5j3vHO.g0DW6bjp9o7DNrnP0R5cYeMTaYQkWdtMwsozbUtCUko4irzOJAHaxUVG26 UpdMOTLuwVf_uxTxFWkP61tPtuKu_XObIPCQKxz6lCVrjB8E9NPGGMwsbpoxAboIETJKkomYIDKE c5vurTpfQn.2sc7cRRL.SWUwJ4.xoouaoHIF5BgsyIt6Ydc0ONwlMnOVvGQYH_RTmG76T6fhp3eo 33YwtGRPANw.kdc222BC9iBmj7IPqXMCelduwQ0ZPUCITDKH0HLxCQlsJ1q.mYCQM8DM.pU_n8.H uqqgYEBY0hJdbSKxJcmsV.7ULDyfXnkLPmJJxnqJKUau3t2lqv9U08ttMK5HA_IJi5gNKcaN3mNs 3cCEbSw0hJ6i6NlZ1wE4GR609P_kTYkuYNfM1BCYLSB6qVw1Pps4B29QBlFcU81nVBYe_92HrFPJ 5idke.lNhlUhOWudpBPLhDA7j24AdZ5U3YGAofsB7jXUClZzA9LhMboaLE6JDEfR1jMnuXR1xX_G vLtij3DvJLrq2iv8vGmQowSjaeUGwJ6w0dI1IKfpIYFHK2syOe29fAcKKDOPDMdZVvGHhLP3oSbL 2n_V2SXUSLbnp0U36nkju3CJG.i1yeCERab.OsajwPUErNE9IrJbfvGlRQGmBgwj5.MV.FVImPA1 ypu01mibR7GwxfIqHXgVtZLZmdEqn3T.PfPL.TLGL9bbvSSoISB26esfwaM2B5ob5KwoGu2pbPtu nfFtRVcjLv6eKJZzgIqdYh7IxxdW2bYTMg5S5SZSHOesf6wXZr9C2agSunbT6fgWtpumgVHwjwzg mBNWMPoOEC90OrlzFTJjQ_uydSJECuq7qwvMPRfdReQsFb7fET432.hJxQfBAGIX3Dx6Use6Krg- - X-Sonic-MF: X-Sonic-ID: b810b3a2-32a4-4997-bef8-3fb0fed15858 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Tue, 1 Aug 2023 08:25:57 +0000 Received: by hermes--production-bf1-7c4db57b6-87g95 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 389e984e1a39be2279f616d41f7b46c1; Tue, 01 Aug 2023 08:25:51 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Some results from my crude technique of using (some of) Kyua to test aarch64's lib32 vs. kyua runs in a armv7 chroot on aarch64 Message-Id: <84EFE4FC-D8E0-41C0-AC10-D1DBE2262F6E@yahoo.com> Date: Tue, 1 Aug 2023 01:25:39 -0700 To: FreeBSD ARM List , Current FreeBSD X-Mailer: Apple Mail (2.3731.700.6) References: <84EFE4FC-D8E0-41C0-AC10-D1DBE2262F6E.ref@yahoo.com> X-Spamd-Result: default: False [-3.20 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_HAM_MEDIUM(-0.99)[-0.989]; NEURAL_HAM_LONG(-0.71)[-0.710]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.148:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.148:from] X-Rspamd-Queue-Id: 4RFSqX2p24z3MMg X-Spamd-Bar: --- [I first report how I tested before reporting on errors that look to be valid kyua reports of issues.] [This testing is with a line commented out in order to prevent sys/net/if_bridge_test:gif from being tested, because of its leading to a panic for lib32 style testing.] I have /usr/obj/DESTDIRs/main-CA7-chroot/ containing an armv7 installworld distrib-dirs distribution DB_FROM_SRC=3D1 result. It also has various ports installed that kyua runs use. I use this tree for both the lib32 and the chroot testing. I have a script to preload various kernel modules: # grep kldload ~/prekyua-kldloads.sh | sort #kldload -v -n ipfw.ko #kldload -v -n pflog.ko #kldload -v -n pfsync.ko kldload -v -n bridgestp.ko kldload -v -n carp.ko kldload -v -n cryptodev.ko kldload -v -n dtrace.ko kldload -v -n dummynet.ko kldload -v -n fdescfs.ko kldload -v -n filemon.ko kldload -v -n geom_concat.ko kldload -v -n geom_eli.ko kldload -v -n geom_gate.ko kldload -v -n geom_mirror.ko kldload -v -n geom_multipath.ko kldload -v -n geom_nop.ko kldload -v -n geom_raid3.ko kldload -v -n geom_shsec.ko kldload -v -n geom_stripe.ko kldload -v -n geom_uzip.ko kldload -v -n if_bridge.ko kldload -v -n if_epair.ko kldload -v -n if_gif.ko kldload -v -n if_infiniband.ko kldload -v -n if_lagg.ko kldload -v -n if_ovpn.ko kldload -v -n if_stf.ko kldload -v -n if_tuntap.ko kldload -v -n if_wg.ko kldload -v -n ipdivert.ko kldload -v -n ipsec.ko kldload -v -n mqueuefs.ko kldload -v -n netgraph.ko kldload -v -n nfsd.ko kldload -v -n ng_bridge.ko kldload -v -n ng_ether.ko kldload -v -n ng_hub.ko kldload -v -n ng_socket.ko kldload -v -n ng_vlan_rotate.ko kldload -v -n nullfs.ko kldload -v -n opensolaris.ko kldload -v -n pf.ko kldload -v -n sctp.ko kldload -v -n sdt.ko kldload -v -n tarfs.ko kldload -v -n tcpmd5.ko kldload -v -n xz.ko kldload -v -n zfs.ko (Some I've listed despite there being built into the kernel or already being loaded for my normal environment.) Likely I'll end up adding some more later. I have some ports used by kyua runs that I build and then install into /usr/obj/DESTDIRs/main-CA7-chroot/ : # more ~/origins/kyua-origins.txt=20 archivers/gtar devel/py-pytest devel/py-pytest-twisted devel/py-twisted lang/perl5.32 lang/python net/scapy security/openvpn security/sudo shells/ksh93 shells/bash sysutils/coreutils sysutils/sg3_utils textproc/jq Likely I'll add some more later. The above, of course, lead to other installs as well. For lib32 testing, I try to control where most *.so* 's that are not based full path references are found. This is via use of LD_32_LIBRARY_PATH . I try to have more programs that are not based on full path references run as armv7 code. This is via use of PATH . So: # env \ LD_32_LIBRARY_PATH=3D/usr/obj/DESTDIRs/main-CA7-chroot/lib\ :/usr/obj/DESTDIRs/main-CA7-chroot/usr/lib\ :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/libexec/rtld-elf\ :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libxo\ :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/csu/dynamiclib\ :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libc/tls\ :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libc/stdlib\ :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libthr/dlopen\ :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib\ = :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages\ :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/lib-dynload\ :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/perl5/5.32/mach/CORE\ :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/perl5/5.32/mach/auto \ PATH=3D/usr/obj/DESTDIRs/main-CA7-chroot/sbin\ :/usr/obj/DESTDIRs/main-CA7-chroot/bin\ :/usr/obj/DESTDIRs/main-CA7-chroot/usr/sbin\ :/usr/obj/DESTDIRs/main-CA7-chroot/usr/bin\ :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/sbin\ :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/bin\ :/usr/obj/DESTDIRs/main-CA7-chroot/root/bin \ /usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua test \ -k /usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/Kyuafile On the Windows Dev Kit 2023 I end up with the lib32 summary being (so far): # kyua report --verbose \ = --results-file=3Dusr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230731-08082= 0-275974 \ 2>&1 \ | tail -6 =3D=3D=3D> Summary Results read from = /usr/home/root/.kyua/store/results.usr_obj_DESTDIRs_main-CA7-chroot_usr_te= sts.20230731-080820-275974.db Test cases: 8704 total, 1442 skipped, 37 expected failures, 46 broken, = 746 failed Start time: 2023-07-31T08:08:20.858437Z End time: 2023-07-31T10:18:37.393732Z Total time: 6954.365s Of course, some tests labeled as broken/failed are just from the limitations of the techniques involved lib32 based kyua testing. For example the 127 "failures": In the chroot it is currently: # kyua report --verbose \ --results-file=3Dusr_tests.20230731-163737-720329 \ 2>&1 \ | tail -6 =3D=3D=3D> Summary Results read from = /usr/home/root/.kyua/store/results.usr_tests.20230731-163737-720329.db Test cases: 8699 total, 1478 skipped, 38 expected failures, 200 broken, = 664 failed Start time: 2023-07-31T16:37:38.302188Z End time: 2023-08-01T06:57:18.663231Z Total time: 50619.428s To generate files to diff lib32 vs. chroot results I used for lib32: # kyua report --results-filter "" \ = --results-file=3Dusr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230731-08082= 0-275974 \ 2>&1 \ | grep " -> " \ | sed -e 's@\(.*\) [\[0-9.s\]*]$@\1@' \ | sort -u > ~/kyua_lib32_aarch64_armv7.txt NOTE: That strips off the [TIME-IN-SECONDS] suffix. For inside the chroot I used: # kyua report --results-filter "" \ --results-file=3Dusr_tests.20230731-163737-720329 \ 2>&1 \ | grep " -> " \ | sed -e 's@\(.*\) [\[0-9.s\]*]$@\1@' \ | sort -u > ~/kyua_chroot_aarch64_armv7.txt NOTE: That strips off the [TIME-IN-SECONDS] suffix. Then I did the diff (from outside the chroot): # diff -u ~/kyua_lib32_aarch64_armv7.txt \ /usr/obj/DESTDIRs/main-CA7-chroot/root/kyua_chroot_aarch64_armv7.txt \ | grep "^[+-]" \ | sort -k1.2 -k1.1 > ~/kyua_aarch64_lib32_chroot_armv7_diff.txt I later swapped the first 2 lines to get the -then+ order there as well. See the 1021 lines at: https://gist.github.com/markmi/37400c797bc94e5670622bb36919964e There are interesting differences, such as many sys/net* tests for the chroot context hanging up and timing out after 300s but lib32 having many of these tests pass instead. There are other types of tests that chroot generally has the passing status and lib32 has the failure/broken status. One thing I've noticed is that for lib32 some of the failures trace back to examples of "Inappropriate ioctl for device" or other ioctl behavior differences. I sent out a prior notice to the lists for that. There are examples of -/+ line pairs that only exist because of /tmp/* paths that are different in the text of the 2 lines. So the overall line count overstates the differences by some amount. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Aug 1 17:12:12 2023 X-Original-To: freebsd-current@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 4RFhWp6006z4pdvJ for ; Tue, 1 Aug 2023 17:12:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (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 4RFhW434sfz4NJ7 for ; Tue, 1 Aug 2023 17:12:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Ftk9kxdw; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 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=1690909949; bh=RtGKRq3HolSNhZFf4oRxvkzjBx9g6SsdopTRX5hch6A=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=Ftk9kxdwFFdJdeXTr25sw/fij3PK7l4TYLdto4mclgWem4t8EeUvaAKTIdzr+JYP21KjV2J0l2eDFF+X9cS1nWgi6wuo28N89FjYFBNw7/wvvqOwhGuEP3PX7Wds9ZYg2oabLOX6ueEdW/ROySaTwAVXDi477LmumWgSDwd5URp+kzM7e3yaKacVOxiW9z5zzPivlua28Mf++OADx0p3FG/YT0naZU+xb8QvB5fkTs97bnnMbVLJCDbNuhfcLdxEaj5mL/ZP5BsXZr5GYp8iWN0qaxAwBaS8BYhoWb1G1vm7cvn2GVy+Iuhg9os4uUm4Vu1HWBY7HBse496GjIsZ7A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1690909949; bh=r8YWbURrlXhrK/SiXLBiPoFvFWAZOgvjMOa6xnv3A0s=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=M2E6gplTdrTjaZP4Ta3psPLPXt2bgwpC/kX/sq2EiGm1XrcYC1NR2k4CgfshPYZNOD0w+83lPcoshU3TZL1TOvv35MSzUgBdawcWCp3pOexJxE77CzmS/jgjN+C+y+tw6wYJAQ2LM2RW52ihXfaeEhG/oHTLOY0Vhzmhim15qwxMDLUViYFTtM3pIJtPugamOs5qb72h6iy34JFVjmkfI/FlQ+RyIeXSeBL5iPobJ+FUyAOQ3R3mOHPHE3adUTvD0fXC2mAoVE7PIDEuyHfI6mkzyC7udQzZ+gZFcbpqqgPcALSHBrhtbNOvtxw9uWYAI7motDzjgylUvPuK4MK6ng== X-YMail-OSG: 1w_z.F4VM1k5gU2pQcvMeE8YKk0KVZ7rLF9xCS6YL25Xy64bggH0RRHbMZcxZMW JP1pUf4BwBxJmjTiolc0FimiZ4SP_VYcbDt1XHV7H7kjOBsI5ZsF6tkoaOIyrI0aZvwVfx3lIg6D E3E0vN6H2LWBGH9SaPbUpTstCB9_VuFRUzz0NMyOsaO9azjgkUkTyPnW1rRCGImJAAqBeDk_WNrG Zd7gNuUWW3ONrKyFO0BRYX7BVsZnoumsX.7z0H9yCGmD6VFKYJBwlSyz1AeQCVnRf2jmEzhOoed. CixV.F8cMJPRnPFcYzL8RH.J.A9gvPdCZnkghj6EliQ4e7ZiT0aXKbojsDTFEgZMu17cTr16M40I 2sQzkAY7cIbu0XBr4EGE0smdgMWOLh5n7N5ONGbgu.WayetOYfwO5._Q9STeRvrxhF8e7hLfpagj RsK7gCVVkdwKe2N_Jp8w5ZwREDRtEIY8jjmYqBiE9MTo3mbNfMu6zCuiuwajfHaeUeIIK6yu2805 cFGCYolBSSVRlu_t4b5xSxDL.UBZSBGv6Cyeymy2sZhYJC4D_uVXVbIiTJuLjjYZ4YZDhbv0_KO3 XzUqZ7yVcJaEeGSLBws08AqBl1qtayqsQGk2vgsNW5RB3fd9b8JWxbiYx8lNSWVeON78md5aRoEO 1tm6dJBjeJrmbQi2Swk6uBenkxuanuFQ7Tj_hUNqmKB3Cf2q64B50pFVPLASuZW8boxDOpDsq_YG UKpFgJE6vbW0pbdnQvNrWMYedxkW.Bzr4njccy1t9ILGvJZ4T9NJOH5zdU5cu0SzgR3GZoImmJTV sE3xBUnsUG3zdWvflJYyjQygcLpIopyBitedHeaCwEDs8tOlufxfY2bpKPmf91MuOvC2Fs6Hkpwd _0Jws_SCZHL2aKyKF8Dx5LqayENlpLGq6vZHLsglsUwLnHd3Z_jwEb8_LGH2t.sV42PAkQtxwx_e MZJt3U.xyo2hyeXEuWheshzcjUzLnPlDeUjeJZLwpGJXgq6LDbGPyQ2SBB.0wwcqG03l28LFrVqV AP2j3anMujeBa0kP1z_UHN3TV0CWcrtSWVdo188.Cr2mBLU8ncqUO2snoi1b1BuRxu48_.FHAD1v pRJwu4gVZ.PnXf.MK5oNsx88ngecajR2nCeX2NUDOOkKemu2EYdUdnabXnyjkEQevRHM2xtZbhcr Ewf4NTYaVi1OXxvFN1qTXNNVRufhRsOOWbw8Til3_B6XeoHfSi5YmSERVCkqLK9JjKIAfiZudkW. TUXJN.iS.ErLr1AkgzItxquSZe03M1xaDhFKDrCWiMI2kiiVgprAtnvqzDP.Ba5ppCeNDI1A6LYn x2B3BOc4lAZojtA9NbJrPBelMZCNm9tWbVsEUkcV14nsj4485GtlQk96GE8oYmnsm8JwF6dqKJl7 ELkaUMZeHYSPQPjw8bfvUDojlp6sf..BjSUX2JhrOxlmBhBTLjVN.iZ4npuTAEceauniVc0ui277 WsHfWpzqLxa7DFAKVktxQXaCCgaBSd8JLyAeyO9OHnTQJul43MTeRIf7dM6BQj54fhbjZLhxriAD KDZe9mqpCrLSw44pk_AdazqcZe0lBDVQdF35ACx0KCwZC7Hzvpd2tRMMmv4SU60RfDMtAuo7USV3 whWwT1FdbrY01kKAPfwNR5adtttpwYopF40MyzMCJWCBX4926DwgQP1m_tG7IOxW.UoEGp2jPGyu ii70gPl5QgEi9mBOtPm5XlfSxMzIjOuUUP3wCkQrq0PABU5Lk0iBzdDGiiuqi90SVyRjrh7HG3KG bhvNL1W3Tu9.2koUaCTqPW.5BQxYgtfj01c69a3qL1QTjGvGXV9MEV.0Q3XKTs0EhGDgR5rHQ00P SF1bfQguNS3JrlHSxwvZLfC_sTKNiz7bhqj3TdMMEGq6re6D8jfWLQyatf.6OzXXZ6STf_Iv3KK1 luLG2JURGzS_zLQydOnAfwycdz0SoT_11HRSeW20kQ2N0w.OvpZgwlpepr_j024g_qeKYsifomOP LofLuV1icnt8XiUD8XwHbT.Gr4B65dyyRLGKXw5aUnWX8Liq.p0ltMpN1109YzgVcJvC2oVdZDNf u8fxd1N3767yWOhb1_PAaRaBkcs9vdytxeXLSeSRWhEKsRIDkEu.8yyTsCPk4bAd215s9ryd_kgy L6p1ZWQBHtqSW3rfeyItrdSIKDSD3Ze6nU42Afh3bU6iKbXFsviYUwY1d_8c2KI9ADSWG6ZyOAAn Hzj4SaE2qcnUTXZpaHrh.7Ma.I5PUL9buF6AJPLt8BOkJXi21O9FXxyoyEuKUEK0Wo62rdhWG3k. RiQ-- X-Sonic-MF: X-Sonic-ID: aa73251d-4777-4026-9fee-c827283a6e06 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 1 Aug 2023 17:12:29 +0000 Received: by hermes--production-ne1-549c7f6c44-c7r4q (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 882422d1e25e66c73e15c57108bab52b; Tue, 01 Aug 2023 17:12:24 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: aarch64/armv7 via lib32 and via chroot: db_test:btree_byteswap_unaligned_access_skbd gets bus error Message-Id: Date: Tue, 1 Aug 2023 10:12:12 -0700 To: FreeBSD ARM List , Current FreeBSD X-Mailer: Apple Mail (2.3731.700.6) References: X-Spamd-Result: default: False [-2.12 / 15.00]; NEURAL_HAM_MEDIUM(-0.99)[-0.987]; NEURAL_HAM_SHORT(-0.60)[-0.596]; 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]; NEURAL_HAM_LONG(-0.04)[-0.041]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from] X-Rspamd-Queue-Id: 4RFhW434sfz4NJ7 X-Spamd-Bar: -- I do not know if the unaligned access activity in the likes of: db_test:btree_byteswap_unaligned_access_skbd is some form of FreeBSD requirement or not. But, for armv7 activity, it results in a bus error (and kyua test failure). Probaly also true native armv7 operation. =3D=3D=3D> lib/libc/db/db_test:btree_byteswap_unaligned_access_skbd Result: failed: atf-check failed; see the output of the test for = details Start time: 2023-08-01T09:07:38.975390Z End time: 2023-08-01T09:07:39.006220Z Duration: 0.031s Metadata: allowed_architectures is empty allowed_platforms is empty description =3D btree: small key, big data, byteswap unaligned = access has_cleanup =3D false is_exclusive =3D false required_configs is empty required_disk_space =3D 0 required_files is empty required_memory =3D 0 required_programs is empty required_user is empty timeout =3D 300 Standard output: Executing command [ = /usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libc/db/h_db -o out -i = psize=3D512,lorder=3D1234 btree in ] Executing command [ = /usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libc/db/h_db -o out -i = psize=3D512,lorder=3D4321 btree in ] Standard error: Fail: program did not exit cleanly stdout: stderr: Files left in work directory after failure: h_db.core, in, out For reference: Reading symbols from = /usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libc/db/h_db... (No debugging symbols found in = /usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libc/db/h_db) [New LWP 102818] Core was generated by = `/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libc/db/h_db -o out -i = psize=3D512'. Program terminated with signal SIGBUS, Bus error. Invalid address alignment. #0 __bt_pgout (t=3D, pg=3D, = pp=3D0x4060651c) at /usr/main-src/lib/libc/db/btree/bt_conv.c:174 174 P_32_SWAP(p); (gdb) bt #0 __bt_pgout (t=3D, pg=3D, = pp=3D0x4060651c) at /usr/main-src/lib/libc/db/btree/bt_conv.c:174 #1 0x401468ac in mpool_write (mp=3D0x40610000, bp=3D0x40606500) at = /usr/main-src/lib/libc/db/mpool/mpool.c:406 #2 mpool_sync (mp=3D0x40610000) at = /usr/main-src/lib/libc/db/mpool/mpool.c:329 #3 0x4013d548 in __bt_sync (dbp=3D, = dbp@entry=3D0x4060b000, flags=3D) at = /usr/main-src/lib/libc/db/btree/bt_close.c:146 #4 0x4013d35c in __bt_close (dbp=3D0x4060b000) at = /usr/main-src/lib/libc/db/btree/bt_close.c:80 #5 0x000221b4 in main () =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Aug 1 17:46:49 2023 X-Original-To: freebsd-current@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 4RFjH46fy9z4pgFM for ; Tue, 1 Aug 2023 17:47:07 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) (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 4RFjGw5Q01z4Sfw for ; Tue, 1 Aug 2023 17:47:04 +0000 (UTC) (envelope-from ctuffli@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of ctuffli@gmail.com designates 209.85.217.46 as permitted sender) smtp.mailfrom=ctuffli@gmail.com; dmarc=none Received: by mail-vs1-f46.google.com with SMTP id ada2fe7eead31-44768034962so1531280137.3 for ; Tue, 01 Aug 2023 10:47:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690912023; x=1691516823; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=jpPx0Bfh6a79ho7R4/l2eC5QA+KS4t0bFXvjLZo7cYk=; b=NnZ2Hn40cOe9R7MhtE4Nw52C1QGmAx6SfWom/6flC0N6e13l5FIqsjBVKRkPljcpCE zfFByjCJ1pSSIl2Hi8Pu2f5yeL3z0l39dmhArKAKlyuTPZTDO/+tlrPERGufcbUJZLqL Ncu7oya3rmAmAbUV3nVlTxbt9JdnQi51fdQD9BZrNa192FehvxMgpqOaSi+MX4nibZwa 5mT/cS8T29yPuILP1Q9sUeWtDF7oaNEsb1iHLBuPc7X9OIch8XnUj3oZez5slmlFHEqU c7fqakXqK38u+iefc0KzrF+1PdlckTWLENSxTTIAtd+LWdA9hr3pgjM/8/fPCRDH+F58 1dHw== X-Gm-Message-State: ABy/qLYkCC5zBrhYerdwFz5zo5hdvxdDI0vrrml3wJG2eQcXvClXvanW kvho7npUb7M2aNCgfJhg7BSqNpbC/aA= X-Google-Smtp-Source: APBJJlGD7ESWeZe184f0f/tOQ1jkwFDOfDsxPfDycOXhtRsl0B29wnyuWK98jSR2WXoT3xQfijTFyg== X-Received: by 2002:a05:6102:a35:b0:447:4f20:c79c with SMTP id 21-20020a0561020a3500b004474f20c79cmr2261082vsb.12.1690912022939; Tue, 01 Aug 2023 10:47:02 -0700 (PDT) Received: from mail-vk1-f180.google.com (mail-vk1-f180.google.com. [209.85.221.180]) by smtp.gmail.com with ESMTPSA id u2-20020ab05b02000000b0079a01ecb0a0sm1680827uae.38.2023.08.01.10.47.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Aug 2023 10:47:02 -0700 (PDT) Received: by mail-vk1-f180.google.com with SMTP id 71dfb90a1353d-486519e5da0so1937118e0c.2 for ; Tue, 01 Aug 2023 10:47:02 -0700 (PDT) X-Received: by 2002:a1f:bf4d:0:b0:481:2d01:867f with SMTP id p74-20020a1fbf4d000000b004812d01867fmr2437912vkf.3.1690912022480; Tue, 01 Aug 2023 10:47:02 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Chuck Tuffli Date: Tue, 1 Aug 2023 10:46:49 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Can't assign address to igc To: FreeBSD-Current Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-1.31 / 15.00]; NEURAL_HAM_LONG(-0.99)[-0.994]; NEURAL_HAM_MEDIUM(-0.97)[-0.970]; NEURAL_SPAM_SHORT(0.66)[0.657]; FORGED_SENDER(0.30)[chuck@freebsd.org,ctuffli@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[209.85.217.46:from,209.85.221.180:received]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[chuck@freebsd.org,ctuffli@gmail.com]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.217.46:from]; R_DKIM_NA(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DOM_EQ_FROM_DOM(0.00)[] X-Rspamd-Queue-Id: 4RFjGw5Q01z4Sfw X-Spamd-Bar: - Running a recent-ish version (n264266-8f8da1bcc799) on an Intel NUC (RNUC11PABi5), assigning an IPv4 address to igc0 doesn't work. There is no error message, and this has been working in the past. Looking through dmesg only shows: igc0: link state changed to UP igc0: link state changed to DOWN igc0: link state changed to UP The address is set in rc.conf: ifconfig_igc0="inet 192.168.5.10 netmask 255.255.255.0" And manually setting it via # ifconfig igc0 inet 192.168.5.10/24 up does not work either. Any suggestions? --chuck From nobody Tue Aug 1 23:33:16 2023 X-Original-To: freebsd-current@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 4RFryt6QRLz4q11W for ; Tue, 1 Aug 2023 23:33:30 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-oo1-xc2a.google.com (mail-oo1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (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 4RFryd6zJzz3mJ6; Tue, 1 Aug 2023 23:33:29 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oo1-xc2a.google.com with SMTP id 006d021491bc7-56ca4d7079aso2312666eaf.0; Tue, 01 Aug 2023 16:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690932808; x=1691537608; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+Gs09JfHRKH+QEve/edjtuZNHhDcggtZKq4pvyRrx4g=; b=bYvaCsuS9dRUpSHSY6HFwY/nikgmWHTr9JuIMMxUFpn0N2KuRgdT2d2y5lUdMdyfk1 xNPdvwOY4RkVPs1XIyJjTETvXbffpSDMZdio0KQFMvzsX3/3fxSAaAAHAnN1KRy9bNwL NeSQWlVQ2QcjG2zPFd9k8E0tXZ+dmDeUkofdzD61Ooc5o92KNg5Q5Q04X3H9ZRSyN6Ug qQxuRjw1TyuYdfWb1TnIV27r11edA4IQkN1Uxgxbj1JTKBDW5vF2BvZ1vCri0KxvhB56 zeB53rE281CMoJ1MPLGj/y11hTXJRB2xIpsphV2bHpJnokvBz4+1Wka8zBJ07JUgSfb6 cn4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690932808; x=1691537608; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+Gs09JfHRKH+QEve/edjtuZNHhDcggtZKq4pvyRrx4g=; b=PHzH0x6UJysHyMRdePxDNxeaq/hReYkw1pl14xsR3NO/RpyCpWirC5OKVBMcKo8mfD 3JDKBGzp2Uh3dq8cxjc8v8AcI/5qi9AEBlJjO2peqmPlOTbZ0ihtKXHp3fDWvMehkwsp /Mkbl6b6PJ9ieCmtcw9k2DLTpY3vc/Sh+V2v0LkJP0YtzWQcgVpnvwk5chzJi1lEPLIB 4vKDrRD+NW2HBu5GURwtKIyZbdR6GH5Tdv4D+FpTqDGE7m1El0e0VwAF0wF9uayA84pZ e4emLqdHIDojccmIZE+c/CNoQ4t21O4TeQJcOf2GM4L3sWL3PisqH43HGnPFca6hzoDF 35Ig== X-Gm-Message-State: ABy/qLZAWSMOTz8u/koezkKGaRSCEZWg1P+peLRPIOrG0Sy0/gT9TxvI lVQRdFi4AELvne9anKfk/1E8Txioa8v2+PZ994JqSC3GHA== X-Google-Smtp-Source: APBJJlErtWNCaVfqknb8yWvEoSONcwRK5qIO8F17Go092uCsC7G7EUWqOZLGDSJFyTGNPGgxErr8MPIPDpBTwaO1g24= X-Received: by 2002:a05:6870:4182:b0:1b0:2f70:15a5 with SMTP id y2-20020a056870418200b001b02f7015a5mr15574670oac.52.1690932806999; Tue, 01 Aug 2023 16:33:26 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Tue, 1 Aug 2023 16:33:16 -0700 Message-ID: Subject: Re: Review of patch that uses "volatile sig_atomic_t" To: David Chisnall Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4RFryd6zJzz3mJ6 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] On Mon, Jul 31, 2023 at 11:33=E2=80=AFPM David Chisnall wrote: > > Hi, > > This bit of the C spec is a bit of a mess. There was, I believe, a desire= to return volatile to its original use and make any use of volatile other = than MMIO discouraged. This broke too much legacy code and so now it=E2=80= =99s a confusing state. > > The requirements for volatile are that the compiler must not elide loads = or stores and may not narrow them (I am not sure if it=E2=80=99s allowed to= widen them). Loads and stores to a volatile variable may not be reordered = with respect to other loads or stores to the same object but *may* be reord= ered with respect to any other accesses. > > The sig_atomic_t typedef just indicates an integer type that can be loade= d and stored with a single instruction and so is immune to tearing if updat= ed from a signal handler. There is no requirement to use this from signal h= andlers in preference to int on FreeBSD (whether other types work is implem= entation defined and int works on all supported architectures for us). > > The weak ordering guarantees for volatile mean that any code using volati= le for detecting whether a signal has fired is probably wrong if if does no= t include a call to automic_signal_fence(). This guarantees that the compil= er will not reorder the load of the volatile with respect to other accesses= . In practice, compilers tend to be fairly conservative about reordering vo= latile accesses and so it probably won=E2=80=99t break until you upgrade yo= ur compiler in a few years time. > > My general recommendation is to use _Atomic(int) (or ideally a enum type)= for this. If you just use it like a normal int, you will get sequentially = consistent atomics. On a weakly ordered platform like Arm this will include= some more atomic barrier instructions but it will do the right thing if yo= u add additional threads monitoring the same variable later. In something l= ike mountd, the extra performance overhead from the barriers is unlikely to= be measurable, if it is then you can weaken the atomicity (sequentially co= nsistent unless specified otherwise is a good default in C/C++, for once pr= ioritising correctness over performance). Just trying to understand what you are suggesting... 1 - Declare the variable _Atomic(int) OR atomic_int (is there a preference)= and not volatile. 2 - Is there a need for signal_atomic_fence(memory_order_acquire); before t= he assignment of the variable in the signal handler. (This exists in one place in the source tree (bin/dd/misc,c), although for this example, neither volatile nor _Atomic() are used for the variable's declaration. 3 - Is there any need for other atomic_XXX() calls where the variable is us= ed outside of the signal handler? In general, it is looking like FreeBSD needs to have a standard way of deal= ing with this and there will be assorted places that need to be fixed? Thanks, rick > > David > > > On 1 Aug 2023, at 06:14, Rick Macklem wrote: > > > > =EF=BB=BFHi, > > > > I just put D41265 up on phabricator. It is a trivial > > change to mountd.c that defines the variable set > > by got_sighup() (the SIGHUP handler) as > > static volatile sig_atomic_t > > instead of > > static int > > > > I did list a couple of reviewers, but if you are familiar > > with this C requirement, please take a look at it and > > review it. > > > > Thanks, rick > > ps: I was unaware of this C requirement until Peter Eriksson > > reported it to me yesterday. Several of the other NFS > > related daemons probably need to same fix, which I will > > do after this is reviewed. > > From nobody Wed Aug 2 08:12:06 2023 X-Original-To: freebsd-current@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 4RG4TZ16HCz4qPgZ for ; Wed, 2 Aug 2023 08:12:28 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RG4TH72wjz3H00; Wed, 2 Aug 2023 08:12:19 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1690963940; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VRfpbFpba+aFanVU03R3qG5yUbt/f0sJViScGxYkRyA=; b=iE4Sv+UAmE14EUhY9VB/UJnDxkcO2PENs4KxVtHnt3QhzmNhXoVG5DOLZHJzccFgs+3Q7L Y2+oJTb1zzkTttHHK/tg+Pa3EZ38W2qix8fLyesbX+XIJ1P+G6kJQpQ0llIGSY9okst5vp gWRdMKJ/PMjZmmcymE9GIPYk0Ua+iB+dtC+oVOtSWfPxZRNui574HNSVVA8POMIfo0d0FO h+jX/iO8/CreH2Fcswwkrt0URJSgIuwXMRb+OFfnHdo5fUZ7uxoA7qlX/X5DhrLt/ig3iq QYNix+qPs9VhlC/c91A7jBKD24+bn3jfBhEqyKNb1m0yEzLEN6KyivZnTCxIWQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1690963940; a=rsa-sha256; cv=none; b=elbdiIcqV8ud5PWpePh/FM6Fgk7NQ5BxAje23Jek+qdJ5jhmhaneaeNtbiJD1UlK81CsN3 bZvyP8TyXOCJy1uJf37dolr0DAXyjI0vLd4O9mt9eeawG78Wrgmq+z6AoVJ+Z35C9tHTqB IFJwP1JB2B61WQP5CYkWGRxXKBvZLhG5FOk7h1rcDliUtz6H2G1VpZsDWyu4ZFLKWGskW+ JbNwEqrsbEnD8ONKDF2JShKYq77f/s1HuJ1v3f25cEt2M7p+QkzdFPP3hBUhSc5DWWXqjE KC+1afP/3JZUoDogkeUUFqsIJw/RlncJvueW81QDvvPjIu/uEaS4s30YRPQHCg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1690963940; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VRfpbFpba+aFanVU03R3qG5yUbt/f0sJViScGxYkRyA=; b=Opn/0pF8pzkOdBLU0MxuelhpaObcZ18tcTbWfebFx+zGjJhvRnnxqTQFYmd7qLOtMyT5H+ SjzBjsvIOyGMbHFDGSA5+XQA6j/DWDL3W74z7SYRsTUFl92LCrQIWXFT/IdRa92eA/oIhP KonI501dymvLR39Nd5ytSofW4QSjJdiPrVgD0EkzTgBT1ti72g6tQHhnQTC0lHmzAgbr23 py+sRa1qjTOx1WF5pA/pq0jtpzIZe6uXkSlUc4thIKzu5C4omjpH9S2iUFIyqbB9F/qZt1 RmISY254SlBXaq/AfFqMKwu9R66o/mM+4vWjO0P0rdiSDAhgO5eZWfBM0WzYbQ== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RG4TH3Y8Rz17ym; Wed, 2 Aug 2023 08:12:19 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host86-141-212-56.range86-141.btcentralplus.com [86.141.212.56]) by smtp.theravensnest.org (Postfix) with ESMTPSA id DF572889C; Wed, 2 Aug 2023 09:12:17 +0100 (BST) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: Review of patch that uses "volatile sig_atomic_t" From: David Chisnall In-Reply-To: Date: Wed, 2 Aug 2023 09:12:06 +0100 Cc: FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: <9A5C0082-2FFD-4B2B-9381-7ACD9EB7C4DF@FreeBSD.org> References: To: Rick Macklem X-Mailer: Apple Mail (2.3731.600.7) On 2 Aug 2023, at 00:33, Rick Macklem wrote: >=20 > Just trying to understand what you are suggesting... > 1 - Declare the variable _Atomic(int) OR atomic_int (is there a = preference) and > not volatile. Either is fine (the latter is a typedef for the former). I am not a = huge fan of the typedefs, some people like them, as far as I can tell = it=E2=80=99s purely personal preference. > 2 - Is there a need for signal_atomic_fence(memory_order_acquire); = before the > assignment of the variable in the signal handler. (This exists in > one place in > the source tree (bin/dd/misc,c), although for this example, > neither volatile nor > _Atomic() are used for the variable's declaration. You don=E2=80=99t need a fence if you use an atomic variable. The fence = prevents the compiler reordering things across it, using atomic = operations also prevents this. You might be able to use a fence and not = use an atomic but I=E2=80=99d have to reread the spec very carefully to = convince myself that this didn=E2=80=99t trigger undefined behaviour. > 3 - Is there any need for other atomic_XXX() calls where the variable = is used > outside of the signal handler? No. By default, _Atomic variables use sequentially consistent = semantics. You need to use the `atomic_` functions only for explicit = memory orderings, which you might want to do for optimisation (very = unlikely in this case). Reading it outside the signal handler is the = equivalent of doing `atomic_load` with a sequentially consistent memory = order. This is a stronger guarantee than you need, but it=E2=80=99s = unlikely to cause performance problems if you=E2=80=99re doing more than = a few dozen instructions worth of work between checks. > In general, it is looking like FreeBSD needs to have a standard way of = dealing > with this and there will be assorted places that need to be fixed? If we used a language that let you build abstractions, that would be = easy (I have a C++ class that provides a static epoch counter that=E2=80=99= s incremented in a signal handler and a local copy for each instance, so = you can check if the signal handler has fired since it was last used. = It=E2=80=99s trivial to reuse in C++ projects but C doesn=E2=80=99t give = you tools for doing this. David From nobody Wed Aug 2 17:26:52 2023 X-Original-To: freebsd-current@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 4RGJnh3084z4qksm for ; Wed, 2 Aug 2023 17:27:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (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 4RGJnQ5C6mz4NJ8 for ; Wed, 2 Aug 2023 17:27:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=inEcVdv2; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.83 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=1690997225; bh=MojFUMFvj1uhAj5zknqAn0dSevZXaXGSGprTDJKNmWI=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=inEcVdv25BGVeLtVM1G3i+Nlh9TLl8bfiFdJDDkvxKYeaXzQZ92blEo2oljUEeWOdCiwFn7Xv9f1UwxlPnrKIvMWAobP7vBQIqrAWS4Iz38vjd6OrNKoZU7rzLmsUiVUgpva+fAZF21KTo2V1oCCsA3m0IP/Q2a5/qquB/yFl4AuXVIgdzyj/yvnChufdvohh2tZOy9pmk8XPuj+M2fvkn3W2AxjkdKe3YURjfKwsIvQ62e+0RVfnTTzyjK6D+XT5jNQXibYj8pCoi6zfOIRLFRq0xzhp2/9TjfIyhL+oIc1sLTEIYqDS1npZn/YBUkaaBDAAOZmIsGAZPrld2gdBA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1690997225; bh=Ct7s4CchfhQDYTBYuSGqrMuKF30Bm79dxColPPfZQQa=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=tqjYUf2V7/+v4iAF6nCzUrkmA0z/02du2vMlYMdPEuHoY4XurktGkkqMszSXlEM7UnXXQGX4n2fO+FDCU22GcWwNNFc6uH2eeHi2Lz5xQtFM1Tg5hVDtKCJPM4QuwqEzRx541K0uPpGoTtimBRIcEmL8rd6zMY9UPBHLXMP42IkAOfgb5+jC/nVYzXtd/+g3id+RBMtH0RXOmuw9pERON389RbsDS6fJLdXJN8JFyGhsYwLjgjkQeZjsmjG8n9hFMOwYwmFiWgWQpkM4dzHV4i6n5R3KRBRx1fZJfX7i5RiAv/iXtCq3+dvqP789M9Hq2chV5zrzH1cqhaj97CnfaA== X-YMail-OSG: _XrV.1sVM1mhFOvpgNKBpMpyECSs1CiA_rw5bgDh3lTv0cx..unErVCzpteWPgZ dCOarjjISE57.57bLBM0qeSG2YnD_c5iuecyCgak6WMt68VoTrlAd4MwJLKE1r51V18pW6nxUKaL OHWxGmxMTNVy2EtLfyBZs1XE_5GA7QHsAYjNuOAJ1TBM4nwDMSCcZ7xHDayNiq3xBsN8kBGndfrc YymO7KC7cX9rGvUiHEG7cJOI6Xc3tnASyqz5W47W_RUrmN1j0qE7ERJqMBv9tB17JkmqkuXp2rC. 8qZ7mLJKCj9KOnVkSMT4TiGijq2Wv_moJ0rEQX32o.U5I54hcz91HUmTmzEPilH2NW68sfNGsYPB tg4UWg9HnSVIW24e77L2AweS2fckmaVrbureEChyU9ffqS8g9e2qp2TzvC7jCHnSxq1cpUo_8CKf 7V.l.3yrNXne98CPFr7vfiTQvz29Kh2_ORcV7QknSttjlEHvcEjE8edXegsWYKhNBJIVIx5LEdud _DQk4oh4hL_S1M1otp4HEgENbAZ7bFXncnIRkhASjIm0qcN6pAw2O3Sr1QaP1.21rjnxkRxI27hX jmPLhphDtTl.y6lwqlwBRhBWFKs58U4uriJ3EbsmEl4UCh7gRhiwTLwpHeovMtJYTFAP5m.EELV. gblFD6WOB2IMDOuN2hG7SeS1BDkffPWqfCGH_RU6UjtIOs6D.epMpmNT_J39oeE.lN.u3iLJXq96 giZ2CupP5gBMLBKzrqscGK6cSQ729oMkoy1_W3YAuqFDOexzzwWWSA.bQFwzUmrZUxG2ItvCVzek cvgF5kNGnZQ94paM_WXjVdsO9H3HPgngmAkAlhVI_jxex6jMvRRfCNzL1uFVj5U64DYZn0p9c6mu jcBTXI0MpRZX_8iptefMGA_tlsNL0U_jLN5kJ2fQFpb5UarAU6ZIRZECOw8s3tjL6ExeqL8Wisqq UnRcU8NVA544.SRr7oGLNjkRq3vZbb4tZcQ4Jv1ed8xpUS8wtQL1_CpVX.YCH_5MyvZ_PmrrBpME fAZz3ConZVkqTWDIyt8XmHdYm_0Xl8Znrsd0mmFf2yQvMF7gC38qr6bxyOYML86YK2aC6LpYzNeC Ik2EQGtSJyc4DsU9WsKXICgv_CF_deJAMJY32CoH1ZBxx2sTNQWQBi7EPLX7pzrljhrh7PcniwlX 1OcbEO8t78ppoaqdKAaBMvvNoy3kxlp30_cl4Y29Q2NpnnxaWqtTChU._dSREH90nyzxBBOVC.Nl 74j.tn9VFBvR8ypD2H7J.a7MQlbFEJRteLnI3vo3NI0JzD9WfiJqkD2j9ndfolQQj56p8Up0hVtE aTWHI0tNw40o0RAb3KOTQdW5N6kCOTo.71S36h.6kP0XjUd9VpsJKJl0Zyn8vey7QuXbSG3yV5f2 3IeIYKzOLHNVMNm85iNQ.IiWUkGeG8N2SgmG3AYryJJ63ZSPgH5v24Wm0R4RLJF954TSz1E7kk8P 7s2oPAEtsbrCaX5FRFmgGZ6AFEERJitF0oU17d0_QG2wLSf5iBOTYIGeBE.bMzwgfzcI.lfinORE .IhjDb.3EVPJjsqBe9mh_6lxjrkO5iTq8FcorSuvDMtoT2MfM3AGQblvT.7nXDMocFXYTw36_8Un yPHzyo4wbAU_pasCRiiJpAU4RjYsQ61Bzo_XWOpfEokHJgL4AXbI2hdMgaTQ_6pSRtpdRr4epBrt 3ufiSBB6CgkPgtJLYupt1Tj4iVH1Ihwk2mKdSh4EdIaNMkcQLk_PK6FW0hiwOi4cuQ4glyIc5nmA DSJIz72X1uobVhraNQVaQUqDS46oMhDra6xVlDAqy9hcEH7se8gGud4SawTzVq9TmTqSDx0JbG9a TQlGwkZuL46bG8yVwYHrVQmMCcHViicBsIjZgzrjQFYPSebnjnbbRiasAiryZpARFuGC2oQOJIFA yY9R3unTAxMIs8IYOSKRsTe9Cl5eSHXjHGrjnGwsAHpMoh4uDngLfCNhNsD5Nn_Ax38L49ujDXdk 6c5aU3fV0e9V3Hn55S2ET8uqKBRlxOaIeT2G0v75DJU0CCcDHlNMhoRx_NrDDoF4LIl4e7hcFl5v D7ee4wBGshKukaMLkT_aBVbVtQShj0ruRPMbHdMjI9I_b_tsvvM.888b30RWLRxn1IYxhpuGq.7n ycLaR5qRxo38BrGoJUZ1vHKZPWTvH9THXM5VnUWSfuIMXzJXWati36JXeVBVw4Klzp6gtCQgCT7B Ickucd023pj2Zn33dhKjk9asoYATBf788ecl0qLhs9mb9cXJGPvZoqJBKJ_mCNJlj0eCojAhulbb MVPJR_7A- X-Sonic-MF: X-Sonic-ID: b11533ea-d9af-44ca-bc25-0bf09015198f Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Wed, 2 Aug 2023 17:27:05 +0000 Received: by hermes--production-gq1-7d844d8954-pkqkw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 65aeada7a322bf1e07fd0d38d06bcc69; Wed, 02 Aug 2023 17:27:03 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: sys/modules/Makefile and MACHINE_ARCH vs arm64 (in use) vs aarch64 (not in use) VS. man arch; also COMPAT_FREEBSD32_ENABLED use Message-Id: Date: Wed, 2 Aug 2023 10:26:52 -0700 Cc: FreeBSD ARM List To: Warner Losh , Current FreeBSD X-Mailer: Apple Mail (2.3731.700.6) References: X-Rspamd-Queue-Id: 4RGJnQ5C6mz4NJ8 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.38 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.88)[-0.885]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.83:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.83:from] man arch reports: MACHINE MACHINE_CPUARCH MACHINE_ARCH arm64 aarch64 aarch64 . . . arm arm armv6, armv7 So I'd not expect arm64 in MACHINE_ARCH . But sys/modules/Makefile has (from a grep for MACHINE_ARCH): .if ${MACHINE_ARCH} =3D=3D "amd64" || ${MACHINE_ARCH} =3D=3D "arm64" .if ${MACHINE_ARCH} =3D=3D "amd64" || ${MACHINE_ARCH} =3D=3D "arm64" || = ${MACHINE_ARCH:Mpowerpc64*} Another issue may be that COMPAT_FREEBSD32_ENABLED is only put to use in the Makefile for MACHINE_CPUARCH being i386 or amd64 : .if ${MACHINE_CPUARCH} =3D=3D "i386" || ${MACHINE_CPUARCH} =3D=3D = "amd64" _agp=3D agp .if ${MACHINE_CPUARCH} =3D=3D "i386" || !empty(COMPAT_FREEBSD32_ENABLED) . . . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Aug 2 18:16:40 2023 X-Original-To: freebsd-current@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 4RGKxV2qfHzZf9J for ; Wed, 2 Aug 2023 18:18:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 4RGKtt6mFwz4RjS for ; Wed, 2 Aug 2023 18:16:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20221208.gappssmtp.com header.s=20221208 header.b=XHuhOymg; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::12d) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-4fe1344b707so188826e87.1 for ; Wed, 02 Aug 2023 11:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1691000212; x=1691605012; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MXV+zd2Do8aYpEYfdwf5KzmM24s5tVaNrRJnM24l+CE=; b=XHuhOymgZH7serzmoBjLi5bYc4594c7jWefvGlmZy4N6zuNdActTgcjL1kuPht8EXd c+WPpkIYxcdAwcpKEbfg71c0jTeMKh6FASxsOxMixuhtVBRhi2bUFbHN6Rs3/CIJfKWM DL7f1k0Kj5XpTrgH2ZC09Ist981+uhAEyQkSDelhU0A9LxcaYhMEwZ27X8kdK/XWOzDx tdf6s01XcrL+v8v4jdFa4cV2l0Y3SElApYBZBjg2SfueNcgpxMf8ZP/P+7fPzyY/6B6l vUZ3r71R3IJAwcwf63ZNFJKzjySC6kNhtQsJ1AhKzHxklNlHRH/PoBcP1UCKTTf+Tfkp Wa7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691000212; x=1691605012; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MXV+zd2Do8aYpEYfdwf5KzmM24s5tVaNrRJnM24l+CE=; b=W+9ojInAW6DvFfzfBXfKKuYI/hRw6Rzsy4bcAt7oZ/vwUseRIcAOrtU7LCV3SQFbLh qJhppmo47icWwQ+ZeBkNh0SCczFz9cQIc/nNR8p4+ZXThhaKjEEcizg4JLICj9RwdOco 9FQC22Ue2W8Wy7izw71N6EBGRjSDer0xCj71WTI/RhohhLZ/k4lTI8bCs96VdZyT3udz QtsfV9gR7W9ijLIRy5VgKgx3N+ehSRe1W5lo98JGMPd2OweCWgdR3nr+t0Qvr0WYsMTn bv4CGVDIMLy30tr0rxmZlxoHBRloJ4y/OD5aFH5eszgDOPpmXDq+V4OsjidrCeZ1sqep 8Mlw== X-Gm-Message-State: ABy/qLaPQvRGlPS58x4w7vfsoqK8G6cLKdJutWyGSgqclgMx5tdSNlTf wpZszOedhShw6ORyJQdeZ1JlJLbjVgp+SRbcS1XX1g== X-Google-Smtp-Source: APBJJlH3yj531rDeKu7lpm4GoefNwL7ohOChYSCAGsDVfVyHdoy8U/slqNlwcNUDLZ6jCWOx1JJ8Xwgm+GdJvvnER/c= X-Received: by 2002:a19:8c06:0:b0:4fd:f80d:f6a3 with SMTP id o6-20020a198c06000000b004fdf80df6a3mr4599732lfd.43.1691000211586; Wed, 02 Aug 2023 11:16:51 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Wed, 2 Aug 2023 12:16:40 -0600 Message-ID: Subject: Re: sys/modules/Makefile and MACHINE_ARCH vs arm64 (in use) vs aarch64 (not in use) VS. man arch; also COMPAT_FREEBSD32_ENABLED use To: Mark Millard Cc: Current FreeBSD , FreeBSD ARM List Content-Type: multipart/alternative; boundary="000000000000ed657e0601f4aab3" X-Rspamd-Queue-Id: 4RGKtt6mFwz4RjS X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.99)[-0.993]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20221208.gappssmtp.com:s=20221208]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_TO(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12d:from]; DKIM_TRACE(0.00)[bsdimp-com.20221208.gappssmtp.com:+]; TO_DN_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] --000000000000ed657e0601f4aab3 Content-Type: text/plain; charset="UTF-8" Those all look wrong to me. Warner On Wed, Aug 2, 2023, 11:27 AM Mark Millard wrote: > man arch reports: > > MACHINE MACHINE_CPUARCH MACHINE_ARCH > arm64 aarch64 aarch64 > . . . > arm arm armv6, armv7 > > So I'd not expect arm64 in MACHINE_ARCH . But > sys/modules/Makefile has (from a grep for MACHINE_ARCH): > > .if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "arm64" > .if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "arm64" || > ${MACHINE_ARCH:Mpowerpc64*} > > > Another issue may be that COMPAT_FREEBSD32_ENABLED is only > put to use in the Makefile for MACHINE_CPUARCH being i386 > or amd64 : > > .if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64" > _agp= agp > .if ${MACHINE_CPUARCH} == "i386" || !empty(COMPAT_FREEBSD32_ENABLED) > . . . > > > > > === > Mark Millard > marklmi at yahoo.com > > --000000000000ed657e0601f4aab3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Those all look wrong=C2=A0to me.

Warner=C2=A0

On Wed, Aug 2, 2023, 11:27 AM Mark M= illard <marklmi@yahoo.com> w= rote:
man arch reports:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MACHINE=C2=A0 =C2=A0 =C2=A0 =C2=A0= MACHINE_CPUARCH=C2=A0 =C2=A0 =C2=A0 =C2=A0MACHINE_ARCH
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arm64=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0aarch64=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0aarch64=
. . .
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arm=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0arm=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0armv6, armv7

So I'd not expect arm64 in MACHINE_ARCH . But
sys/modules/Makefile has (from a grep for MACHINE_ARCH):

.if ${MACHINE_ARCH} =3D=3D "amd64" || ${MACHINE_ARCH} =3D=3D &quo= t;arm64"
.if ${MACHINE_ARCH} =3D=3D "amd64" || ${MACHINE_ARCH} =3D=3D &quo= t;arm64" || ${MACHINE_ARCH:Mpowerpc64*}


Another issue may be that COMPAT_FREEBSD32_ENABLED is only
put to use in the Makefile for MACHINE_CPUARCH being i386
or amd64 :

.if ${MACHINE_CPUARCH} =3D=3D "i386" || ${MACHINE_CPUARCH} =3D=3D= "amd64"
_agp=3D=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0agp
.if ${MACHINE_CPUARCH} =3D=3D "i386" || !empty(COMPAT_FREEBSD32_E= NABLED)
. . .




=3D=3D=3D
Mark Millard
marklmi at yahoo.com

--000000000000ed657e0601f4aab3-- From nobody Wed Aug 2 19:56:42 2023 X-Original-To: freebsd-current@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 4RGN8Q6t38zZjqt for ; Wed, 2 Aug 2023 19:58:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (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 4RGN6R1ktTz3C7C for ; Wed, 2 Aug 2023 19:57:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691006218; bh=w+B5jJcvRIqykxajCt/60beNzfwIYV+hNzYzN1oe8GE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=uRrmalhuuCvMjlIks9pr/ydn5VeksYloLwXcrRIDPSZ200dWOisILC4msA9fQhCDE55DsSO4q4c/LneedL66fEkHjm8HwVR+8kedtuqkxtoQjfVbWqTkH8GFZIfbes8KT/ELr1dEDWoS+oiKoH8gy1CF2U1IRqog9ODhOKPJhqp72VPO3YlDrgoxKrikkas/kJqep+N+7EwOQCdk5D+RqHs7X0HeTcYQqQIrihSmVcgr0wElL01mI6zlD4i3rwe0KFi4Q+VVdhqivHUoDQnrTFRcQDDys/0/xldb/gjr8t/tfcvSWMt+mTHUspQ5GB6BPLjH+1zPJOp3JT/XQ51VtA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691006218; bh=WRmhcgsctJa0GPaNPjtWiyCGYi4s1i0AL7jY4iTw5dP=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=h+37H/h+TtwRq4SVa7c6dRWfyw3h4kXMm7bqHGN18vEqxyXzeIuZqkMKhkwP2iJixPbWR7jguADW2Nel5NUf6Fqqy8JXb2EnUli00Fa0nEz12m07cHuGzlxreeL61HS0PmDJg6PYrMySLNwiUqu4l6bMDeMGYmLSbz1wQStwwhASxZm+nNEofnmKb53Itl9DhUHnpYvmQ37QfbD5aL3bKAPkpIbSVbLOPGL7AsbeWD9klsyENhwwN+9h7nhwema204yPYzlxG4wvL8hgToagdT75speKesxj5kc6QPqXL8bQdgiRSsalXGs283nUyoTAGmlAvLKKLfMZvccIE6fIJA== X-YMail-OSG: QFYBCkYVM1k1hZgitIiAc7vSU5WFxwGJk1eRxzCXxiuAjpnV7CYtj5R6GLk0fKm FowOexsLchhSqtn3a8z6yg4Jv2ZAzO9_We1S7KmzaaKpahR8AHMXqGMicPNoMVK0ngRT8HN_jkUM bpsPKeYttwVP1JUCsdLQtEbvInuSyT4203ZL6UHxNmTTY.uJ4A0QRlzh52QfYLIJaCPOuoZ5qTTG tn7Rlc7jB2f3.RCRYRLX5f7.tsbmvCDVVrI.A2sm37TCh9rU1S_hdmmLcs0rodFa0_8gVKGsjno3 R3SH45m_E61dxL1lpNPz6vxeyRyCS9jhWVguAMySXKTvpNnkDvQ.Wa0gUvhBk0iFSeTPf.pX4NlR 6zuvenWRBC1AO2k3VE3CctqT.CC9y2c.a3O.KYDIHWuAXIahvwSqdXiB6DXTOOlH7ypyzo8_b1ys u_dpCQ0.2ZZ8legUTkbIoUfvhpykCgYX4JafQ.ChdhvFcZK2B0ctRF2wmlcxrRrzytA1uqvBEQM0 DAqxoU6RLgLPJ1NCwfESHxNmk.jTIjSXKoeMK64jgP2C9kL9vP4mPwKfJGhcyvPQ2mo2N0.kHrDD 2jTcKMA24T0BEGP3EruRwJClY7NaOB8P5Cg_aR9JFyeaz9e.phUU37C3_.escRJICyaN6K8PGrdp VXX.eT9LC0HHwF1YO5EoeuWAuCNiuByNTd5wGBWfPtBC91ZSyCbgIOiqmk_Txc.fBKSg999i5srh 2J3cP_l4.ZRqQ2rEPqibGyLSx3QwQ0LMfeYa3cnF4eP4CaE5U.RFlHdnQAHo9xYAIaWnrOjn8HK_ s1wIK1claBCezMooQ6fVN2au57r.uZQ0y.6jF7RbWzjYzrFBBw5hRkNJdESe5K0uC80IYe8ppELs iOCXEaZNeniuhrDVKsOVdkZM9h3Qg4JaF1Sg6FENNbFLfke_hK0eeELxFqyYWg1G19GuCcMgqV8I 89L6sqdpCI0PI8aH1sqCLws.5GBeunRJX9dfR5nAog3RrFbTUmPl0E036x8cV595Vp7SpnXeEJxz MrPW2NKy2zo3lkloTULsPvlVSf4VDYJVhphD3c6H53pxqZA1OlAkLaRilEw33h2H7TLehoDBoH6f SzwhqaM0pnICEVzYIwAswaaZoGBCL_4Rz1ByioWm0VmLYVkG8swb6X_Fw1rohlRb5bt_PliyWVZp mZpqTzv284Ga2Io2bAguoZaBjLyNtSkHH5uYHQSKuUVa_IziyqTztE3ezxF77TknKCFgzj03OV2n qKRxaH.NG8tsQKVsuua2VL3m4vvwEiAA8z5BO.LMlwyjXEV2H7EbOHtwdX55eKR0PnKrL8BHoKvV GWxgkbHl8DawFWT_IsoVV0U9eqHi8tAD6GIc.SoREPcI09Ac7BlYAe65z2AZ.kfKYeJob9tic_Du s4Cow7R9.5mNz1CWzYrp5zWenEeTH.r5L21LK.HXRhGY6I40IonfrfVASuYUk5A1SKBLPICzQS1n ggos_esQbgzf9nn_53TtP5h2uGMkmMx3Y1etR2UwP098Sm.3n_RzBCouOKNy5roXCi2WVIRaL.FD eDO0YXK69T2FuUrfwbmsnNBj5itdXfJXHMiT0DIhSYjP3g5mBOufQjUNSQ7lenntJlJ6IDP46syw ruvH4QxL2_E06L4Kg6ChYMT9Jh84JXUgxojViWocbJqK5dI8MURNh42BnE3FGyNU.NI6dYb7WEaW U5an_Lr2iKEUki3hMWLFHNmckbzaADPOrwUwvdRSiYZEjLWquaMAG3X6OMfD029CXsaB9PjDbews c929LmgRpUY_0uxPTQTKQKVlpbLxy6B0JDYAxaSUjmTkbJ43YxSz8TOVma0L0adT_j4dNsmN8c3v KiFsZNWPTyM059KAm3FDVYUPuTYimjNqRD7AftCnNAekZVgs3kYOURsIwH65X1Qma2dPCwSBhCCK 1o60cGMkAs9pR3shy1J6GlWnsr.rH3MqYaEuj5aJhNnaJh3kmCcRjLRKFuf7Wo8AMIuRoprBFiUm yVXPtEy.pTJf4fCynpff1bewhv0Xu7WbwrgNGTHnih6vH7z6pAmcYw1cyDveosmhQQrTzB9b013w g_sJf6gXt_y21JUyh8nsJl7M.wQeFqVXNeLFwuOfHG5ILYH8NFSK5_v9JOepPl4o58T.dc7Pg.Rn pxTzLkgG8QXXgH2sDtCGNKYunf0B7pKd.rKKCVkNlLPCqW40phSMw_c7PHwjxvjiNEG67FH_RIAM yUqw_zGCBEHa75ddh_PWjdVDWcJYqo6CgLejggJmKEvC7BoYUZDwJz2e3SUydqnBmJslqvalwQQ- - X-Sonic-MF: X-Sonic-ID: edde3f38-98c4-4707-81dc-6d9df92b8e6f Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Wed, 2 Aug 2023 19:56:58 +0000 Received: by hermes--production-gq1-7d844d8954-qb9gk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bbcd901997ee516ccc08a927d0ce0448; Wed, 02 Aug 2023 19:56:53 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: sys/modules/Makefile and MACHINE_ARCH vs arm64 (in use) vs aarch64 (not in use) VS. man arch; also COMPAT_FREEBSD32_ENABLED use From: Mark Millard In-Reply-To: Date: Wed, 2 Aug 2023 12:56:42 -0700 Cc: Current FreeBSD , FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: <2B0FE8B1-5E53-4E70-9792-15A8E423CA33@yahoo.com> References: To: Warner Losh X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RGN6R1ktTz3C7C X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Aug 2, 2023, at 11:16, Warner Losh wrote: > Those all look wrong to me. >=20 > Warner=20 >=20 > On Wed, Aug 2, 2023, 11:27 AM Mark Millard wrote: > man arch reports: >=20 > MACHINE MACHINE_CPUARCH MACHINE_ARCH > arm64 aarch64 aarch64 > . . . > arm arm armv6, armv7 >=20 > So I'd not expect arm64 in MACHINE_ARCH . But > sys/modules/Makefile has (from a grep for MACHINE_ARCH): >=20 > .if ${MACHINE_ARCH} =3D=3D "amd64" || ${MACHINE_ARCH} =3D=3D "arm64" > .if ${MACHINE_ARCH} =3D=3D "amd64" || ${MACHINE_ARCH} =3D=3D "arm64" = || ${MACHINE_ARCH:Mpowerpc64*} >=20 >=20 > Another issue may be that COMPAT_FREEBSD32_ENABLED is only > put to use in the Makefile for MACHINE_CPUARCH being i386 > or amd64 : >=20 > .if ${MACHINE_CPUARCH} =3D=3D "i386" || ${MACHINE_CPUARCH} =3D=3D = "amd64" > _agp=3D agp > .if ${MACHINE_CPUARCH} =3D=3D "i386" || = !empty(COMPAT_FREEBSD32_ENABLED) > . . . I'll note that, for example, i386 vs. armv7 do not match for some struct md_ioctl field offsets and the overall size. Mike Karels is looking at getting struct md_ioctl32 correctly matching each of of the contexts: i386, (32-bit) powerpc, and armv7. I do not know if there are other COMPAT_FREEBSD32 adjustments needed for differences in memory layout across the 3 (i386, powerpc, armv7). md_ioctl I learned about via kyua test runs and looking at the background for some things it reported for armv7. I've not found a clear indication of what is expected to work for chroot/lib32 vs. what is not expected to work. It seems one must look in the code and see if one finds conditional material based, in part, on COMPAT_FREEBSD32. It might also be that COMPAT_FREEBSD32 for i386 vs. armv7 vs. powerpc might not be intending identical coverage for all I know. So seeing COMPAT_FREEBSD32 might not be enough to know the intent. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Aug 2 22:51:08 2023 X-Original-To: freebsd-current@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 4RGRzz1VGQz4d7kv for ; Wed, 2 Aug 2023 22:51:30 +0000 (UTC) (envelope-from pen@lysator.liu.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 4RGRzj3f0fz3m15; Wed, 2 Aug 2023 22:51:29 +0000 (UTC) (envelope-from pen@lysator.liu.se) Authentication-Results: mx1.freebsd.org; none Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 44D45141D3; Thu, 3 Aug 2023 00:51:20 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 4332514367; Thu, 3 Aug 2023 00:51:20 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,AWL,HTML_MESSAGE, T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.6 X-Spam-Score: -1.0 Received: from smtpclient.apple (unknown [IPv6:2001:9b1:28fa:7900:50ae:3785:3e33:f653]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id F052D14824; Thu, 3 Aug 2023 00:51:18 +0200 (CEST) From: Peter Eriksson Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_58B5A35C-7465-46C1-B6E9-025C34A8A2FE" List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: Review of patch that uses "volatile sig_atomic_t" Date: Thu, 3 Aug 2023 00:51:08 +0200 In-Reply-To: <9A5C0082-2FFD-4B2B-9381-7ACD9EB7C4DF@FreeBSD.org> Cc: Rick Macklem , FreeBSD CURRENT To: David Chisnall References: <9A5C0082-2FFD-4B2B-9381-7ACD9EB7C4DF@FreeBSD.org> X-Mailer: Apple Mail (2.3731.600.7) X-Virus-Scanned: ClamAV using ClamSMTP X-Rspamd-Queue-Id: 4RGRzj3f0fz3m15 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1653, ipnet:2001:6b0::/32, country:EU]; TAGGED_RCPT(0.00)[] --Apple-Mail=_58B5A35C-7465-46C1-B6E9-025C34A8A2FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Interesting discussion regarding sig_atomic_t, volatile & stuff. It = seems I opened a can of worms. Sorry :-) Anyway here are the references I had read when suggesting this change: C89: - http://port70.net/~nsz/c/c99/n1256.html#7.14p2 CERT C Coding Standard: - = https://wiki.sei.cmu.edu/confluence/display/c/SIG31-C.+Do+not+access+share= d+objects+in+signal+handlers I=E2=80=99ve also been using "static int foo;=E2=80=9D in my own code = forever before and like you say it works but then I got curious and = started searching to see if there was a more =E2=80=9Ccorrect=E2=80=9D = (and portable) way of doing this) If I read you right then just dropping =E2=80=9Cvolatile=E2=80=9D and = use =E2=80=9Csig_atomic_t=E2=80=9D should be better (and =E2=80=9Cportable= =E2=80=9D for some value of portable, not a problem in this case with = mountd) but using atomic_int from stdatomic.h from C11 is even better? = (volatile sig_atomic_t is from C89 I think). Something like this: > #if __STDC_NO_ATOMICS__ !=3D 1 > /* C11 */ > #include > static atomic_int got_sighup =3D ATOMIC_VAR_INIT(0); >=20 > #else > /* C89 */ > static volatile sig_atomic_t got_sighup =3D 0; > #endif (for portability, not needed for mountd though).=20 https://www.informit.com/articles/article.aspx?p=3D2204014=EF=BF=BC Ah well, time to relearn C again :-) (K&R C was simpler :-) - Peter > On 2 Aug 2023, at 10:12, David Chisnall wrote: >=20 > On 2 Aug 2023, at 00:33, Rick Macklem wrote: >>=20 >> Just trying to understand what you are suggesting... >> 1 - Declare the variable _Atomic(int) OR atomic_int (is there a = preference) and >> not volatile. >=20 > Either is fine (the latter is a typedef for the former). I am not a = huge fan of the typedefs, some people like them, as far as I can tell = it=E2=80=99s purely personal preference. >=20 >> 2 - Is there a need for signal_atomic_fence(memory_order_acquire); = before the >> assignment of the variable in the signal handler. (This exists in >> one place in >> the source tree (bin/dd/misc,c), although for this example, >> neither volatile nor >> _Atomic() are used for the variable's declaration. >=20 > You don=E2=80=99t need a fence if you use an atomic variable. The = fence prevents the compiler reordering things across it, using atomic = operations also prevents this. You might be able to use a fence and not = use an atomic but I=E2=80=99d have to reread the spec very carefully to = convince myself that this didn=E2=80=99t trigger undefined behaviour. >=20 >> 3 - Is there any need for other atomic_XXX() calls where the variable = is used >> outside of the signal handler? >=20 > No. By default, _Atomic variables use sequentially consistent = semantics. You need to use the `atomic_` functions only for explicit = memory orderings, which you might want to do for optimisation (very = unlikely in this case). Reading it outside the signal handler is the = equivalent of doing `atomic_load` with a sequentially consistent memory = order. This is a stronger guarantee than you need, but it=E2=80=99s = unlikely to cause performance problems if you=E2=80=99re doing more than = a few dozen instructions worth of work between checks. >=20 >> In general, it is looking like FreeBSD needs to have a standard way = of dealing >> with this and there will be assorted places that need to be fixed? >=20 > If we used a language that let you build abstractions, that would be = easy (I have a C++ class that provides a static epoch counter that=E2=80=99= s incremented in a signal handler and a local copy for each instance, so = you can check if the signal handler has fired since it was last used. = It=E2=80=99s trivial to reuse in C++ projects but C doesn=E2=80=99t give = you tools for doing this. >=20 > David >=20 >=20 --Apple-Mail=_58B5A35C-7465-46C1-B6E9-025C34A8A2FE Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_CE0F325C-78E2-41AE-B8CF-3F116913547F" --Apple-Mail=_CE0F325C-78E2-41AE-B8CF-3F116913547F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Interesting = discussion regarding sig_atomic_t, volatile & stuff. It seems I = opened a can of worms. Sorry :-)


Anyway here are the references I had read = when suggesting this change:

C89:
- = http://port70.net/~nsz/c/c99/n1256.html#7.14p2

CERT C Coding = Standard:
- = https://wiki.sei.cmu.edu/confluence/display/c/SIG31-C.+Do+not+access+share= d+objects+in+signal+handlers


I=E2=80=99ve also been using "static int = foo;=E2=80=9D in my own code forever before and like you say it works = but then I got curious and started searching to see if there was a more = =E2=80=9Ccorrect=E2=80=9D (and portable) way of doing this)


If I read you = right then just dropping =E2=80=9Cvolatile=E2=80=9D and use = =E2=80=9Csig_atomic_t=E2=80=9D should be better (and =E2=80=9Cportable=E2=80= =9D for some value of portable, not a problem in this case with mountd) = but using atomic_int from stdatomic.h from C11 is even better? (volatile = sig_atomic_t is from C89 I think). Something like this:

#if __STDC_NO_ATOMICS__ = !=3D 1
/* C11 */
#include = <stdatomic.h>
static atomic_int got_sighup =3D = ATOMIC_VAR_INIT(0);

#else
/* C89 = */
static volatile sig_atomic_t got_sighup =3D = 0;
#endif

(for = portability, not needed for mountd = though). 

3D"apple-touch-icon-144x144-precomposed.png"


Ah well, time to relearn C again :-)

(K&R C was = simpler :-)

- Peter

On 2 = Aug 2023, at 10:12, David Chisnall <theraven@FreeBSD.org> = wrote:

On 2 Aug = 2023, at 00:33, Rick Macklem <rick.macklem@gmail.com> = wrote:

Just trying to understand what = you are suggesting...
1 - Declare the variable _Atomic(int) OR = atomic_int (is there a preference) and
   not = volatile.

Either is fine (the latter is a typedef = for the former).  I am not a huge fan of the typedefs, some people = like them, as far as I can tell it=E2=80=99s purely personal = preference.

2 - Is there a need for = signal_atomic_fence(memory_order_acquire); before the
=    assignment of the variable in the signal handler. = (This exists in
one place in
   the source tree = (bin/dd/misc,c), although for this example,
neither volatile nor
=    _Atomic() are used for the variable's = declaration.

You don=E2=80=99t need a fence if you = use an atomic variable.  The fence prevents the compiler reordering = things across it, using atomic operations also prevents this.  You = might be able to use a fence and not use an atomic but I=E2=80=99d have = to reread the spec very carefully to convince myself that this didn=E2=80=99= t trigger undefined behaviour.

3 - Is = there any need for other atomic_XXX() calls where the variable is = used
   outside of the signal = handler?

No.  By default, _Atomic variables use = sequentially consistent semantics.  You need to use the `atomic_` = functions only for explicit memory orderings, which you might want to do = for optimisation (very unlikely in this case).  Reading it outside = the signal handler is the equivalent of doing `atomic_load` with a = sequentially consistent memory order.  This is a stronger guarantee = than you need, but it=E2=80=99s unlikely to cause performance problems = if you=E2=80=99re doing more than a few dozen instructions worth of work = between checks.

In general, it is = looking like FreeBSD needs to have a standard way of dealing
with = this and there will be assorted places that need to be = fixed?

If we used a language that let you build = abstractions, that would be easy (I have a C++ class that provides a = static epoch counter that=E2=80=99s incremented in a signal handler and = a local copy for each instance, so you can check if the signal handler = has fired since it was last used.  It=E2=80=99s trivial to reuse in = C++ projects but C doesn=E2=80=99t give you tools for doing = this.

David



= --Apple-Mail=_CE0F325C-78E2-41AE-B8CF-3F116913547F Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=apple-touch-icon-144x144-precomposed.png Content-Type: image/png; x-unix-mode=0666; name="apple-touch-icon-144x144-precomposed.png" Content-Id: <770B6173-1659-4CD9-814E-194843E87775> iVBORw0KGgoAAAANSUhEUgAAAJAAAACQCAYAAADnRuK4AAANpUlEQVR4Xu2cDUzU9xnHnzvugDtB 3pUiCFIVLFiYqDPQuio6ieq0aW3W2mRxc6VJ2iXd2m623Zotje3SvWapk6QzWdpsS7vOGq3vSn0l KiCqBVVUAUUU8DjejvMA9v0lf/Hy965y8ibH95P88rtySvhxX7/P83ue519DT0+PDAf5+fkh2FKw krAisEKxjNJXSAOWDasS61JBQUGHDAMmGTjMWBYsa+9rNw4cOBBXUVGRZTAYvg/RTk5LS4sAPVih VqvVHBgYKH2HtLe3S0dHh6u+vr791q1bAevXr78VFBR0Gl87mpWVVThz5sx6k8nk7g4OLBdWu9vr ftMvB+ru7jZiC8MaixUkOvbv3z/h4sWLuU6nczkOF5uUlBQN5JFHHpHIyEgxm80yMJCGhgaprq6W 2tpa+eabbzosFks11hdPPvnkF1OnTm2Re3FiNWPZjUZj95AKqLOz04wtHCtMH3ba2toCtm/f/nhz c/Mr+MFSH3300ejJkycr0UhAQIAMDUSJ6ejRo3Lp0qWOMWPGVOD3/96KFSvOePIBLDtWExzLNegC gptEYIvylK989tlns1tbW1+HUFKzs7ODUlJSBDYqwwfBP3Y5d+6cFBcXdyASlIeHh78PIZ3yIqRG RArboAiovd1hxhbnKVSdOFEaXVZWts7lcuUsWLDAhPxGHi4IciM5e/aslJeXOxAlCpOTkz/Mzs6p 9RLaaq1Wi2vABARXCcEWq3cdm81m3rFjx0oI52cZGRkRSNwe8ryGOBwOKS0tlZKSkhbkSH9dtWrV J17cqC4kJKS13wKy2+1jlXhEBxwnGsnaH8LCwmbl5uaaxo0bJyMHgs9VNm3a1IWocWj69Om/RNTw FLrq8Pk2P7CA4DAexYMkOR3J2ScLFy60KtcZmRDkRHLkyBHBTbkKpZQ3ly5dWuZJRCi1NPssoMbG xhBscaJjy5Yty6Dad+bPnx+Oa7mMfEhlZaXs3LmzFSJ6/+mnn/6v3EttVFRUa58FdPPmTTO2RCyj 7pa1BtsryOIt6lruP5Dr16/Ltm3b2pDDvrtkyZItHnKiKqQprj4JqK6uToknSOc8zyAB+/WaNWss /lk1JvjcZe/evc0IbR8sXrz4f7pKtjM2NrbqvgJCJTMCW4xodHV1GbZu3fpDJFOvIWyFqUqyf8Pk esOGDZ2IMG/m5eV9pXu7Pi4uzuZVQDU1V/WhC7FxR9aNGzf+CecxIw6K/0NgIrJv375GFCFfXbQo r0QfyhIS4l0eBXTlSpVyngjRKCo6kowey8fIeSbAvmR0wVYIcl7788+/MFt/OU9KSqzXC0j1TIzY kt3dZ/Pmzf+eM2fOjNF5VSeFhYVy+vTpsieeeOJHMTExHW4udAmVbLWLya2z7t4YVRa2Bq4zHRVm GZ2QefPmydWrV9NPnTr1Al5vFADuTGDYBJjckuWxooHmWzQc6Y21a9eqZqgolxqdENVl2LVr1+pj x47txZxRlQCgtGLrDWEY9DKLyCTRQFHp77NmzZqPJYSoajVcaBc6D6/KXS5PmzbNZdLcxyIaBw8e zITr5CDvGVDnKXt8aENhCH7+yRv/IZ6o/PFPpLW4WEYjmadOiq+oNObChQtzMVWanpOTc0YAsGC5 TFr+Y3Vr+7+Nek+QaBCCFoeg2RpcVFT0OxQZn0W1ulsbXW6+IyCz5j5ZqPVMUROE7hCSmZkphw4d SsEYyJTZs2ef0+bexT2ECdT1OuKaBROFfpA493g/A94bpTzw54rxZEH4MkFAr0MvP9VCmBixIKBu TBWemIQeV5IaQ/UEIenp6SrF+c6lS5cjlGYURi2EYeqwbfGUKVMivTVKCcG8tOAhiVC0tp5RmlFo OVAXlOX4waRJk/ym5oNjeD0L3mMIe0AQoVTXfgE087EAo1Y4jEWMi4yPj5dvg5CEhASVKydhijFa gFFrnOWitzH2fs9tEaJSnMTExAi0ODIFmLQvzse0mbI32jVD2H1BYxWjPzV5IrLeqD1nndHX2g8h ymwMBkOqAGN+fn4AhuSD8cSiENJXB8ItLBTaCVYh7HFUn52wNjPtui8whAUHB6u0J0hExqsQlggB BYsPEIIZ+RBsCcqBJiJ8mfwx3xy8M/F3YrFYzNiilYBCUWH0w/6QOg97YYN1drM5UECoCmGdBgM2 nyCsB5kFhCoHCu7sdPmUXLGVwYuF6s6DwH5ZDyHG/qiSENODWBvrQAxh0MsAOhChA42mOtDEDRuk v1S//LK0l5bKUJJ67Niw14H0ejG5fYk1Dx/geXwIYYQwhPE8g5KMm/zb7nv8LJz0sA5EWAcaSa0M PwonA36e4a8DEWIUv4MwhLGVwRBGGMIIYQgbDhjCCKED9eBMg1+JpgMRwlYGYQhjK4NJNGEdiBCG sIf9TAxhhHCklefhUxl8KoNPZRAm0WxlMImWB4IQo//lCoQhjK0MhjDCEEYIWxkPPwxhhA7Uw1aG r7CVwVYGz8NWBmESzVYGn8ogdCCDwSD+hWGQz2SQoeJh+oz0ejHqxEMIHWgIz0QH6rcdEzqQweCv IjLwPIOGQR/CxA9DGM8zuD8Lk2jCJNq7++BMfuAGvMYPHoQOxEIiHYjQgXiN7xe8xht4jfcdXuNZ SPQdnoeFRJ6HhUTCazwLibzGE2IUQhjCWIlmCCN0II6A0oEIoQPRgThUTzhUz94Ru/EjvhI9lH0p duP90H0GuQ5ER2U3nufpfxJt8vV/G0JId3e3gNvKgTpMJhOv8T7B89y+fVtAi3Igu9N5W3yBEJfL JaBFOVBVU5OtE/o28RrfV3geh8OhFNSgRHPl1q1bHXDHECbRfYXnsdvtrdhqjAUFBacbGxuDmEgT H9znjgPdMAkIDg5ugYgiY2JiONJ6XzjSCq0ozTTCfDqMAsaMGXOiqqpK+gIhdXV10tnZWdlbSGxv b9+NPCi3LwrnRCInEq9fv640s7m3Gz9hwoTDFy5csENVQsj96j/Xrl2zxcfHn+p1oKSkpJtNTU03 b9y4EYY3WHjzCs9TU1Oj8p8rcXFx9l4HCggIELPZ/FV5ebl8G4ScO3dOtTH2KM30CshoDBCrdcyW mpqrDeqK5g3C8HXx4sWWqKioL5RmFKY7DjRt2rSrx48fu3D+/PnozMxMWv498DxnzpxR4evExImJ NgHuIcyBhd30F/whh+ggpKurSwoLC7vQeP+T0gqWw92BXNgsc+bMKTty5PB5kJGSksJCYi8sJB49 elTCwsJLZs6cVSEAuNwEZGzHNlYAkul1+/bt+xQCMgsgpKWlRSXPTqvV8htoRTTa3R3IIRpZWVmn i4qKjhw4cOB7gIVEFhLl+PHjKoTtmTFjxmW5i6M3B8IbLojIiaXaGl2JiYlvFRcXt6M2JKMbUltb q1ZdZGTkH5U+tOWEZu6GMM2FmrHFCEhNTW1Aw+xve/fu/fmKFSvMSlijE7Jjx46uwMDAgoyMjGty l2YBegHZsUXdcaW5c+duxF+eV1paOhuMsmsvz6Nmnvfs2SMdHR3FSGs+dzORbiy7aBjc54CQKCkH ihCNkpKSRDjRxkWLFsWj3SGjC1act2/f3rB8+fIc3Vs2XLDqdQ7U60JN2MLuuBCcpwoq/NWmTZs+ XrVqVfD48ePF/yFqtAc5cGN0dPRLuvSlG6tJgEcHUly+fDlCy4V6QS60BOL6bV5eXii+qfgvxGaz yUcffdQ9derUl7Kzsw/q3q6fNGmSzbuANKqrqxOxBYkbO3fuXI5v/t7q1asDIyIixP8gqtP+9ddf tyD/eXfhwoVf6d52Tpw4scrrk6m6UFaLTYnIKBoLFizYsnv3btPWrVvXPvXUU6EJCQniX/C6js/W ERoa+jYizU4ButBVKzr0DqQfWwzBFidA50SLGhoafr9s2TJLcnKyjHzI2bNnZdeuXe3IcX+Rm5u7 z5O+YmNjW30SkKK+vn4stljRsX///uQrV658imJSVE5OjqDBJiMPgrFUOXz4sApdl1FAfg1hq8KT l+Bhi2YBPgtIgVlpjyI6efJkNJqu60JCQnIQ0kxQqIwsGLJwOerCGHNhWlraW7ia2+VeVAW6WYCv AtI/RBaiicgoOr788stlaLa9g3AWjjxpBLgRXefQoUOCGfgmzPb8+bnnnvuPAA85T11YWFirgH4L SNHa2mrWcqIgD7c2K5qvH2CaMVe5Ecre8vDBhwHVyHJFRYUDjdFtGCD8MD093Sb34sSqRWRxCRgA AekV7IjobXm44XQ6jWh9pNvtTWuNRmMaRBT02GOPCUKcDCccQ3VJWdkJlSh3YCT1VHh4xLolS5ZU eHGdRoxs6EQ1wALSxGLGFu5WtdY34CYjAX8DTbhUxNBYFKUEHX7BfwsZuvFT1Y6orKzsQCgqGzdu 3AdLly71Jhw7VlNQUJBLwKAJSA8SMKMmorGeQht6adGwzKfQkHsWg2oJOES0SrZxXVRrAAXFYXc8 kqVSCfXMlhKPQDDlqOn868UXX/zcmw9oXXU78tZu0RgyAemBEM3YLFhWrDuv3W9tERhM+i46yt+H aFOQzEWjYKlub0FWq9UM9StBCYQmiNHiHeYyqivf1tamEuJOOL0TOY0Lvzc70oViiOngypUrd8N1 OvV/VRtDbVev8T10btMPAQ0X+fn5cdjSsKI0JwvVDmkWb5BOzT3qsGxYZ7HqCwoKumQY+D+tDWKW GnBGhgAAAABJRU5ErkJggg== --Apple-Mail=_CE0F325C-78E2-41AE-B8CF-3F116913547F-- --Apple-Mail=_58B5A35C-7465-46C1-B6E9-025C34A8A2FE-- From nobody Wed Aug 2 22:56:26 2023 X-Original-To: freebsd-current@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 4RGS7g2J1cz4d7mN for ; Wed, 2 Aug 2023 22:58:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 4RGS5k6ltrz3mdH; Wed, 2 Aug 2023 22:56:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.17.1/8.17.1) with ESMTPS id 372MuQZI004241 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 3 Aug 2023 01:56:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 372MuQZI004241 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 372MuQ7j004240; Thu, 3 Aug 2023 01:56:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 3 Aug 2023 01:56:26 +0300 From: Konstantin Belousov To: Rick Macklem Cc: David Chisnall , FreeBSD CURRENT Subject: Re: Review of patch that uses "volatile sig_atomic_t" Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Queue-Id: 4RGS5k6ltrz3mdH X-Spamd-Bar: / X-Spamd-Result: default: False [0.70 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; NEURAL_SPAM_SHORT(0.70)[0.704]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; BLOCKLISTDE_FAIL(0.00)[2001:470:d5e7:1::1:query timed out]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; HAS_XAW(0.00)[]; TAGGED_RCPT(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCVD_TLS_LAST(0.00)[] On Tue, Aug 01, 2023 at 04:33:16PM -0700, Rick Macklem wrote: > On Mon, Jul 31, 2023 at 11:33 PM David Chisnall wrote: > > > > Hi, > > > > This bit of the C spec is a bit of a mess. There was, I believe, a desire to return volatile to its original use and make any use of volatile other than MMIO discouraged. This broke too much legacy code and so now it’s a confusing state. > > > > The requirements for volatile are that the compiler must not elide loads or stores and may not narrow them (I am not sure if it’s allowed to widen them). Loads and stores to a volatile variable may not be reordered with respect to other loads or stores to the same object but *may* be reordered with respect to any other accesses. > > > > The sig_atomic_t typedef just indicates an integer type that can be loaded and stored with a single instruction and so is immune to tearing if updated from a signal handler. There is no requirement to use this from signal handlers in preference to int on FreeBSD (whether other types work is implementation defined and int works on all supported architectures for us). > > > > The weak ordering guarantees for volatile mean that any code using volatile for detecting whether a signal has fired is probably wrong if if does not include a call to automic_signal_fence(). This guarantees that the compiler will not reorder the load of the volatile with respect to other accesses. In practice, compilers tend to be fairly conservative about reordering volatile accesses and so it probably won’t break until you upgrade your compiler in a few years time. > > > > My general recommendation is to use _Atomic(int) (or ideally a enum type) for this. If you just use it like a normal int, you will get sequentially consistent atomics. On a weakly ordered platform like Arm this will include some more atomic barrier instructions but it will do the right thing if you add additional threads monitoring the same variable later. In something like mountd, the extra performance overhead from the barriers is unlikely to be measurable, if it is then you can weaken the atomicity (sequentially consistent unless specified otherwise is a good default in C/C++, for once prioritising correctness over performance). > > Just trying to understand what you are suggesting... > 1 - Declare the variable _Atomic(int) OR atomic_int (is there a preference) and > not volatile. Really does not matter. > 2 - Is there a need for signal_atomic_fence(memory_order_acquire); before the > assignment of the variable in the signal handler. (This exists in > one place in > the source tree (bin/dd/misc,c), although for this example, > neither volatile nor > _Atomic() are used for the variable's declaration. In mountd, there are two signal handlers. One for SIGHUP, and another for SIGTERM. They are very different, let me explain. For SIGHUP, the only action in the signal handler is the assignment to the variable. The assignment itself is atomic on FreeBSD. But what is more important, there is no ordering issues between this assignment and any other action. Eventually the main execution context notices that the variable is set and does something (re-read config). As consequence, there is no need in any fencing of the SIGHUP handler. > 3 - Is there any need for other atomic_XXX() calls where the variable is used > outside of the signal handler? The SIGTERM is different, it does some rpc bind calls to unregister itself as a mount program. If these actions can interfere with the main context execution (I believe they are), then userspace rpc bind client state can be corrupted, resulting in failing attempt to unregister. No amount of atomics or fencing would fix it, the unregister action should be either moved out of the signal handler context to main context. Another option might be to block SIGTERM, and only unblock it in places where it is safe to do rpcb calls from interrupt. This is approximately what dd(1) does. > > In general, it is looking like FreeBSD needs to have a standard way of dealing > with this and there will be assorted places that need to be fixed? > > Thanks, rick > > > > David > > > > > On 1 Aug 2023, at 06:14, Rick Macklem wrote: > > > > > > Hi, > > > > > > I just put D41265 up on phabricator. It is a trivial > > > change to mountd.c that defines the variable set > > > by got_sighup() (the SIGHUP handler) as > > > static volatile sig_atomic_t > > > instead of > > > static int > > > > > > I did list a couple of reviewers, but if you are familiar > > > with this C requirement, please take a look at it and > > > review it. > > > > > > Thanks, rick > > > ps: I was unaware of this C requirement until Peter Eriksson > > > reported it to me yesterday. Several of the other NFS > > > related daemons probably need to same fix, which I will > > > do after this is reviewed. > > > > From nobody Thu Aug 3 00:25:29 2023 X-Original-To: freebsd-current@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 4RGV4k3mr9z4dCGP for ; Thu, 3 Aug 2023 00:25:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (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 4RGV4V4jlGz3vjw for ; Thu, 3 Aug 2023 00:25:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=PwqJOlfy; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.83 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=1691022343; bh=7vgFcTS5NnnVOuTqICPCCZ7NlvYILazgKb1X5VNPlcg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=PwqJOlfyoWKNDhh5g8CrrlqFbCA2SYKhs+v7EtMgtF3+fl5zeltY6qaNe/1vhi+3P4NSX1dSZavtFd515HwIJOAAK7J1fhDopk7o3V0Clg0weNv3GWSx9uVaet27TENRMuE8VQY14OcheJFBvMXLjmUztOJI4ThEoyvyR93ab1BTN2AmRutwsn/foeCU5mMWOe2xhvs44rBoRTNSsbvcdbhN092cPv85cGAHVrmWZyIb+cJ5PFXdOI0Umqo3dHAE185xERI8TODeVaixHt6S3WGYRHv49MJw1ahZioa7I/mhTY9iQV6VL+M/hTwpOSITnueDAFbBmNHr/P0a/he9Ng== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691022343; bh=Bz839wEH36LJkD2IO5r72zQ+ZFn3PstTef4O/5kwBmA=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=lrKkto98oa0ngis4wQv5kWN44j9Ja5z66ZjyLj3Ql0eNHWrIiD0/1R0tYc7U3sawK4sdNf6oN3yZt0Jtb0RUl3mOLPnEkTxnLDCrD5Hx5QxXc3EREP2wPLg8CPky6L0StYxLDOyH0rdkl9FzrJk+KXPYKfQkaUHDwOL96QEtDN2Sj3oc39wwse9ZlU7u6vrqWIdhzw8eCp2f4PIfK9ClPD47IqQkQBlalf/wgfTkX0/kpgwgTERCaCmynD56MjT8W8J1zN8ottysfvmHYTNEBynzqHR547ThUIpqi/hV6DRJHODcLBVmCmgOSMmXBF/g5A825XEU/Bg7ZZhyGcenyg== X-YMail-OSG: diAmh4kVM1lRg4katyIproR3XLe7nWYArFXNy6JhCt8Du.26aCX0kJeoce2tJwt vdEHxl5qHNsHsjUCJcecmEOLz59174O8EsO1hENOD2ShNlhurfGjcYNQ97oPoQUSnn9BDkryPQ8U r1GPxR44FHiIKoapu_us.qnxnHCK24TYee2vZuE_eJ0VVSlXaQGmNFITeYFl56E2hYxq5gJKuuIu Am7zKreDbT1jABkXtcGf8y0uga8fR1.kpIDZhrCr7A7taO9SPAM5akXGNlfDDhgKW00YuVP_4deZ dPcahgll13QzuENGrsWz2zX8zBTeS4rhLrpKG_fEtIpCLN1_.G9Qnu3naUXeB1lBIY.TEvNxWjmA CxZjwVIwtBEDxlwPVR5NwE0UMIEYLKUsiFtpZ_1.USaAd47.qShEQXD70ASs_8OQMufqUwZLaWur 0.Fm3kpde_9JZd0xcJ7d4jzuVncmRsMgLOrZ94DQ8c.SeK_H_siQ_QhbFdAqcN2gn3t7WU3tBQe4 tvzSjdMRAU.BDEj50XBEqltMRexAea3YPZnxzyZHw8BUuP8x7eqkNZn_iavs07H6aGie6QopDdAM aZHCJ98G_pu.fHJ9mofMEKJV3fJw570fj17P9QU5G6QExYOm3RxM78eo82s5XqyvA.wZQQT09UFQ KY4HSgQJwQEJaEEVVycVzeIyoq1.0lLxpUVNHB2HLu.CzqovoTL2cC3pODZhIR.m5Sp7_B93piMF oCDVIIVWeLPvLUNWzKAK3upDhbuEw.EaaE5E9Pnk0C8JZj10TaUytjxmVp.KjLPE2v5sZENuk_FQ 6bfOP7uDOclaxLUPtyhNg21ii7S8sM_IuHspxZq3FoJHKfYsIGZ9rrTmYr3eU3_VxVBymsoppT3u friDaDCFZZrNjYX4g0tIWZENNsZOAYVIAPwKiY0uQ.KfxHl2m0h5gn6IuK.x4tcp.1s4Hb4MOiO9 OaGcrhNRccKHzrCDeaACin6nNhDGPEMilMlU2_lbB9q2o8pwpK11ja.ThooasKi7VUfV7Mu4TbKu gjj_VCcq1QZGMFglz7g6XQbKAJ0D6NO88HKGXrrZ0ADw0qo84bg93YYWsA1iUQhru0BG2izW6JcP Cu1cAyFTW0Cn8nt0jnAkuao9xaKihkC19PRCVLQN9Z8.FeiXGLJOEtrjScmnb2qZ7QllFpbO0PSJ OyZPynQD1ZLp35iRIGMB9fOeG4zDRipmydcWIPTpHaM6k_je3eXmzDn1aIuzgZP3.74lkBZfAPem MUz_4Ne1oa1rZwsXXX9qQbk.go3LZkSQAkvfVD4KQoWzikYBjYysKxMSOfAfu9dVZuqTbsCXxJhm 84UOYhiBmhTQQcTqNrlziHuChzsNLbLlapKjTq5.hVIya3IMkfb64eS48T3DWni8I4wE7qSfs.Yu pDpCglKrbm2z13mDsOCxPb9hfGD_Lg9jfU7DDr8TG_4oMvCwOKg0.CTlvSBwKdSk0aHo5GJqm.1E 2Hbc7K_Fpk1XB9Zv42Mi2WOUPesj.Xffax3tGt_v8gBtNM7rZvj71QofaEDy4XPZJ3PaILe1HhjY 4L0x5wNAbs1LGWfI54k.1RyXIramIwzvm5vPN_6Sd_3bZPYCO8eyI8qqc_7WhNIsf3ilsPlIU0Ey 4afgtkzxf.NQHdz94lliS5uy2QfK7KYJsOrZl78u1W_ly_jQqIM5fNrnC_MRSvl4izugERpIOd.8 N1Zhb_9UsOrccd7J.uRlJKafsW7TKQ2hjO6cTIuhkTplZch5yOw3k3WUutZ3EuPrV6SkpLqGsfay BZc8.ZpRNEHXRRMJBeZ_XRZLjjiDei3VLhiXM2VDiWHPz.InL3ST85GzbmTUZ_JiYiLWrYIBCjbg LRkMcMkMoErO5fBmUq7sP_oc6uDoWcGL1us1mdMQz1cHXPXfjd5eLog2IKiddcD3FxBzlPeSHHfB c6I.TyaqK13ThGR6qaDDWKyPnlgfhcekU0hCTgLEFDWAZD2q7yiilv6kjpgvOe7Kb8lseedvTx5V DFWcchLeNJ2ME1d.xZz9VnH.wnc4ZlOrsAJmcp48pN2BHGiHcJbyWKWaKCPJqj3RL9KNR6gIAZET tP5lA5WJeJhFWw6SVxRtRQ6FDsEnbVe1r2bUwWqHeKZDK6sjpn5GHBkgVjhg6KaNIlgVemSwGoOa d_3Vdtn4RSwTb35ZAIJt65q.w631nWjR29_dnEUHKV5xNR6XbApF17C6DtgUIsaDNCAXdjrTeXUN 5b3Xgn9Jc7LhLHPg9zV7XB3uOLZEyrOsrU9uU3gxb17UWJM_.r06TuV.tD01lFDn.vn_2A6f57jl 7l0aU X-Sonic-MF: X-Sonic-ID: ba0e873d-20be-46b1-b600-88b7165ca695 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Thu, 3 Aug 2023 00:25:43 +0000 Received: by hermes--production-gq1-7d844d8954-l5pzx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID adb52329811117f2cb148214802152e4; Thu, 03 Aug 2023 00:25:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: sys/modules/Makefile and MACHINE_ARCH vs arm64 (in use) vs aarch64 (not in use) VS. man arch; also COMPAT_FREEBSD32_ENABLED use From: Mark Millard In-Reply-To: <2B0FE8B1-5E53-4E70-9792-15A8E423CA33@yahoo.com> Date: Wed, 2 Aug 2023 17:25:29 -0700 Cc: Current FreeBSD , FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: References: <2B0FE8B1-5E53-4E70-9792-15A8E423CA33@yahoo.com> To: Warner Losh X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RGV4V4jlGz3vjw X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.35 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.85)[-0.851]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.83:from]; BLOCKLISTDE_FAIL(0.00)[98.137.65.83:query timed out]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.83:from] On Aug 2, 2023, at 12:56, Mark Millard wrote: > On Aug 2, 2023, at 11:16, Warner Losh wrote: >=20 >> Those all look wrong to me. >>=20 >> Warner=20 >>=20 >> On Wed, Aug 2, 2023, 11:27 AM Mark Millard wrote: >> man arch reports: >>=20 >> MACHINE MACHINE_CPUARCH MACHINE_ARCH >> arm64 aarch64 aarch64 >> . . . >> arm arm armv6, armv7 >>=20 >> So I'd not expect arm64 in MACHINE_ARCH . But >> sys/modules/Makefile has (from a grep for MACHINE_ARCH): >>=20 >> .if ${MACHINE_ARCH} =3D=3D "amd64" || ${MACHINE_ARCH} =3D=3D "arm64" >> .if ${MACHINE_ARCH} =3D=3D "amd64" || ${MACHINE_ARCH} =3D=3D "arm64" = || ${MACHINE_ARCH:Mpowerpc64*} >>=20 >>=20 >> Another issue may be that COMPAT_FREEBSD32_ENABLED is only >> put to use in the Makefile for MACHINE_CPUARCH being i386 >> or amd64 : >>=20 >> .if ${MACHINE_CPUARCH} =3D=3D "i386" || ${MACHINE_CPUARCH} =3D=3D = "amd64" >> _agp=3D agp >> .if ${MACHINE_CPUARCH} =3D=3D "i386" || = !empty(COMPAT_FREEBSD32_ENABLED) >> . . . >=20 >=20 > I'll note that, for example, i386 vs. armv7 do not match > for some struct md_ioctl field offsets and the overall > size. Turns out no member offsets were different but the size was: just differing tail padding in the structure. Still it means some conditional differences across i386 and armv7. (I've no clue if the 32-bit powerpc lib32/chroot handling is working on powerpc64 vs. not. So I make no claims relative to such.) > Mike Karels is looking at getting struct md_ioctl32 > correctly matching each of of the contexts: i386, (32-bit) > powerpc, and armv7. >=20 > I do not know if there are other COMPAT_FREEBSD32 adjustments > needed for differences in memory layout across the 3 (i386, > powerpc, armv7). md_ioctl I learned about via kyua test runs > and looking at the background for some things it reported for > armv7. >=20 > I've not found a clear indication of what is expected to work > for chroot/lib32 vs. what is not expected to work. It seems > one must look in the code and see if one finds conditional > material based, in part, on COMPAT_FREEBSD32. It might also > be that COMPAT_FREEBSD32 for i386 vs. armv7 vs. powerpc > might not be intending identical coverage for all I know. > So seeing COMPAT_FREEBSD32 might not be enough to know the > intent. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Aug 3 02:25:50 2023 X-Original-To: freebsd-current@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 4RGXlh4fQ8z4dJMX for ; Thu, 3 Aug 2023 02:26:03 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 4RGXlG2lyBz47Sp; Thu, 3 Aug 2023 02:26:02 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oi1-x235.google.com with SMTP id 5614622812f47-3a44fae863fso342908b6e.0; Wed, 02 Aug 2023 19:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691029560; x=1691634360; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Qa2lDLEyUW+TWVGbNeIXSvlymIHKZsJsCn6GNfiBfmo=; b=OKh8Non6YDwXaZBv/31HdEVZxyZGHccURC5B80sHqb4oQBzgkHiPy9C20w5nx6AG+U Hwt2g8dJEaPfIi2NBDl5fWdx3x8TzP6ZoA07Lpl3WfQ/gL9cVb2XVYqaH0iOy+ncGOJ+ f3M28zD8e7FFSbQCMjHKp9S7po+R7LBQR6ae/JPgOBdHGIxyRsg+XCmhMMywUoff51LF HggwpJ9OH1oMlxSiYonWz/CwIgR4EBRqOjyQMP27ABg8+RY86wptzXblANrgyA/xB9TY aaNNM/brUd1TA1JGvcoD6Un2KjUF8yGUDoftobWnyffRVKwzPQagBW/jspfaxKsz5zvL l0Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691029560; x=1691634360; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Qa2lDLEyUW+TWVGbNeIXSvlymIHKZsJsCn6GNfiBfmo=; b=PA6n3n0lkzNIAnRPHVsvW7fVSodVV/wreIHmEhY8I1GYTwM8iJ7COzc+6+LYauJanN a6clwy2dHbi/I65EVrRkZg9O+Ex3h13JoaKJ9R/b166e2JGdLSkurWcOsiOHJvqdjoP3 dSiUOe6oFdL8ZNOoDo7FfRIN8tRLQi0CdUozijMNrWLnqBI39oqNb3f04ei0ktGS1KBz 4+vX3Aaww7N42TtxdeWECy+Kn2976Mk/Nk6UN3oEXQ2hkZKlU6hiOnGxYQNCt+5PLV5n jsGQoOOl0u3TUukyUhwjmM4JvNRBXg1Nq+H1vgblGHxmakr/F9mlxENNpsS3SXwdyRBO 09xw== X-Gm-Message-State: ABy/qLYRAg8qGFc71mbBRCAgc75S1zhSgPJshyIdfKsnzXD4td5SiAOS 5qsVgC7/euWlej02206/x9xcudknhA1OpHPa5A== X-Google-Smtp-Source: APBJJlF/aSyJhEgAVltsdkCaUen5yM6yo9H0uD0SGaLW/Vhp1pdUrlh2AwnzaIO5C/KLYEoHceX3ZJWpx2A2oQ29yb0= X-Received: by 2002:aca:1e04:0:b0:3a3:6f20:39b4 with SMTP id m4-20020aca1e04000000b003a36f2039b4mr17192856oic.29.1691029560160; Wed, 02 Aug 2023 19:26:00 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Wed, 2 Aug 2023 19:25:50 -0700 Message-ID: Subject: Re: Review of patch that uses "volatile sig_atomic_t" To: Konstantin Belousov Cc: David Chisnall , FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4RGXlG2lyBz47Sp X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[] On Wed, Aug 2, 2023 at 6:14=E2=80=AFPM Konstantin Belousov wrote: > > On Tue, Aug 01, 2023 at 04:33:16PM -0700, Rick Macklem wrote: > > On Mon, Jul 31, 2023 at 11:33=E2=80=AFPM David Chisnall wrote: > > > > > > Hi, > > > > > > This bit of the C spec is a bit of a mess. There was, I believe, a de= sire to return volatile to its original use and make any use of volatile ot= her than MMIO discouraged. This broke too much legacy code and so now it=E2= =80=99s a confusing state. > > > > > > The requirements for volatile are that the compiler must not elide lo= ads or stores and may not narrow them (I am not sure if it=E2=80=99s allowe= d to widen them). Loads and stores to a volatile variable may not be reorde= red with respect to other loads or stores to the same object but *may* be r= eordered with respect to any other accesses. > > > > > > The sig_atomic_t typedef just indicates an integer type that can be l= oaded and stored with a single instruction and so is immune to tearing if u= pdated from a signal handler. There is no requirement to use this from sign= al handlers in preference to int on FreeBSD (whether other types work is im= plementation defined and int works on all supported architectures for us). > > > > > > The weak ordering guarantees for volatile mean that any code using vo= latile for detecting whether a signal has fired is probably wrong if if doe= s not include a call to automic_signal_fence(). This guarantees that the co= mpiler will not reorder the load of the volatile with respect to other acce= sses. In practice, compilers tend to be fairly conservative about reorderin= g volatile accesses and so it probably won=E2=80=99t break until you upgrad= e your compiler in a few years time. > > > > > > My general recommendation is to use _Atomic(int) (or ideally a enum t= ype) for this. If you just use it like a normal int, you will get sequentia= lly consistent atomics. On a weakly ordered platform like Arm this will inc= lude some more atomic barrier instructions but it will do the right thing i= f you add additional threads monitoring the same variable later. In somethi= ng like mountd, the extra performance overhead from the barriers is unlikel= y to be measurable, if it is then you can weaken the atomicity (sequentiall= y consistent unless specified otherwise is a good default in C/C++, for onc= e prioritising correctness over performance). > > > > Just trying to understand what you are suggesting... > > 1 - Declare the variable _Atomic(int) OR atomic_int (is there a prefere= nce) and > > not volatile. > Really does not matter. > > > 2 - Is there a need for signal_atomic_fence(memory_order_acquire); befo= re the > > assignment of the variable in the signal handler. (This exists in > > one place in > > the source tree (bin/dd/misc,c), although for this example, > > neither volatile nor > > _Atomic() are used for the variable's declaration. > In mountd, there are two signal handlers. One for SIGHUP, and another fo= r > SIGTERM. They are very different, let me explain. > > For SIGHUP, the only action in the signal handler is the assignment to > the variable. The assignment itself is atomic on FreeBSD. But what is m= ore > important, there is no ordering issues between this assignment and any ot= her > action. Eventually the main execution context notices that the variable = is > set and does something (re-read config). As consequence, there is no nee= d > in any fencing of the SIGHUP handler. The only concern would be that the setting of "got_sighup" would get lost d= ue to some compiler optimization and it sounds like _Atomic(int) is sufficient= to guarantee that will not happen. rick > > > 3 - Is there any need for other atomic_XXX() calls where the variable i= s used > > outside of the signal handler? > > The SIGTERM is different, it does some rpc bind calls to unregister itsel= f > as a mount program. If these actions can interfere with the main context > execution (I believe they are), then userspace rpc bind client state can > be corrupted, resulting in failing attempt to unregister. > > No amount of atomics or fencing would fix it, the unregister action shoul= d > be either moved out of the signal handler context to main context. Anoth= er > option might be to block SIGTERM, and only unblock it in places where it > is safe to do rpcb calls from interrupt. This is approximately what dd(1= ) > does. Yes, I think moving the termination into the main context should work. I'll do that as a separate commit/review. I suspect that failing to de-register doesn't cause too much of a problem. since the client won't be able to connect to the port# after mountd has terminated and will fail (just maybe not a gracefully). Same would happen if mountd crashes for some reason (and not terminated via SIGTERM). rick > > > > > In general, it is looking like FreeBSD needs to have a standard way of = dealing > > with this and there will be assorted places that need to be fixed? > > > > Thanks, rick > > > > > > David > > > > > > > On 1 Aug 2023, at 06:14, Rick Macklem wrot= e: > > > > > > > > =EF=BB=BFHi, > > > > > > > > I just put D41265 up on phabricator. It is a trivial > > > > change to mountd.c that defines the variable set > > > > by got_sighup() (the SIGHUP handler) as > > > > static volatile sig_atomic_t > > > > instead of > > > > static int > > > > > > > > I did list a couple of reviewers, but if you are familiar > > > > with this C requirement, please take a look at it and > > > > review it. > > > > > > > > Thanks, rick > > > > ps: I was unaware of this C requirement until Peter Eriksson > > > > reported it to me yesterday. Several of the other NFS > > > > related daemons probably need to same fix, which I will > > > > do after this is reviewed. > > > > > > > From nobody Thu Aug 3 04:48:08 2023 X-Original-To: freebsd-current@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 4RGbvT2DKpz4n4sq for ; Thu, 3 Aug 2023 04:48:21 +0000 (UTC) (envelope-from drskorp@gmail.com) Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com [IPv6:2607:f8b0:4864:20::1130]) (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 4RGbvS4CH8z3kZ3 for ; Thu, 3 Aug 2023 04:48:20 +0000 (UTC) (envelope-from drskorp@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=YzDMD4O3; spf=pass (mx1.freebsd.org: domain of drskorp@gmail.com designates 2607:f8b0:4864:20::1130 as permitted sender) smtp.mailfrom=drskorp@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-5860c7fc2fcso5153507b3.2 for ; Wed, 02 Aug 2023 21:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691038099; x=1691642899; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=z1k9QrylkeQv2+W464dzEStsEdEt6HeWLgySLbjSaZE=; b=YzDMD4O3jm+/5ZOy9AcETyerc1JxjBH+EeMbBw8Gx8TibRlknjIS5SgWAiEdVHp0NX SCqJBOpJ/TprZnHiVhhmQW77sRLQNCZcByGWoYesRVhOSDnPlhybe5D8xs1dtP/lqJXe s7b8XsHgi6CrBJrw0vKBRhIZC5GiT6Ha/jnG6B8H4PzclbXAPP8fu9Rgax9tcWTFCfS7 9iP5DDuvDSkeO63jzoc2z52ZUu9ULZhV+NfsGYPHn4ej6ftf7nnd5jRwSDhY32/ueSAb Z5RPDKVfHPFKIPpt9cEhK0EVfulQ9jZUCGze9wJXWObjLVxID0p1EITshcKK1XpJXE/3 by+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691038099; x=1691642899; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=z1k9QrylkeQv2+W464dzEStsEdEt6HeWLgySLbjSaZE=; b=bmpR+yNDCaGktWHyzR9NMGOpAFHI4NMUloMCerwtqMBk7gzKVwm7yVS3pNr0FkJXus /H7IpAo9dwf4nxslUqqyv08m+A3o5QBA37fGHF/5XS4rYYDlsFd7llRFu6UPn+bqr95b 7Oiqk6x2Ab2KctLYDrZzfNfa0xjaKl+fao34mo81hPmAZUHee76b9GK6StIFORvl8SSC NC2SRulnUG71zpxausSF0bchpqeBC5UIJG0mnteEXIXhrc7M1HIPiqx61p8SyPUceLgo U4YAG1v01lZwueHDtUQu0R1wP7+sIZeNWBV1KhbmDsB6Z4WMVhfqP7aSkGzx8oQhWD6w DrZQ== X-Gm-Message-State: AOJu0YyIUn5UQ+Nb9oYJswk8P7sE3rfTOTVIpMLUCSjF8gT3QAhIjd23 QNxDettl2YaE6d+eOvR4Nvsas49NDyVnURVKYDVzpad4wRk4AjF4 X-Google-Smtp-Source: AGHT+IHIEpmDLT0zs1Kb3xcf1xsRMJ3ik7NGUod9dOKSk3QVos3U98l1j12oXipzBr1gHKqZS56Y36bMDSfzHJ2fY8Q= X-Received: by 2002:a81:a04e:0:b0:586:8d9c:e8c8 with SMTP id x75-20020a81a04e000000b005868d9ce8c8mr1246681ywg.40.1691038099714; Wed, 02 Aug 2023 21:48:19 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: skorpio dr Date: Thu, 3 Aug 2023 03:48:08 -0100 Message-ID: Subject: Bhyve NIC Passthru broken To: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="0000000000003c36770601fd7d3f" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.27 / 15.00]; NEURAL_HAM_LONG(-0.97)[-0.970]; NEURAL_HAM_SHORT(-0.67)[-0.673]; NEURAL_HAM_MEDIUM(-0.63)[-0.626]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1130:from]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4RGbvS4CH8z3kZ3 --0000000000003c36770601fd7d3f Content-Type: text/plain; charset="UTF-8" Hello, Starting a vm (FreeBSD 13.2) with passthru NIC results a constant flood of error messages on the host (FreeBSD 14-CURRENT). The NIC refuses to work in the vm (it works on the host if I turn off the passthru). This problem is persistent since 13.1-Release. (Sidenote: the passthru mostly works under the EOL 13.0-p13 with the same config, only occasionally showing the symptoms after multiple vm reboots, and a host reboot solves the problem unlike in 13.1-release 13.2-release and now 14.0-current) Ruling out NIC/board hardware fault and specific NIC driver problems, I've tried with the following NICs: - Intel I350-t4 - Intel 82580 - Broadcom BCM5720 ...in different desktop and server boards (with the latest BIOS): - Asus M5A99X EVO R2.0 - Asus M4A87TD EVO - Asus KGPE-D16 # freebsd-version -kru 14.0-CURRENT 14.0-CURRENT 14.0-CURRENT /boot/loader.conf: vmm_load="YES" nmdm_load="YES" hw.vmm.amdvi.enable=1 pptdevs="8/0/0 8/0/1" # vm passthru|grep ppt0 ppt0 8/0/0 Yes 82580 Gigabit Network Connection the vm config file for vm-bhyve: loader="bhyveload" cpu=2 memory=4G disk0_type="virtio-blk" disk0_name="ptproba.img" # igb0: passthru0="8/0/0" uuid="2333ba09-dfe1-11ed-9ed6-9c5c8e54ad77" vm-bhyve.log: Aug 03 02:25:16: initialising Aug 03 02:25:16: [loader: bhyveload] Aug 03 02:25:16: [cpu: 2] Aug 03 02:25:16: [memory: 4G] Aug 03 02:25:16: [hostbridge: standard] Aug 03 02:25:16: [com ports: com1] Aug 03 02:25:16: [uuid: 2333ba09-dfe1-11ed-9ed6-9c5c8e54ad77] Aug 03 02:25:16: [debug mode: no] Aug 03 02:25:16: [primary disk: ptproba.img] Aug 03 02:25:16: [primary disk dev: file] Aug 03 02:25:16: booting Aug 03 02:25:16: bhyveload -c /dev/nmdm-ptproba.1A -S -m 4G -e autoboot_delay=3 -d /root/vm-bhyve/ptproba/ptproba.img ptproba Aug 03 02:25:22: [bhyve options: -c 2 -m 4G -AHP -U 2333ba09-dfe1-11ed-9ed6-9c5c8e54ad77 -u -S] Aug 03 02:25:22: [bhyve devices: -s 0,hostbridge -s 31,lpc -s 4:0,virtio-blk,/root/vm-bhyve/ptproba/ptproba.img -s 5:0,passthru,8/0/0] Aug 03 02:25:22: [bhyve console: -l com1,/dev/nmdm-ptproba.1A] Aug 03 02:25:22: starting bhyve (run 1) The first few dozen messages are like the followings (couple of hundred lines): ivhd0: EVT INTR 0 Status:0x1a EVT Head:0x0 Tail:0x10] [CMD Total 0x24] Tail:0x240, Head:0x240. ivhd0: [Event0: Head:0x0 Tail:0x10] [INV_DTE devid:0xa0 addr:0xfdf9103300 type:0x3 tr:0] ivhd0: EVT INTR 1 Status:0x1a EVT Head:0x10 Tail:0x20] [CMD Total 0x26] Tail:0x260, Head:0x260. ivhd0: [Event0: Head:0x10 Tail:0x20] [INV_DTE devid:0xa0 addr:0xfdf9103300 type:0x3 tr:0] ivhd0: EVT INTR 2 Status:0x1a EVT Head:0x20 Tail:0x30] [CMD Total 0x26] Tail:0x260, Head:0x260. ivhd0: [Event0: Head:0x20 Tail:0x30] [INV_DTE devid:0xa0 addr:0xfdf9103300 type:0x3 tr:0] ...then the constant flood (about 35 lines per second in /var/log/messages): ivhd0: [Event63: Head:0x3e0 Tail:0x8d0] [INV_DTE devid:0xa0 addr:0xfdf9103300 type:0x3 tr:0] ivhd0: [Event64: Head:0x3f0 Tail:0x8d0] [INV_DTE devid:0xa0 addr:0xfdf9103300 type:0x3 tr:0] ivhd0: [Event65: Head:0x400 Tail:0x8d0] [INV_DTE devid:0xa0 addr:0xfdf9103300 type:0x3 tr:0] Any idea? Best --0000000000003c36770601fd7d3f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,
=C2=A0
Starting a vm (FreeBSD 13.2) with pass= thru NIC results a constant flood of error messages on the host (FreeBSD 14= -CURRENT).
The NIC refuses to work in the vm (it works on the host if I = turn off the passthru).
This problem is persistent since 13.1-Release.(Sidenote: the passthru mostly works under the EOL 13.0-p13 with the same= config, only occasionally showing the symptoms after multiple vm reboots, = and a host reboot solves the problem unlike in 13.1-release 13.2-release an= d now 14.0-current)

Ruling out NIC/board hardware fault and specific= NIC driver problems, I've tried with the following NICs:
- Intel I3= 50-t4
- Intel 82580
- Broadcom BCM5720

...in different desktop= and server boards (with the latest BIOS):
- Asus M5A99X EVO R2.0
- A= sus M4A87TD EVO
- Asus KGPE-D16

=C2=A0 # freebsd-version -kru
= 14.0-CURRENT
14.0-CURRENT
14.0-CURRENT

=C2=A0 /boot/loader.con= f:
vmm_load=3D"YES"
nmdm_load=3D"YES"
hw.vmm.a= mdvi.enable=3D1
pptdevs=3D"8/0/0 8/0/1"

=C2=A0 # vm pas= sthru|grep ppt0
ppt0 =C2=A0 =C2=A0 =C2=A0 8/0/0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Yes =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A082580 Gigabit Network Connection
=C2=A0 the vm config file for vm-bhyve:
loader=3D"bhyveload&q= uot;
cpu=3D2
memory=3D4G
disk0_type=3D"virtio-blk"
di= sk0_name=3D"ptproba.img"
# igb0:
passthru0=3D"8/0/0&qu= ot;
uuid=3D"2333ba09-dfe1-11ed-9ed6-9c5c8e54ad77"

vm-bh= yve.log:

Aug 03 02:25:16: initialising
Aug 03 02:25:16: =C2=A0[lo= ader: bhyveload]
Aug 03 02:25:16: =C2=A0[cpu: 2]
Aug 03 02:25:16: =C2= =A0[memory: 4G]
Aug 03 02:25:16: =C2=A0[hostbridge: standard]
Aug 03 = 02:25:16: =C2=A0[com ports: com1]
Aug 03 02:25:16: =C2=A0[uuid: 2333ba09= -dfe1-11ed-9ed6-9c5c8e54ad77]
Aug 03 02:25:16: =C2=A0[debug mode: no]Aug 03 02:25:16: =C2=A0[primary disk: ptproba.img]
Aug 03 02:25:16: =C2= =A0[primary disk dev: file]
Aug 03 02:25:16: booting
Aug 03 02:25:16:= bhyveload -c /dev/nmdm-ptproba.1A -S -m 4G -e autoboot_delay=3D3 -d /root/= vm-bhyve/ptproba/ptproba.img ptproba
Aug 03 02:25:22: =C2=A0[bhyve optio= ns: -c 2 -m 4G -AHP -U 2333ba09-dfe1-11ed-9ed6-9c5c8e54ad77 -u -S]
Aug 0= 3 02:25:22: =C2=A0[bhyve devices: -s 0,hostbridge -s 31,lpc -s 4:0,virtio-b= lk,/root/vm-bhyve/ptproba/ptproba.img -s 5:0,passthru,8/0/0]
Aug 03 02:2= 5:22: =C2=A0[bhyve console: -l com1,/dev/nmdm-ptproba.1A]
Aug 03 02:25:2= 2: starting bhyve (run 1)

The first few dozen messages are like the = followings (couple of hundred lines):

ivhd0: EVT INTR 0 Status:0x1a = EVT Head:0x0 Tail:0x10]
=C2=A0 [CMD Total 0x24] Tail:0x240, Head:0x240.<= br>ivhd0: =C2=A0[Event0: Head:0x0 Tail:0x10]
=C2=A0 =C2=A0 =C2=A0 =C2=A0= [INV_DTE devid:0xa0 addr:0xfdf9103300 type:0x3 tr:0]
ivhd0: EVT INTR 1 = Status:0x1a EVT Head:0x10 Tail:0x20]
=C2=A0 [CMD Total 0x26] Tail:0x260,= Head:0x260.
ivhd0: =C2=A0[Event0: Head:0x10 Tail:0x20]
=C2=A0 =C2=A0= =C2=A0 =C2=A0 [INV_DTE devid:0xa0 addr:0xfdf9103300 type:0x3 tr:0]
ivhd= 0: EVT INTR 2 Status:0x1a EVT Head:0x20 Tail:0x30]
=C2=A0 [CMD Total 0x2= 6] Tail:0x260, Head:0x260.
ivhd0: =C2=A0[Event0: Head:0x20 Tail:0x30]=C2=A0 =C2=A0 =C2=A0 =C2=A0 [INV_DTE devid:0xa0 addr:0xfdf9103300 type:0x3= tr:0]

...then the constant flood (about 35 lines per second in /var= /log/messages):

ivhd0: =C2=A0[Event63: Head:0x3e0 Tail:0x8d0]
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 [INV_DTE devid:0xa0 addr:0xfdf9103300 type:0x3 tr:= 0]
ivhd0: =C2=A0[Event64: Head:0x3f0 Tail:0x8d0]
=C2=A0 =C2=A0 =C2=A0= =C2=A0 [INV_DTE devid:0xa0 addr:0xfdf9103300 type:0x3 tr:0]
ivhd0: =C2= =A0[Event65: Head:0x400 Tail:0x8d0]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [INV_DTE= devid:0xa0 addr:0xfdf9103300 type:0x3 tr:0]

Any idea?

Best
--0000000000003c36770601fd7d3f-- From nobody Thu Aug 3 07:19:27 2023 X-Original-To: freebsd-current@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 4RGgGC2H5Qz4mLPL for ; Thu, 3 Aug 2023 07:19:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-20.consmr.mail.gq1.yahoo.com (sonic310-20.consmr.mail.gq1.yahoo.com [98.137.69.146]) (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 4RGgG94Hvjz3DPw for ; Thu, 3 Aug 2023 07:19:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=rElXsda6; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691047183; bh=zb2Y3a5kCP+kGWFwNO9kNfEDYsQ/ILOSxlnBngaYA/A=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=rElXsda6QH8+U0F8R06g/859/+Qwzv2x09ys5seAJt5LHc1fB+H1Iry8i0MKFtTl1SH9nfHXEEEWpdP8yKg5wqg+rSJchRtjBVhXC0dcAzlfqbSYR62EqE4kOwTR2yMrwh6hsbnurn1VmILGz2gkuirnZCXkq56mI2ZnNzbSZkhxY8aVzySRQycblVmbVMs7242yDw/ymT2ebQA9EMH3RptHzC0tUT4VMNUCLzOKKvlBlPkVIzVJmZmurYov+ppeE56e+1TEzeOYHdVEUNXZNSOUiAsIp98AeYxAp429VUPkCodC8Q7++eTqAC0LNOxSIksGT9EOLgztHxpQTd+ZwA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691047183; bh=G4crm/tHTT3KjCXoRFc5KRJejiK9EEFfPYOf88kawID=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=SbUlM/cmo5ghFponfH3vf/CnAvwSVfFcfa4ORVpNLSxg8jq1FwUHNYZtzcoYJEnb0KmXEOGbsRhj6uqZd1eAonrBEFbxTNJGgS++s3LWsR2wUoS7R9sXd2lR8QaXCkHCbP1eWX/ScZNQfPkEd+2JyhgbBgF6JoAWpWjn0WVZZJky+nnIxmjM6gDQw+46Kh/aEZ1iyvVIg0QH2ZSU+eGUyDiSPzW0lp8f3cmlv8mrZ7oz/idZnU75vR78lYoqEMZGLEu42k9CMzokKQ/abAS/4YKTBYxFzCx9butXsKAgEUtHvAKdvAKIeBM95+fBnVWC5A51kJLwPzBo3s+LkvkdQw== X-YMail-OSG: rt6HtBIVM1koMXbQj8hJJdUuoMhX3qKpYMUqpkVqfE_qC4uv1nz882sFyLXAztV .FYFVibMWFsESu9RPWSuucVgOSSU8KBw_rd3RVnEGPHIJFu6v_ce23D45sKKsL7z.SPDOWhO.ugJ qtmEqZCFez5MjKN7brhx8ZKVl6eaaD6l1W0mqbXQgnsC4ckHus55ov6JlNTpePd8KC0geUWjJGAp bm.bnW0UQ158zuWhnz.M9DAnrZhEp9jgltTOz3K_AulTFhPHPe57Zf1oK5s0FM5FSXl9wwI884oH B1pj87tU2FTqgH4Ur5Qoo4zRmdS6MFZJmcXZi6j0sXTmvfC05rPLmRSqrwyTgsdtPLQiSy7VoEWl Wmjhzsp.Rfsxk9Wap1MLMmW.gOLkDg.WJSreTl6hoYAo3RzxX2RxfZXs2sLmYO6bc82YDb5sleYe QIa0QShD4VAEfC3S6mpechOy74daIwavyaRfdD8rduqVeN7movH0ew77rMAUw63L.0qLGiuSbLvE MmAv6blNlfcjbAe3a8X2n8_ReTb5vl1nkpxMNUUvFy6v3v1RVheeu2ZIrgYYnZYh1ZKPJzpE3rEv Zmzo2lJdC3K6xJ2uInJ7zJN6EdOBLs549v3GYaMYJOtrEMpQCtR5HJQ94LvHv9qmwneyErhWNmoR vqY4ZcI_Wg.6eOd6KRm7YAG9FEXgz5J4wmdCO7CIObpRqr3kJKAn4QpHnuBsL5IocND1sTWNSnQB hE2lCuqBr5MMXi7MUeyhWv9TEcCT6pWc_xQFH30wvuMimycJCE_8062oNbgBxUwzFtc4kjAnFTP5 keNkBpCh.PJlzaEUx6dSPnZ1Eipm1pR0EqQ_rnFNoxive_J1HzoZ917Bn50w2bU2WWj_11uk6ugY 9UsCjcFTiYrH2Pt5Uic8VRNq4CdmY18g8UEi8NgbVssXlfuA0LDn5KE1FDd6R7yGUe51JLon1lJu X.gXnYJjBrRktgpSTMMWzaSX.i9keFaS6bQJICuUSHprtHy7Zse3m_ss59mi_rs6ArB.DXoUJQqw OZGaM31A.hYyDQcNiNotjUdxTUSl3wwBOzM5OtHrezMswz.O4ypYwo_.MGDusymVEYqF9hK9IoES 0.dt3KR5.1Ip4DIdDGzI6Q_MURpoDJfm74w5QpoJMMtzdK07r6e95gmwqUfgd1f4l5EWFm7CWxQp T3kRjjahwx_NkkQLveN0zJbeiVnGtbW7JVTRWy3WFo5DfxuWPhCN_5FYWsG1xdGx7AatD768YcQ3 OdF9J6mitX_CipPisjFahtEqWm.8O5eF4T4rKMBHwfPp9nmqqHE2jVGFdXXkmVhOxb9hcE2qavXB uDZAq8DRUTLUUpXYQ8ccsB4EVryEA.5BKvGm3uaDo2INnv4xWqQ3RNeD80y6Kmsb4mjpduoJOAsp 3vBQK8GBdJas70pjQED5upYdZ7KSt6v0om050Emm2tpbKyIAStrAcgixAsv.N_97VmXXr1654hzT i3YJ3hXBSx1jdv7Z8jjzc9NwKhr60.qJMQ9EX0miSaw7yg7SWbFqBS.JabrdIgwLQow5VozXWitW DQI3jgwBwAdojtBxAzyvcGOlCTV1ESutR0ZTmFv4taASEEvHu3ZOMBQjaafJUsA.1FCWYjYZ2Gjz N9WDFAVmN1u.d8bH8mOEVAJ.EK3arrXbNeoBlei7yphmFGYyr1t_5gE0L5lLnmHWcBHobD740QGb KmrmUwh5kq0gCZPPUwsJ1dfPQ.kugnXcJ2D08ps6LmbCFJUJEHYedEJ.Crp6fQeUgd.4IR.cbezW R34GcFM1JR42cGpb8kEfTTcRp21RbO7pWxkwehws8aK2u3lvXw3uKcVK8NVjnRa_dC2SuK5xJd3k EndBLNQ2J08VObtGAYxE7jBDa_FaV6bzgLyrqRC3kSUtrnD4u0OxZSDF6kdAjujNUrPAgV1Ozs5W ZJpQ1y7i4UHhQ7tVx_KHTdWtxa_pcuWdo3aMP6DaFoJ9Ik1UpnwTDeTWfrIN0Z6ZotpNqzzmjMiZ 8WyLDplnSCRU4qDZXsXTBT1ZHtXc9ecGj_ydA9oQhhCiF2eKCX4ADBlq0XbN.to9B5M1FMl4ozt7 efiVgIcrfZR2AacqoHXvvhyUKRoF_asbv79GMA5JId98rA7YFsgDxezOe4xgkck8wqwfZuJE8dDi z_ssy4Hd6wxwDQVbKtPgqllH168kUTGsDlJkQD0M0fGbS7Ghgu19YSpi3Ir44cZojtZG7jkpIwvB Ef4tUwFrOqVqFk1jk28b6HFl7.z4xSDgzgsmnMXG8F_jnMsk6jz20tMK.PRRB3BAGYcIPIZfHQoy QvQ-- X-Sonic-MF: X-Sonic-ID: 6cf5d31f-7bdf-4b07-b115-8ba8d5781576 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Thu, 3 Aug 2023 07:19:43 +0000 Received: by hermes--production-bf1-7c4db57b6-967mb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID adefbbb46573ae81d66cd064ffa1577b; Thu, 03 Aug 2023 07:19:39 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: armv7 kyua runs via chroot on aarch64: zfs tests leave behind processes from timed out tests Message-Id: Date: Thu, 3 Aug 2023 00:19:27 -0700 To: Current FreeBSD , FreeBSD ARM List X-Mailer: Apple Mail (2.3731.700.6) References: X-Spamd-Result: default: False [-3.35 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; NEURAL_HAM_SHORT(-0.86)[-0.857]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.146:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.146:from] X-Rspamd-Queue-Id: 4RGgG94Hvjz3DPw X-Spamd-Bar: --- This is after the patch (leading whitespace might not have been preserved in what you see): # git -C /usr/main-src/ diff sys/dev/md/ diff --git a/sys/dev/md/md.c b/sys/dev/md/md.c index a719dccb1955..365296ec4276 100644 --- a/sys/dev/md/md.c +++ b/sys/dev/md/md.c @@ -147,8 +147,15 @@ struct md_ioctl32 { int md_fwsectors; uint32_t md_label; int md_pad[MDNPAD]; +#ifdef __aarch64__ + uint32_t md_pad0; +#endif } __attribute__((__packed__)); +#ifdef __aarch64__ +CTASSERT((sizeof(struct md_ioctl32)) =3D=3D 440); +#else CTASSERT((sizeof(struct md_ioctl32)) =3D=3D 436); +#endif =20 #define MDIOCATTACH_32 _IOC_NEWTYPE(MDIOCATTACH, struct = md_ioctl32) #define MDIOCDETACH_32 _IOC_NEWTYPE(MDIOCDETACH, struct = md_ioctl32) The kyua run is still in process, but at this point there is the following accumulation from the zfs testing timouts: # ps -alxdww UID PID PPID C PRI NI VSZ RSS MWCHAN STAT TT TIME = COMMAND . . . 0 17491 1 6 20 0 36460 12324 - T - 0:24.71 |-- = fsync_integrity /testdir2316/testfile2316 0 17551 1 5 20 0 10600 7512 tx->tx_s D - 0:00.00 |-- = /sbin/zpool destroy -f testpool.2316 0 17739 1 7 20 0 10600 7308 zfs tear D - 0:00.00 |-- = /sbin/zpool destroy -f testpool.2316 0 17841 1 3 20 0 10600 7316 tx->tx_s D - 0:00.00 |-- = /sbin/zpool destroy -f testpool.2316 0 17860 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 17888 1 3 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 17907 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 17928 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 17955 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 17976 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 17995 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18023 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18043 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18064 1 3 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18085 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18114 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18135 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18157 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18177 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18205 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18224 1 1 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18255 1 3 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18275 1 1 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18296 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18317 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18345 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18365 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18386 1 3 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18412 1 1 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18447 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18466 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18516 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18535 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18632 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade Lots of these are from 300s timeouts but some are from 1200s or 1800s or 3600s timeouts. For reference: = sys/cddl/zfs/tests/txg_integrity/txg_integrity_test:fsync_integrity_001_po= s -> broken: Test case body timed out [1800.053s] = sys/cddl/zfs/tests/txg_integrity/txg_integrity_test:txg_integrity_001_pos = -> passed [63.702s] sys/cddl/zfs/tests/userquota/userquota_test:groupspace_001_pos -> = skipped: Required program 'runwattr' not found in PATH [0.003s] sys/cddl/zfs/tests/userquota/userquota_test:groupspace_002_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] sys/cddl/zfs/tests/userquota/userquota_test:userquota_001_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] sys/cddl/zfs/tests/userquota/userquota_test:userquota_002_pos -> = broken: Test case cleanup timed out [0.148s] sys/cddl/zfs/tests/userquota/userquota_test:userquota_003_pos -> = broken: Test case cleanup timed out [0.151s] sys/cddl/zfs/tests/userquota/userquota_test:userquota_004_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] sys/cddl/zfs/tests/userquota/userquota_test:userquota_005_neg -> = broken: Test case body timed out [300.021s] sys/cddl/zfs/tests/userquota/userquota_test:userquota_006_pos -> = broken: Test case body timed out [300.080s] sys/cddl/zfs/tests/userquota/userquota_test:userquota_007_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] sys/cddl/zfs/tests/userquota/userquota_test:userquota_008_pos -> = broken: Test case body timed out [300.034s] sys/cddl/zfs/tests/userquota/userquota_test:userquota_009_pos -> = broken: Test case body timed out [300.143s] sys/cddl/zfs/tests/userquota/userquota_test:userquota_010_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] sys/cddl/zfs/tests/userquota/userquota_test:userquota_011_pos -> = broken: Test case body timed out [300.003s] sys/cddl/zfs/tests/userquota/userquota_test:userquota_012_neg -> = broken: Test case body timed out [300.019s] sys/cddl/zfs/tests/userquota/userquota_test:userspace_001_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] sys/cddl/zfs/tests/userquota/userquota_test:userspace_002_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_001_pos -> = broken: Test case body timed out [300.052s] sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_002_pos -> = skipped: Required program 'labelit' not found in PATH [0.002s] sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_003_pos -> = broken: Test case body timed out [300.076s] sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_004_pos -> = broken: Test case body timed out [300.106s] sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_005_pos -> = skipped: Required program 'ff' not found in PATH [0.002s] sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_006_pos -> = broken: Test case body timed out [300.015s] sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_007_pos -> = broken: Test case body timed out [300.005s] sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_008_pos -> = skipped: Required program 'ncheck' not found in PATH [0.002s] sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_009_pos -> = broken: Test case body timed out [300.051s] sys/cddl/zfs/tests/write_dirs/write_dirs_test:write_dirs_001_pos -> = broken: Test case body timed out [1200.056s] sys/cddl/zfs/tests/write_dirs/write_dirs_test:write_dirs_002_pos -> = broken: Test case body timed out [1200.046s] sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_autoreplace_001_neg -> broken: = Test case body timed out [3600.055s] Other timeouts not from zfs tests have not had an accumulation of processes left behind. But these may be the set of tests that use ksh93 for scripting. I make no claim of knowing the zfs vs. ksh93 vs. both vs. ??? for what is contributing. I'll note that the system was booted via a bectl BE environment on the only FreeBSD media enabled, so is a zfs-root boot context. For reference: # uname -apKU FreeBSD CA78C-WDK23-ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT aarch64 = 1400093 #6 main-n264334-215bab7924f6-dirty: Wed Aug 2 14:12:14 PDT 2023 = = root@CA78C-WDK23-ZFS:/usr/obj/BUILDs/main-CA78C-nodbg-clang/usr/main-src/a= rm64.aarch64/sys/GENERIC-NODBG-CA78C arm64 aarch64 1400093 1400093 I preload various modules (6 are commented out [not preloaded] and some listed may be actually built into the kernel): # grep kldload ~/prekyua-kldloads.sh=20 kldload -v -n zfs.ko kldload -v -n cryptodev.ko kldload -v -n nullfs.ko kldload -v -n fdescfs.ko kldload -v -n filemon.ko kldload -v -n nfsd.ko kldload -v -n tarfs.ko kldload -v -n xz.ko kldload -v -n geom_concat.ko kldload -v -n geom_eli.ko kldload -v -n geom_nop.ko kldload -v -n geom_gate.ko kldload -v -n geom_mirror.ko kldload -v -n geom_multipath.ko kldload -v -n sdt.ko kldload -v -n dtrace.ko kldload -v -n opensolaris.ko kldload -v -n geom_raid3.ko kldload -v -n geom_shsec.ko kldload -v -n geom_stripe.ko kldload -v -n geom_uzip.ko kldload -v -n if_epair.ko kldload -v -n if_gif.ko kldload -v -n if_tuntap.ko kldload -v -n if_lagg.ko kldload -v -n if_infiniband.ko kldload -v -n if_wg.ko kldload -v -n ng_socket.ko kldload -v -n netgraph.ko kldload -v -n ng_hub.ko kldload -v -n ng_bridge.ko kldload -v -n ng_ether.ko kldload -v -n ng_vlan_rotate.ko kldload -v -n ipdivert.ko kldload -v -n pf.ko kldload -v -n if_bridge.ko kldload -v -n bridgestp.ko kldload -v -n mqueuefs.ko kldload -v -n tcpmd5.ko kldload -v -n carp.ko kldload -v -n sctp.ko kldload -v -n if_stf.ko kldload -v -n if_ovpn.ko kldload -v -n ipsec.ko #kldload -v -n ipfw.ko #kldload -v -n pflog.ko #kldload -v -n pfsync.ko kldload -v -n dummynet.ko #kldload -v -n mac_bsdextended.ko #kldload -v -n mac_ipacl.ko #kldload -v -n mac_portacl.ko armv7 ports built and installed in the armv7 chroot area include: # more ~/origins/kyua-origins.txt archivers/gtar devel/gdb devel/py-pytest devel/py-pytest-twisted devel/py-twisted lang/perl5.32 lang/python net/scapy security/nist-kat security/openvpn security/sudo shells/ksh93 shells/bash sysutils/coreutils sysutils/sg3_utils textproc/jq (Those cause others to also be installed.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Aug 3 14:14:12 2023 X-Original-To: freebsd-current@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 4RGrSg4FBHz2tvnS for ; Thu, 3 Aug 2023 14:14:27 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) (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 4RGrSf62dSz4Hhf for ; Thu, 3 Aug 2023 14:14:26 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.208.169 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com; dmarc=none Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-2b9d07a8d84so15980581fa.3 for ; Thu, 03 Aug 2023 07:14:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691072064; x=1691676864; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=X+PcNUmZz6UxDL+FWGzI5gIcUDRsyc6SuLGvpFqzK9A=; b=KVEsrvbXoBBa2iTXg5BVfVvd3DZjNKaYJdWEfFn2I6qP337hTev8IPvILFIHmSkybt vX0cWbp3z0sj/WSJ89xQD+gJFRWcJ009JsWjEizNzDeeEcAnUdFhJO8PY5VgmVI9pjMR DjBg+3kdwAUc049DApYG9Yt7eO0lq4n+0LvCNDSY7Op3w9xVGCXSwi8Uu6XMedz4xfGA PADa9IrNb/Wg1Cxsoc4ftxoQEi20v0DVHrErrZQpyu2NxPlUbw/iWMbk/RwsgM3deq5T UIA6KvZOYbpBrOOQ1wngRX8pXQE1hXocBI8/6WJAQlkOmHtP3taoKp1q+08IRCszA4Bt VASw== X-Gm-Message-State: ABy/qLZMj1gzvYtVTOy2TzbOPySJ+bpSUG3jTyRApc3lebiyUr4HkkA8 Fv5VuFKqYmT9dunw6AVNh9WU9IoQygJVBDCkgZa1eH0RPLQZ/w== X-Google-Smtp-Source: APBJJlEn/9ZLU5wNLWp3BY46aucJRR3JN+gw5mx6Wk53LlzBpi/cPtQa6CqPl7zRI+sHyGXfNqvNPkxlyqB+eHnMCHI= X-Received: by 2002:a2e:9bc3:0:b0:2b6:fa60:85a1 with SMTP id w3-20020a2e9bc3000000b002b6fa6085a1mr7924961ljj.21.1691072063996; Thu, 03 Aug 2023 07:14:23 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Thu, 3 Aug 2023 10:14:12 -0400 Message-ID: Subject: Heads-up: MAXCPU increasing shortly To: FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [0.98 / 15.00]; NEURAL_SPAM_SHORT(0.98)[0.984]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.169:from]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.169:from]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[freebsd.org]; MIME_TRACE(0.00)[0:+]; TO_DOM_EQ_FROM_DOM(0.00)[] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4RGrSf62dSz4Hhf On Fri, 5 May 2023 at 09:38, Ed Maste wrote: > > FreeBSD supports up to 256 CPU cores in the default kernel configuration > (on Tier-1 architectures). Systems with more than 256 cores are > available now, and will become increasingly common over FreeBSD 14=E2=80= =99s > lifetime. The FreeBSD Foundation is supporting the effort to increase > MAXCPU, and PR269572[1] is open to track tasks and changes. I intend to commit the change to increase amd64 MAXCPU to 1024 very soon. After updating your src tree and building a new kernel you will need to rebuild kernel modules that come from outside of the src tree (such as drm-kmod or VirtualBox). [1] https://bugs.freebsd.org/269572 From nobody Thu Aug 3 14:18:21 2023 X-Original-To: freebsd-current@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 4RGrYX3w28z2tw39 for ; Thu, 3 Aug 2023 14:18:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-23.consmr.mail.gq1.yahoo.com (sonic311-23.consmr.mail.gq1.yahoo.com [98.137.65.204]) (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 4RGrYW4gTbz4Jtb for ; Thu, 3 Aug 2023 14:18:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=U6caNKAJ; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.204 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=1691072317; bh=LQMA/0VUjaHxrRO6/pNDLwaAQJ5cGIMkvApF9y3maDw=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=U6caNKAJ6Ld/iOTavaKg7EN177W3d00Evqmr/u+fw0wm7R03K4KwnDuTUMh14DTMiWY/RU6p5kPNneMCuDGLyxUG311NlvCaVmu+oDdzf5/Hy5qXhzVDmYRgzuSi84noYCgBIYah+hnf+CoZ6N/3IP10A82btsfSYo2+2rXmTefPB/q2Q3nMq9qH5v/QhGsBajc8N7FOoE/o92BAqzDKgulTO07Lhtda5GLdsdn1uRkUpNLVUlYp2YTtntSm2asDwYKro9Bs/cCdYlQURg7wmldaGBY1AIhejeuEcilI52VGS6wWzZZ2lVHDOoQtLsgmX3zMGUMKwbgitW/iCASctQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691072317; bh=Dem05u+d6KhVeRmDvoFUyzjSZKOTQH2l7bpwADEiV/K=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=lBdvKEarS6f8xYwg1T3VJ0dN2VcizVImB1XyJc6HkLc+TDEt5+ZJWYMUf7uPKAZFGYuV/dgjEu55fx0fWziIf+wf2/lSlukBBAf4VZdcfQMFhqSA4GgBSPf4hjYEv5xQhslkJZuzmp+k9rdkkRGkqE93yOxAVvOPbVLXN8S6vmFWTEYDtRRbrKv7tTGsoYORh11Ekoc5qpOb3kvrVNkkbAKhivqve+RrelHG2RKf9dgujQQx4dbQOrk72MtXYd1zGMRHGULQU+xziJ2mn/gxblTHpUWtKJQEdln2/5FFs9NyrCzbUMZCeYIINuIlwXzQIkW1GTh0bPoqSmXF6YnbWA== X-YMail-OSG: cnvm2kkVM1lVKbL8MtUzCIHc6RFlW9Eci6.AuSEzw1w2PqEA7JHrUEiMh0dTA5S BGhSKjS0NqyWpUkAh5kMTNMB7Ovn3g6gTFXkk.fHll3KHexTqhd1LjzsRf_GY90vLwv1jF.M3YA3 abXeBOfq3eFn5O28jvo60RtLupfEyWj5kLabEZJq66MVoCDDbDlm71nDavR7gnGIX2hoUWT5VDxQ bXuWfedVjsJWMeh5nkdG0J27BO25Gqnry2.b9u6gLJ8_lil_vCq6H1e438k1AJ77J6bp_JYWZ_G2 raatGrgLsU.7yPXZ4jv_GT9vUsi50VLxfvJWgwF_53HD50PSKBlEBAK9FrV9cc1YAKAyjmsfRy.J KAoFIrXl4lcmD6JGy8QCHCqGXmBdz4NPVm_hJPnRhlZnWyn3eNUghXPOzqy2sIy53uq.pvLLycm0 lAjMx0cUieQoHPiAjQBfha.3dkE2PU7qdh1eEYZu1u5So.aWOd6DsPIIna_hY9F2aU2IlhOVyBo7 DHrncqrsDL36s37x1qc2ottIHtZ5XnvFKDCbEuCYqP_a9bXrI6pwaLDTxfq9c8STCSA51AtWjZkl 479UD4DU8b4hh3WXQnS3lhwUphDsP9gWCnaXov4pymIR0QinGrup7omvSMAasgJG8z9FIYtgAZ6x 9qm5fVaQZRsucvCehEq7HcQj7PWWlVuVvF00sHryBQWLXNRkP4Kja4SdZA5ULAFEsQPQBoqpPChu 5O_gFmEEnR6H.Nsr7RyRxW5ohcKAEsL3hKVCBQJW9wTrUp62kISSnkn6s7VCEEITJuGMCgeXUrK0 GdvbikBEnqXo8W2mQIDLdh4_pvJTHcXYN2NvnhNh3UWy9r2YK9rbxJTdjnn11nKn9vcDSCJQnVrh guT5YGGxxqXus51BRhIKQMywbZUpA4Svqt1ynSUmrenqR5EVGuXOufax94rUDUXkYtMtbpfCNetR ptB80UXTvXXpS5AYCiUu.w7MDE0Z1OLXcSxshTZswd.BKZY0WNDQjFiGIw1ifjZITEvhW1K5pdhj vNIwRAFWU6zJOv10ONtnDIeoIr.QYjuKiZtAF6.qxvfW5K5y.Mpn2hFuiSQiqif41NEPf6klaO1t ynGuP44k1DeQFcPoj4VSF3NWua4QVQEO5DiW4P96FOJK7RpkXXSn2uD_VAWcuBrxmlYSjR6xb5PK RHfT9p2YOV68bP.tLYKrpF8FRNhnzKheyQlxj8MRr9NAkkbsJ9rBLfNMHhG6viZMbxKb_fIMW87E b9..pzML2yy7R_ezr1WCNmeYbk.sLR5zbNthVu45cH4TMtyPkeRg188s2V04T.OMwktXhkNXIQsA 3gthoAMkaEaEiBmkKOC4w3fYglQUTiszCA586qlgfkPswFlRa7IlYyhailCzE6cc6xngO9UX_euV 0eR2qsAqaPRXF35UKQTzx_ZYNyL7vvaQe9wW4_4ACsbpTs.rmV_fZsY39fq4q3FpBCp6x7i93MZq HZH4dw_xFxNEAjIcRJbbn.anyUEAABRTn6MHd_CSJUmJQAz1.mHjXGt_SPFHZ9e6kTSI3z1i17AQ gT814itiSHuflg2n1VyKi4fusYDj86uleqTRV5R7HY0u0dQTEOnZUhLEBDpnumhVlinhEROaT6gE Fm7sSJWo4GNV3nKxIyhidPjRpwiUiDUsl_KljMllJ7vAkpfAwPqBx8vgfhK_GsJo.I293AFtTHKZ N_oxr5MPBQKkAhBsLhMbKPKqr5AzPhZ_yp7ji99hG71ci929FrYbqqu5bAae9_kUSaqiPSrktBCe H6z.b2Jdt7gOGzBW6yGLxUCxzXkIGmMK3AhF6uNszldVFTXg6cjDEDPMRwaKadHo1yUFXenFCzZe zAxYcQLmrOjbRi9EYg611M7D4ezT5DjyXpdlbSDHLJ5DFmELLULIY9X_2jUTWUO_xTwydYbeZZ0U F5JPrTvqYwrqHfp_T4c6ULW3h.ocaatfzMk9UjhvkKWIMXDjBNpBf1T8inTKMPA.nhVExpmMmy45 MItAMrwabbfKBqM0nc0OV9Vh5b31fhxRs_O_cc2h8BserdBrJXDIKJk1Q9UrqhowwyMC8SUx3T78 Xzlc3ITWaZ.tP2y2bERU1L9HuW66Wi9PoMRapGb0Vnr0wiGdGZk1QocxiYiFgih1jQ_7NGTRG69h S7dfrqg5v4ZvHKU7Jkzxh.QYc5YU1ktvthAqjEJ71LFqdSA6nmIe9h7ySdweVGiTN8axWjA7W9iM Ei2g5Umg9u8TSm4Cc.a_iwmOLs9s6mrbgbjlN3o2CyX.XeD341Oshur3cwN16gX55e.otvBV3qCk - X-Sonic-MF: X-Sonic-ID: 3502ef56-ae44-4a38-b758-0af6b4bb7628 Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Thu, 3 Aug 2023 14:18:37 +0000 Received: by hermes--production-bf1-7c4db57b6-wcllk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c741c30067c5725bf5ac161b25852559; Thu, 03 Aug 2023 14:18:34 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: armv7 kyua runs via chroot on aarch64: zfs tests leave behind processes from timed out tests Date: Thu, 3 Aug 2023 07:18:21 -0700 References: To: Current FreeBSD , FreeBSD ARM List In-Reply-To: Message-Id: <1BDD2369-BCC3-469B-8094-AEFE7FC3CE94@yahoo.com> X-Mailer: Apple Mail (2.3731.700.6) X-Spamd-Result: default: False [-1.47 / 15.00]; NEURAL_HAM_SHORT(-0.97)[-0.974]; 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]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.204:from]; DKIM_TRACE(0.00)[yahoo.com:+]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.204:from]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Spamd-Bar: - X-Rspamd-Queue-Id: 4RGrYW4gTbz4Jtb On Aug 3, 2023, at 00:19, Mark Millard wrote: > This is after the patch (leading whitespace might > not have been preserved in what you see): >=20 > # git -C /usr/main-src/ diff sys/dev/md/ > diff --git a/sys/dev/md/md.c b/sys/dev/md/md.c > index a719dccb1955..365296ec4276 100644 > --- a/sys/dev/md/md.c > +++ b/sys/dev/md/md.c > @@ -147,8 +147,15 @@ struct md_ioctl32 { > int md_fwsectors; > uint32_t md_label; > int md_pad[MDNPAD]; > +#ifdef __aarch64__ > + uint32_t md_pad0; > +#endif > } __attribute__((__packed__)); > +#ifdef __aarch64__ > +CTASSERT((sizeof(struct md_ioctl32)) =3D=3D 440); > +#else > CTASSERT((sizeof(struct md_ioctl32)) =3D=3D 436); > +#endif >=20 > #define MDIOCATTACH_32 _IOC_NEWTYPE(MDIOCATTACH, struct = md_ioctl32) > #define MDIOCDETACH_32 _IOC_NEWTYPE(MDIOCDETACH, struct = md_ioctl32) >=20 >=20 > The kyua run is still in process, but at this point there is > the following accumulation from the zfs testing timouts: >=20 > # ps -alxdww > UID PID PPID C PRI NI VSZ RSS MWCHAN STAT TT TIME = COMMAND > . . . > 0 17491 1 6 20 0 36460 12324 - T - 0:24.71 |-- = fsync_integrity /testdir2316/testfile2316 > 0 17551 1 5 20 0 10600 7512 tx->tx_s D - 0:00.00 |-- = /sbin/zpool destroy -f testpool.2316 > 0 17739 1 7 20 0 10600 7308 zfs tear D - 0:00.00 |-- = /sbin/zpool destroy -f testpool.2316 > 0 17841 1 3 20 0 10600 7316 tx->tx_s D - 0:00.00 |-- = /sbin/zpool destroy -f testpool.2316 > 0 17860 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 17888 1 3 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 17907 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 17928 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 17955 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 17976 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 17995 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18023 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18043 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18064 1 3 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18085 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18114 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18135 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18157 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18177 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18205 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18224 1 1 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18255 1 3 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18275 1 1 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18296 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18317 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18345 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18365 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18386 1 3 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18412 1 1 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18447 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18466 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18516 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18535 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18632 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade It has added: 0 18656 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18748 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18767 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18858 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18877 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18907 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18926 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18956 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 18975 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 19005 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 19026 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 19298 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 19317 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 19408 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 19427 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 19518 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 19537 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 19635 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > Lots of these are from 300s timeouts but some are from 1200s or > 1800s or 3600s timeouts. >=20 > For reference: >=20 > = sys/cddl/zfs/tests/txg_integrity/txg_integrity_test:fsync_integrity_001_po= s -> broken: Test case body timed out [1800.053s] > = sys/cddl/zfs/tests/txg_integrity/txg_integrity_test:txg_integrity_001_pos = -> passed [63.702s] > sys/cddl/zfs/tests/userquota/userquota_test:groupspace_001_pos -> = skipped: Required program 'runwattr' not found in PATH [0.003s] > sys/cddl/zfs/tests/userquota/userquota_test:groupspace_002_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_001_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_002_pos -> = broken: Test case cleanup timed out [0.148s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_003_pos -> = broken: Test case cleanup timed out [0.151s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_004_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_005_neg -> = broken: Test case body timed out [300.021s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_006_pos -> = broken: Test case body timed out [300.080s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_007_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_008_pos -> = broken: Test case body timed out [300.034s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_009_pos -> = broken: Test case body timed out [300.143s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_010_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_011_pos -> = broken: Test case body timed out [300.003s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_012_neg -> = broken: Test case body timed out [300.019s] > sys/cddl/zfs/tests/userquota/userquota_test:userspace_001_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] > sys/cddl/zfs/tests/userquota/userquota_test:userspace_002_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] > sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_001_pos -> = broken: Test case body timed out [300.052s] > sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_002_pos -> = skipped: Required program 'labelit' not found in PATH [0.002s] > sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_003_pos -> = broken: Test case body timed out [300.076s] > sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_004_pos -> = broken: Test case body timed out [300.106s] > sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_005_pos -> = skipped: Required program 'ff' not found in PATH [0.002s] > sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_006_pos -> = broken: Test case body timed out [300.015s] > sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_007_pos -> = broken: Test case body timed out [300.005s] > sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_008_pos -> = skipped: Required program 'ncheck' not found in PATH [0.002s] > sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_009_pos -> = broken: Test case body timed out [300.051s] > sys/cddl/zfs/tests/write_dirs/write_dirs_test:write_dirs_001_pos -> = broken: Test case body timed out [1200.056s] > sys/cddl/zfs/tests/write_dirs/write_dirs_test:write_dirs_002_pos -> = broken: Test case body timed out [1200.046s] > sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_autoreplace_001_neg -> = broken: Test case body timed out [3600.055s] And added: sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_autoreplace_002_pos -> broken: = Test case body timed out [3600.028s] sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_autoreplace_003_pos -> broken: = Test case body timed out [3600.146s] sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_degrade_001_pos -> broken: Test = case body timed out [600.067s] sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_degrade_002_pos -> broken: Test = case body timed out [600.015s] sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_fault_001_pos -> broken: Test = case body timed out [300.061s] sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_hotspare_001_pos -> broken: = Test case body timed out [3600.042s] sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_hotspare_002_pos -> broken: = Test case body timed out [3600.161s] sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_hotspare_003_pos -> broken: = Test case body timed out [3600.033s] sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_hotspare_004_pos -> broken: = Test case body timed out [3600.007s] > Other timeouts not from zfs tests have not had an accumulation > of processes left behind. But these may be the set of tests > that use ksh93 for scripting. I make no claim of knowing the > zfs vs. ksh93 vs. both vs. ??? for what is contributing. >=20 >=20 > I'll note that the system was booted via a bectl BE environment > on the only FreeBSD media enabled, so is a zfs-root boot context. >=20 > For reference: >=20 > # uname -apKU > FreeBSD CA78C-WDK23-ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT aarch64 = 1400093 #6 main-n264334-215bab7924f6-dirty: Wed Aug 2 14:12:14 PDT 2023 = = root@CA78C-WDK23-ZFS:/usr/obj/BUILDs/main-CA78C-nodbg-clang/usr/main-src/a= rm64.aarch64/sys/GENERIC-NODBG-CA78C arm64 aarch64 1400093 1400093 >=20 > I preload various modules (6 are commented out [not preloaded] > and some listed may be actually built into the kernel): >=20 > # grep kldload ~/prekyua-kldloads.sh=20 > kldload -v -n zfs.ko > kldload -v -n cryptodev.ko > kldload -v -n nullfs.ko > kldload -v -n fdescfs.ko > kldload -v -n filemon.ko > kldload -v -n nfsd.ko > kldload -v -n tarfs.ko > kldload -v -n xz.ko > kldload -v -n geom_concat.ko > kldload -v -n geom_eli.ko > kldload -v -n geom_nop.ko > kldload -v -n geom_gate.ko > kldload -v -n geom_mirror.ko > kldload -v -n geom_multipath.ko > kldload -v -n sdt.ko > kldload -v -n dtrace.ko > kldload -v -n opensolaris.ko > kldload -v -n geom_raid3.ko > kldload -v -n geom_shsec.ko > kldload -v -n geom_stripe.ko > kldload -v -n geom_uzip.ko > kldload -v -n if_epair.ko > kldload -v -n if_gif.ko > kldload -v -n if_tuntap.ko > kldload -v -n if_lagg.ko > kldload -v -n if_infiniband.ko > kldload -v -n if_wg.ko > kldload -v -n ng_socket.ko > kldload -v -n netgraph.ko > kldload -v -n ng_hub.ko > kldload -v -n ng_bridge.ko > kldload -v -n ng_ether.ko > kldload -v -n ng_vlan_rotate.ko > kldload -v -n ipdivert.ko > kldload -v -n pf.ko > kldload -v -n if_bridge.ko > kldload -v -n bridgestp.ko > kldload -v -n mqueuefs.ko > kldload -v -n tcpmd5.ko > kldload -v -n carp.ko > kldload -v -n sctp.ko > kldload -v -n if_stf.ko > kldload -v -n if_ovpn.ko > kldload -v -n ipsec.ko > #kldload -v -n ipfw.ko > #kldload -v -n pflog.ko > #kldload -v -n pfsync.ko > kldload -v -n dummynet.ko > #kldload -v -n mac_bsdextended.ko > #kldload -v -n mac_ipacl.ko > #kldload -v -n mac_portacl.ko >=20 > armv7 ports built and installed in the armv7 chroot > area include: >=20 > # more ~/origins/kyua-origins.txt > archivers/gtar > devel/gdb > devel/py-pytest > devel/py-pytest-twisted > devel/py-twisted > lang/perl5.32 > lang/python > net/scapy > security/nist-kat > security/openvpn > security/sudo > shells/ksh93 > shells/bash > sysutils/coreutils > sysutils/sg3_utils > textproc/jq >=20 > (Those cause others to also be installed.) I tried gdb -p PID against a couple of the processes. Each got stuck, not reaching the gdb prompt. I also show a Control-T output: Attaching to process 17491 load: 0.24 cmd: gdb131 19693 [uwait] 32.27r 0.02u 0.06s 0% 32152k #0 0xffff00000049fe20 at mi_switch+0xe0 #1 0xffff0000004f3658 at sleepq_catch_signals+0x318 #2 0xffff0000004f3318 at sleepq_wait_sig+0x8 #3 0xffff00000049f410 at _sleep+0x1d0 #4 0xffff0000004b52dc at umtxq_sleep+0x27c #5 0xffff0000004bab7c at do_wait+0x25c #6 0xffff0000004b8cdc at __umtx_op_wait_uint_private+0x5c #7 0xffff0000004b6e64 at sys__umtx_op+0x84 #8 0xffff0000008267d4 at do_el0_sync+0x9b4 #9 0xffff000000805910 at handle_el0_sync+0x44 and: Attaching to process 17860 load: 0.23 cmd: gdb131 19697 [uwait] 13.14r 0.06u 0.01s 0% 32184k #0 0xffff00000049fe20 at mi_switch+0xe0 #1 0xffff0000004f3658 at sleepq_catch_signals+0x318 #2 0xffff0000004f3318 at sleepq_wait_sig+0x8 #3 0xffff00000049f410 at _sleep+0x1d0 #4 0xffff0000004b52dc at umtxq_sleep+0x27c #5 0xffff0000004bab7c at do_wait+0x25c #6 0xffff0000004b8cdc at __umtx_op_wait_uint_private+0x5c #7 0xffff0000004b6e64 at sys__umtx_op+0x84 #8 0xffff0000008267d4 at do_el0_sync+0x9b4 #9 0xffff000000805910 at handle_el0_sync+0x44 I was unable to Control-C the gdb's to gain control but was able to put them in the background (Control-Z then bg). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Aug 3 17:20:00 2023 X-Original-To: freebsd-current@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 4RGwb84jh7z3cV7r for ; Thu, 3 Aug 2023 17:20:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83]) (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 4RGwb70NgPz4h4g for ; Thu, 3 Aug 2023 17:20:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=QvHNQxVf; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.83 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=1691083216; bh=9r7MZi9NiZSTqivreD+4r4oWBObVcTrRsez+mYfoQR0=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=QvHNQxVfZixsxXhpT4zWH8d8xiP855Ny724Y9z5Xezz3nf/iphi3Rsp3Yh7+40xB7gmdk53thC3cm9L1g8YFZc/TQA4kNT2S6LfNXQNRozHRxDPqUSrxSItVJbBkYZDZq+S0cVUtPYmSZgRWEDF7ZDwvaCHxRr1FmMxuBe4o+g/mI0PykIprkhsVWzuQUgEbqK7+utLZyX0DFV5KW4D9gCWUy1ry0JTaODtl490EQcM4Xb41m8cjnw1b5NGtpJyROtMhnJWlKpK9X7guuNGrZtHAmoTuBamh+qxjN2r1gQLzBkEeCvubEaN8zvwVgAtC6awj11dWLEKS3T1a24BZiw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691083216; bh=XyhyGgf31KAod0EuQDCaCxOOtRahxGp3g8HH1SDylBU=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=nDO3xD0S9SNW7kqC8ZuM1IAMTRbpej9VmUkP/zpOKzYk4Kn9xk1ff7BGzISTahSNpVKqJ9mDAafEjmCJANTba6fMmQ5B9GDk/p8uvm+3ZzQb8TrPCxfSn7WJBMalENLaQJAO219gVTr/uKg4n2q92Gly1rmdcEtYyz3sxfz+Xrk9Dr7M4KS8uc/D6GT7aH6DE3j19XunyQ5V/Fnd6qfIkyDHtqB/UwQFeVP1Ro6KhMnrjvigNGnWzxJ8B2EvFZNwxh8+2Z9VxydnbFHc1D/fLgRrysq0mCwzSQsw4GOqiMqjriZ1uZKoFCn8Af9sFDfnm1BoitPzfiFVEJedCkGXAA== X-YMail-OSG: lS0yDAgVM1mZYPxpv4VACQsv4PUGRdicQnREylkwK3C6gZcc7el4G6k7nHcsyi6 YDRX3CJvpJ9.od_GDV1LgoDopijOgkb_VltxkZ08f_zJ93x.EOXMBRXcu_P6Sv0gONCKJ71GGd7g AXmCqRggpPT7gk9em3BxHEbou1CQj9r9Ki1dN1n0X2.PCiMdiuwWLmMjfPA1MC5Pa2am02pqNyop Q5H5hKe9GzoJJMA9FxgakjwjdEMLiJMZXD_BxN9PSrXSs.0I4qf9xTBJv8IjwoM5ZP32zynvP.Ew zwAb.qNqhYMWenQ.tMCTs9_AXRWndqO9ZXW3WES8RIFoLX6_1xfEM2U4q7q0sFW10jHbHMDMMpCi vnIwCIc83TPwu7gIk.u8RIlqHlaJF5CCYZfGdVlO_bG_GVD3jwEFcy3S0EGz0RKFfi.HVscNsoL_ hpH6cM12uw_3yv4Wr5J_.e58IbBJAtlo3Oc7CHNmEPHGpev9gQv2pwrW.5QlX3avKupRTbKRtuqq Jj_3vVljr3BS1UoiH0SPyguWGmJrqZN94rNodkM7tFiKoboPVARDdRj80PCHgVy3htHfld2aZXGc ju11.P64Krul_LFQm3133qOAU2.QR6U3DBAZoXxWLjD_TRLoYFVYmQFMxQpyeFAMzxbDL.yptUf8 okJ4nM.DZ13.oGFq4TxP4v137D_TJ_m21TsBBWfc1MAioIMWgFrMHTMsUfc6OtXAC1XKk78HlH15 P2TCQffAirK4YyWe7oK3N9B.8SY6avWF5humHnMo.FHJFTojHbfcWzkBX104SAv9.eJ5W9W4Akzc CERyeXUx6JvqCkTY_QpJaghqygVXboPT0XcbbTX_nB46I4QiDn62krvDxYboonF9KtEduLdM1BIp fkDoPLAgC5LJFjXNiNz7TQr_7Ny8B_xVI2l7w8YrL8QnKKc_hMZAoU6DtI3p5_iqdC3QujfQYXoH jwUTYhsOegl19WYxTkukk.QMWq2DSlWKMObDMXTbjQOwCagptjUibq8_C3mL.FumsAVDRgUXn96O Z27Eh2mKZxRdpqg5nAQrJoHcF0QZsL2Fww9s0s7toQBcy50SrbioKQDjP6kUVhLgMk1IIU7rZdba iUYdg3yqRyOyULcePBqDCCqzZDNMUHXnu8RZFEHsD04ywe7XUx0jPeqUdhWbg03jDnk4KT0GXsv8 _fn9rOsWaUQNTdzHoKvElL4_WjQmrwC4EUyxE2rEr3IPVBHX2QFdYkg9nzJK0SMDdgr1AW093y1e rgqsBb28_M_J438JUXJfIjs0xZd426glBNOyKKeQg2MjMEw.GInF9H2pD4Ozkcv39iL.xNpPcr8c 7aRcQZw.fj5PCiipavOcHAioAld20y7FWGaA0PlzsOyk7tUWNFfRDprceAMummpvAILCnEg9H_Sm ZL4sdArhsAbdDaZUdra4QlQTy0cJmkdw70MD3sEBwhRgbW0SwTv40CfMmyol68SiRZDxJ1UrzOGg nXghS6VHklwgOsd.nj6i4p9UlE235uIUH_iArmXmvFqL3a80yMGJE8PgxKz81iXjDpuNvgXZNtA7 .9A4OcQTCwzyZSrYCPoRto5DJ3EcNQqoIsMK7ywJh93eSE3UWT6s9DHlQrIWm2nZwaaJ3IZv4FwX PFOwK2LU.7GKPaTC6JUfEnr556AnFpxjN.tXiCaBfO4t6OczrZDZnd7ptTAjGAtlbrbiSnbNMKCV bzO68IEGBvkLPSHet.uI1.bRjHcNEVAiZWinvj0Pe7Tp0SMUT5wHZpC5ODhWXQ3UtPFGrtbyeGYY tjNGNzwYn9d5QKYesbWUOCALnZapJRKUIKqzXiOc8M5uu.0s_CsvyxtOuy3e03REOqj9dMYc7KOU Pxw0HDMDhJkppD9pR61MWp8.K7dlAFPStgywoh1KF9zgbm4CEe99cRmZq85P66tg1IYTVJMLeIs4 BG.TFmcM.4exATAxfsZ6f6c_Sj1.9Rv7d8dfz0_HcJjQjq1lFZmoqXwP728KuGOhurJo0vNwjRjM 0hURTR7dpYuaY.GTOQ0fCkDy8f0EhGsDikJ4BTFQVWdhu3AbRcy733qxhQ_Y5YLwphp_Wz7B9xzR EWOHvynny9HGe0JZNmwalZAO6DT5iXuZ47DrV0mzVbXoaRhzu6qhbpJMd3xwlGVYM_JL.kdQ26t5 QeNwB7PCsoKDY86fan3HUKbibvYlsimXd7F34pV3jwNxST_QanZrmdT5DijksjzP2zCHkI7IhcBL YX6koOVK2EBlHQMk539ic8_FkmpJnxU7cmr8KlVGb5C8RkJmSGUjruoj_5MKHKi19ABJIZuoIPJn n X-Sonic-MF: X-Sonic-ID: d43a6903-45e6-4b86-a4ef-7db197127462 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Thu, 3 Aug 2023 17:20:16 +0000 Received: by hermes--production-gq1-7d844d8954-p9m8l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bd9e305d0a7a4100838daa4fb532a726; Thu, 03 Aug 2023 17:20:11 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: armv7 kyua runs via chroot on aarch64: zfs tests leave behind processes from timed out tests Date: Thu, 3 Aug 2023 10:20:00 -0700 References: <1BDD2369-BCC3-469B-8094-AEFE7FC3CE94@yahoo.com> To: Current FreeBSD , FreeBSD ARM List In-Reply-To: <1BDD2369-BCC3-469B-8094-AEFE7FC3CE94@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3731.700.6) X-Spamd-Result: default: False [-1.50 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.83:from]; DKIM_TRACE(0.00)[yahoo.com:+]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_ALL(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.83:from] X-Spamd-Bar: - X-Rspamd-Queue-Id: 4RGwb70NgPz4h4g On Aug 3, 2023, at 07:18, Mark Millard wrote: > On Aug 3, 2023, at 00:19, Mark Millard wrote: >=20 >> This is after the patch (leading whitespace might >> not have been preserved in what you see): >>=20 >> # git -C /usr/main-src/ diff sys/dev/md/ >> diff --git a/sys/dev/md/md.c b/sys/dev/md/md.c >> index a719dccb1955..365296ec4276 100644 >> --- a/sys/dev/md/md.c >> +++ b/sys/dev/md/md.c >> @@ -147,8 +147,15 @@ struct md_ioctl32 { >> int md_fwsectors; >> uint32_t md_label; >> int md_pad[MDNPAD]; >> +#ifdef __aarch64__ >> + uint32_t md_pad0; >> +#endif >> } __attribute__((__packed__)); >> +#ifdef __aarch64__ >> +CTASSERT((sizeof(struct md_ioctl32)) =3D=3D 440); >> +#else >> CTASSERT((sizeof(struct md_ioctl32)) =3D=3D 436); >> +#endif >>=20 >> #define MDIOCATTACH_32 _IOC_NEWTYPE(MDIOCATTACH, struct = md_ioctl32) >> #define MDIOCDETACH_32 _IOC_NEWTYPE(MDIOCDETACH, struct = md_ioctl32) >>=20 >>=20 >> The kyua run is still in process, but at this point there is >> the following accumulation from the zfs testing timouts: >>=20 >> # ps -alxdww >> UID PID PPID C PRI NI VSZ RSS MWCHAN STAT TT TIME = COMMAND >> . . . >> 0 17491 1 6 20 0 36460 12324 - T - 0:24.71 |-- = fsync_integrity /testdir2316/testfile2316 >> 0 17551 1 5 20 0 10600 7512 tx->tx_s D - 0:00.00 |-- = /sbin/zpool destroy -f testpool.2316 >> 0 17739 1 7 20 0 10600 7308 zfs tear D - 0:00.00 |-- = /sbin/zpool destroy -f testpool.2316 >> 0 17841 1 3 20 0 10600 7316 tx->tx_s D - 0:00.00 |-- = /sbin/zpool destroy -f testpool.2316 >> 0 17860 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 17888 1 3 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 17907 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 17928 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 17955 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 17976 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 17995 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18023 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18043 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18064 1 3 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18085 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18114 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18135 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18157 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18177 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18205 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18224 1 1 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18255 1 3 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18275 1 1 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18296 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18317 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18345 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18365 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18386 1 3 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18412 1 1 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18447 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18466 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18516 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18535 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18632 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >=20 > It has added: >=20 > 0 18656 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18748 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18767 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18858 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18877 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18907 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18926 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18956 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18975 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 19005 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 19026 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 19298 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 19317 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 19408 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 19427 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 19518 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 19537 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 19635 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 19654 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 19746 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 19767 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 19854 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 19873 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade 0 19960 1 1 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> Lots of these are from 300s timeouts but some are from 1200s or >> 1800s or 3600s timeouts. >>=20 >> For reference: >>=20 >> = sys/cddl/zfs/tests/txg_integrity/txg_integrity_test:fsync_integrity_001_po= s -> broken: Test case body timed out [1800.053s] >> = sys/cddl/zfs/tests/txg_integrity/txg_integrity_test:txg_integrity_001_pos = -> passed [63.702s] >> sys/cddl/zfs/tests/userquota/userquota_test:groupspace_001_pos -> = skipped: Required program 'runwattr' not found in PATH [0.003s] >> sys/cddl/zfs/tests/userquota/userquota_test:groupspace_002_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] >> sys/cddl/zfs/tests/userquota/userquota_test:userquota_001_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] >> sys/cddl/zfs/tests/userquota/userquota_test:userquota_002_pos -> = broken: Test case cleanup timed out [0.148s] >> sys/cddl/zfs/tests/userquota/userquota_test:userquota_003_pos -> = broken: Test case cleanup timed out [0.151s] >> sys/cddl/zfs/tests/userquota/userquota_test:userquota_004_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] >> sys/cddl/zfs/tests/userquota/userquota_test:userquota_005_neg -> = broken: Test case body timed out [300.021s] >> sys/cddl/zfs/tests/userquota/userquota_test:userquota_006_pos -> = broken: Test case body timed out [300.080s] >> sys/cddl/zfs/tests/userquota/userquota_test:userquota_007_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] >> sys/cddl/zfs/tests/userquota/userquota_test:userquota_008_pos -> = broken: Test case body timed out [300.034s] >> sys/cddl/zfs/tests/userquota/userquota_test:userquota_009_pos -> = broken: Test case body timed out [300.143s] >> sys/cddl/zfs/tests/userquota/userquota_test:userquota_010_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] >> sys/cddl/zfs/tests/userquota/userquota_test:userquota_011_pos -> = broken: Test case body timed out [300.003s] >> sys/cddl/zfs/tests/userquota/userquota_test:userquota_012_neg -> = broken: Test case body timed out [300.019s] >> sys/cddl/zfs/tests/userquota/userquota_test:userspace_001_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] >> sys/cddl/zfs/tests/userquota/userquota_test:userspace_002_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] >> sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_001_pos -> = broken: Test case body timed out [300.052s] >> sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_002_pos -> = skipped: Required program 'labelit' not found in PATH [0.002s] >> sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_003_pos -> = broken: Test case body timed out [300.076s] >> sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_004_pos -> = broken: Test case body timed out [300.106s] >> sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_005_pos -> = skipped: Required program 'ff' not found in PATH [0.002s] >> sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_006_pos -> = broken: Test case body timed out [300.015s] >> sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_007_pos -> = broken: Test case body timed out [300.005s] >> sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_008_pos -> = skipped: Required program 'ncheck' not found in PATH [0.002s] >> sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_009_pos -> = broken: Test case body timed out [300.051s] >> sys/cddl/zfs/tests/write_dirs/write_dirs_test:write_dirs_001_pos -> = broken: Test case body timed out [1200.056s] >> sys/cddl/zfs/tests/write_dirs/write_dirs_test:write_dirs_002_pos -> = broken: Test case body timed out [1200.046s] >> sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_autoreplace_001_neg -> = broken: Test case body timed out [3600.055s] >=20 > And added: >=20 > sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_autoreplace_002_pos -> = broken: Test case body timed out [3600.028s] > sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_autoreplace_003_pos -> = broken: Test case body timed out [3600.146s] > sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_degrade_001_pos -> broken: = Test case body timed out [600.067s] > sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_degrade_002_pos -> broken: = Test case body timed out [600.015s] > sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_fault_001_pos -> broken: Test = case body timed out [300.061s] > sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_hotspare_001_pos -> broken: = Test case body timed out [3600.042s] > sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_hotspare_002_pos -> broken: = Test case body timed out [3600.161s] > sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_hotspare_003_pos -> broken: = Test case body timed out [3600.033s] > sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_hotspare_004_pos -> broken: = Test case body timed out [3600.007s] sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_hotspare_005_pos -> broken: = Test case body timed out [3600.065s] sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_hotspare_006_pos -> broken: = Test case body timed out [3600.014s] sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_hotspare_007_pos -> broken: = Test case body timed out [3600.066s] >> Other timeouts not from zfs tests have not had an accumulation >> of processes left behind. But these may be the set of tests >> that use ksh93 for scripting. I make no claim of knowing the >> zfs vs. ksh93 vs. both vs. ??? for what is contributing. >>=20 >>=20 >> I'll note that the system was booted via a bectl BE environment >> on the only FreeBSD media enabled, so is a zfs-root boot context. >>=20 >> For reference: >>=20 >> # uname -apKU >> FreeBSD CA78C-WDK23-ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT aarch64 = 1400093 #6 main-n264334-215bab7924f6-dirty: Wed Aug 2 14:12:14 PDT 2023 = = root@CA78C-WDK23-ZFS:/usr/obj/BUILDs/main-CA78C-nodbg-clang/usr/main-src/a= rm64.aarch64/sys/GENERIC-NODBG-CA78C arm64 aarch64 1400093 1400093 >>=20 >> I preload various modules (6 are commented out [not preloaded] >> and some listed may be actually built into the kernel): >>=20 >> # grep kldload ~/prekyua-kldloads.sh=20 >> kldload -v -n zfs.ko >> kldload -v -n cryptodev.ko >> kldload -v -n nullfs.ko >> kldload -v -n fdescfs.ko >> kldload -v -n filemon.ko >> kldload -v -n nfsd.ko >> kldload -v -n tarfs.ko >> kldload -v -n xz.ko >> kldload -v -n geom_concat.ko >> kldload -v -n geom_eli.ko >> kldload -v -n geom_nop.ko >> kldload -v -n geom_gate.ko >> kldload -v -n geom_mirror.ko >> kldload -v -n geom_multipath.ko >> kldload -v -n sdt.ko >> kldload -v -n dtrace.ko >> kldload -v -n opensolaris.ko >> kldload -v -n geom_raid3.ko >> kldload -v -n geom_shsec.ko >> kldload -v -n geom_stripe.ko >> kldload -v -n geom_uzip.ko >> kldload -v -n if_epair.ko >> kldload -v -n if_gif.ko >> kldload -v -n if_tuntap.ko >> kldload -v -n if_lagg.ko >> kldload -v -n if_infiniband.ko >> kldload -v -n if_wg.ko >> kldload -v -n ng_socket.ko >> kldload -v -n netgraph.ko >> kldload -v -n ng_hub.ko >> kldload -v -n ng_bridge.ko >> kldload -v -n ng_ether.ko >> kldload -v -n ng_vlan_rotate.ko >> kldload -v -n ipdivert.ko >> kldload -v -n pf.ko >> kldload -v -n if_bridge.ko >> kldload -v -n bridgestp.ko >> kldload -v -n mqueuefs.ko >> kldload -v -n tcpmd5.ko >> kldload -v -n carp.ko >> kldload -v -n sctp.ko >> kldload -v -n if_stf.ko >> kldload -v -n if_ovpn.ko >> kldload -v -n ipsec.ko >> #kldload -v -n ipfw.ko >> #kldload -v -n pflog.ko >> #kldload -v -n pfsync.ko >> kldload -v -n dummynet.ko >> #kldload -v -n mac_bsdextended.ko >> #kldload -v -n mac_ipacl.ko >> #kldload -v -n mac_portacl.ko >>=20 >> armv7 ports built and installed in the armv7 chroot >> area include: >>=20 >> # more ~/origins/kyua-origins.txt >> archivers/gtar >> devel/gdb >> devel/py-pytest >> devel/py-pytest-twisted >> devel/py-twisted >> lang/perl5.32 >> lang/python >> net/scapy >> security/nist-kat >> security/openvpn >> security/sudo >> shells/ksh93 >> shells/bash >> sysutils/coreutils >> sysutils/sg3_utils >> textproc/jq >>=20 >> (Those cause others to also be installed.) >=20 > I tried gdb -p PID against a couple of the processes. > Each got stuck, not reaching the gdb prompt. I also > show a Control-T output: >=20 > Attaching to process 17491 > load: 0.24 cmd: gdb131 19693 [uwait] 32.27r 0.02u 0.06s 0% 32152k > #0 0xffff00000049fe20 at mi_switch+0xe0 > #1 0xffff0000004f3658 at sleepq_catch_signals+0x318 > #2 0xffff0000004f3318 at sleepq_wait_sig+0x8 > #3 0xffff00000049f410 at _sleep+0x1d0 > #4 0xffff0000004b52dc at umtxq_sleep+0x27c > #5 0xffff0000004bab7c at do_wait+0x25c > #6 0xffff0000004b8cdc at __umtx_op_wait_uint_private+0x5c > #7 0xffff0000004b6e64 at sys__umtx_op+0x84 > #8 0xffff0000008267d4 at do_el0_sync+0x9b4 > #9 0xffff000000805910 at handle_el0_sync+0x44 >=20 > and: >=20 > Attaching to process 17860 > load: 0.23 cmd: gdb131 19697 [uwait] 13.14r 0.06u 0.01s 0% 32184k > #0 0xffff00000049fe20 at mi_switch+0xe0 > #1 0xffff0000004f3658 at sleepq_catch_signals+0x318 > #2 0xffff0000004f3318 at sleepq_wait_sig+0x8 > #3 0xffff00000049f410 at _sleep+0x1d0 > #4 0xffff0000004b52dc at umtxq_sleep+0x27c > #5 0xffff0000004bab7c at do_wait+0x25c > #6 0xffff0000004b8cdc at __umtx_op_wait_uint_private+0x5c > #7 0xffff0000004b6e64 at sys__umtx_op+0x84 > #8 0xffff0000008267d4 at do_el0_sync+0x9b4 > #9 0xffff000000805910 at handle_el0_sync+0x44 >=20 > I was unable to Control-C the gdb's to gain control > but was able to put them in the background (Control-Z > then bg). Looks like I'm going to have to reboot instead of letting the kyua run go to completion. The periodic daily is stuck as well. 0 19064 1657 1 20 0 12980 2484 piperd I - 0:00.00 | `-- = cron: running job (cron) 0 19066 19064 3 40 0 13436 2928 wait Is - 0:00.00 | = `-- /bin/sh - /usr/sbin/periodic daily . . . 0 19237 19235 0 68 0 13436 2936 wait I - 0:00.00 | = | | `-- /bin/sh - /etc/periodic/security/100.chksetuid 0 19242 19237 6 68 0 21912 10292 zfs D - 0:10.21 | = | | |-- / /var/mail . . . /dev/null (find) 0 19243 19237 7 68 0 13436 2932 wait I - 0:00.00 | = | | `-- /bin/sh - /etc/periodic/security/100.chksetuid 0 19245 19243 1 68 0 15204 2212 piperd I - 0:00.00 | = | | `-- cat is also stuck. So the problems are now not limited to the kyua run. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Aug 4 06:59:32 2023 X-Original-To: freebsd-current@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 4RHGmg450dz4ghvQ for ; Fri, 4 Aug 2023 06:59:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.148]) (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 4RHGmd6wQpz3ZVJ for ; Fri, 4 Aug 2023 06:59:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=t8Att6Be; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.148 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=1691132383; bh=xsBVUR7anpefwz1xxhrt9Fh1APodPazBtkqWIjZ1NpE=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=t8Att6BeJRPxz3KXM9g89WbWma7Pa8pYnr860gAzD/iDRqSscbEQ05PfmN4LEtSOpDzpKKkyvy03yCpPyLWjXbQF6guJoFeQL8xJL2Z/sRkS7SoNGCO7zQG9fJaB8D3/uCsdPuocXs2JK8ZKe3D3tzxwF/AeHDlKjLYeYeIqkIVabIGCGrzVOfzQyZF7v5Hv+7rH2tJaCKi+2eZRerR/yFFHrwUZIL59XiWLZ0uR3qC2u/PPpCJWPAcQwWcXSsoWKXlfK9vraS9GN62mx3+6g2gnNEKgnCfBHLqYwmbHXE65UL142B4aWSkoYrgdrHPX71beHgUGeAi4Lzz43EC9xQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691132383; bh=7EmNWyRXmEIxHTRYSjCqrMH7pjGSAocAWYJqdN/Zb9J=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=KZBrMzIw8oocJ57m1Io1nS118WqunGjs+vjB0jl5FXVnK2fZx9SEa/6PpLPE4H13tUozeSQke3mBWW0eDAe1W+aVXn796l/xxfgBNe8tRAL4aN8vRTjBeGR/ZFbulC43scFLOPN7SayYLO7jLC96W665TYt5XMJC1ILPmF1v7KEQbTx3WLnbytvobWWQKKOxaua2nHpfP3951/LV8gfoxIbgf1GE8rZN7rla9h9tc9NWfoo806ZvXFzmVbT/kucofuKyMwC2Vj+ZoJTNhHLtFtYX+ESkx+QtCo0qQgFFWjfj77h93ztgj89B9xn0ca5i41dUqRps+JFEWvXg71mXAQ== X-YMail-OSG: e.GW17wVM1kkEKTCT1z28vi0VwKPhkfntN.arSiKz_nmVaPYT5ce.L5_ayE1nNN UITG27RYhNTfDb3CQ02hwSHyB3Pkze6TJQuCDsQTS843ClRD7cIbzD4ZHlKZh.1jeOIWYE_PztJ6 ULJv1aNAWDmqSWWNpopGQiyixkXGHX0bZOTTTqolz6HzhK7vi7.hYdwq_h02MRV4.SLUg8oLZxsz dHXwNJWfUkAwJSolV8tNmNBRt8Vtc.d7AvoL3fGAzRWNj9uROiJMEhVxSnrjLeYMiDb14B7Cgbp1 OyfY4Wr7p_7rvovou1AA2Z.TJAS0TV50CZCwUfA0lRv6Q2ufy9HO8ResbJiYExPGm7I6zMUOVF4E Ma.lo_RyHpLG9VryljMaRukD9EXce6bCmhhlbo7ic2FVk2vxQe0bzW0X0GGuulY8LmQm8htDM5Ov 7F5ztDd0ME_xkjtGm32mnecpY8XqpLJY3X7ImIdNgO1605ANybb_hbA0mjpo8nzviTYIj7cNuHpg peqTHfpmZ79I9jQjs6MhxclQYWA8BSVP1tGtHpHp88D5qSMjJcSPQA.wwKk37nnfie65FGkgsvgc fkpv1tnnky5D.Wkav0S6ZW588fTHXxhHADHk1qTaFmoHcTglPSAXL1D._v04Qi67FpW.4OqJB_Wc PvyA1rJvj.QYjeRCEnnRkhWTX46bBLH2ToM0Xycdst.dmgSHtE9tg4TRmNmdrmBNjYOhT2ymMq8i Gy3M3l8uDrhvwn3bk_1pv0bkf.VdCKSmEzNWe0l0PPvIhO1TL4QipsWNBlH2EAu22f5drLhKf5jV ml792MqdfwXDQ45ZSfDZ6N.91MqmocVOBBwdNPrj1rL1VK6GWnEuU6AQ0H_6ceFqavJqWw2AJs0V ucjFWOy0ftPy8nkkT26lQ.o6cpqCPRb8nQUpyq.y3j5L9q4TeSZx2NMvnGv36GV.Lmadf5E8gTIF 0zPUb79XmbkwVdjzo9AvEJaQL6ftHqsh7ARhRG.YPmPOK4XQk_mwElbU4juFzpQEZfXidBAiyfwS l3PtmamAziGhkcpx98Ya5xzde8BoPevlOrs5Ri1GK3QUtLPcS2bdoqhfdlimQkWdEFSqzJ7qFEp9 OP0pKD63EGWnkRQqSRt_.A_SKcymcNlJNwyxiNA79adt1r6LvaNhKNH47lbSzBJvrEClI1srhQcN rVt462GarHU4TDZ3gZTUtIVJG62OUhjtU1Vv8hkOQdskDhdgS8tL8nl2GNwWqALzeufmXa.PxsYI UkRuVF9vmPGFXG9e0roS0N8cO7H1ubrIXgZZaYOINe5GDDCvW19sX7tjfSGYAi19tClas4Fi4h7W H.kZm2y9isqHTzJY61CvD_Fgkj9sgC91jN5aUtoWpMHiMHcOoVrVpYftMcVAIM2WPPs62ItiN_or uvy8H3fq4nDE3fUMrdRiMlt7zXDVendM1VedHSsR4aTneKghCI4rqqN86HeF1L_qJ0ljIi6REU_w jfeJhhX_AUkogtfKl5eq_LTkFbXqcaHRYwC3AGI2bGgozfxmW_JUh8Debf_AU18.j32KUHDViO4s wK0anIqXKiey1Fuz.6GgRxmjOcrcfzGMuQzoG0nviALo6U1gzrrUE4XnK2yph6yLbnC3R1TBV.Rz 2VXCJ3onElIUOPJSU.iew5hGgJl6UNs1zziYHu97n7c5cg3HtVqzj37lHqDZrOXe28k8tlAv_mEY QbiZ6EkfcGUSGZyAoBARgSyFKTO2xx1uvIpJ.T460b3FFaNKOVuq9cVTY_hlD3LIM0r6ZTdWLVVB SGlO8zMcTD.Xec7jelHeeFwJQeeksqfWsA5QzAukSf6um2QIU_v_bR7Ffc450ufltjdInkEW7qRS 6T8LXtN9Xyv16D6Pk5DC8JncHAyK2k5wJFXplVRTlu3Tr1p3PiO2JTlAo_hPneZvqfoWll303MtM 2qhRttcNQPPIw0CyE5HAaZivf5J3D1C.wp4GbG8oc_oMeLOl5AgsnneeeD3_LGJvNwWEIqfXDFoS uje6v79VGLeIb6iNIOWcQ6OWHkxtxFyk2Xk._efTqL_AeQfd.cMrAeowo0.Gl3OTvjyzm_I7Ijyp QhcSRIy1xcxpN4VMm6_3V8RvOdaAydpDrKrL3P.YLiDD6rzG05cltAzRWsv_dcmsDa5VfmaEnzWp qXzcwD8P6Sc0A8M6nix7GXHJYdZDLSLYgNwN9FxFDcfi8m3iKFI24c3ReeEcsqQJWz_GTz3cH.Nd x2VaE52eRhoh3sRkFIWorXKUKNMUoWBUNj_QP95TLg1yDLEr9kC28R1YGu3XL8Qd3yos.8LXqCew vw_hCtw-- X-Sonic-MF: X-Sonic-ID: e04bd980-d154-4de8-8a41-1f7fadaf92f6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Fri, 4 Aug 2023 06:59:43 +0000 Received: by hermes--production-gq1-7d844d8954-ll2wj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 896913c23f84edecdfd192e85b4b3ff4; Fri, 04 Aug 2023 06:59:42 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: A native armv7 panic during kyua runs: sys/netinet6/exthdr:exthdr -> Fatal kernel mode data abort: 'Alignment Fault' on read Message-Id: Date: Thu, 3 Aug 2023 23:59:32 -0700 To: FreeBSD ARM List , Current FreeBSD X-Mailer: Apple Mail (2.3731.700.6) References: X-Spamd-Result: default: False [-1.30 / 15.00]; NEURAL_HAM_SHORT(-0.80)[-0.801]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.148:from]; BLOCKLISTDE_FAIL(0.00)[98.137.66.148:server fail]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.148:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(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]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: - X-Rspamd-Queue-Id: 4RHGmd6wQpz3ZVJ 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=3D00000001, FAR=3Ddb43ab76, spsr=3D60000013 r0 =3Ddfedd000, r1 =3Ddfb97b34, r2 =3D00000000, r3 =3D00000000 r4 =3D00000000, r5 =3D00000000, r6 =3Ddb43ab76, r7 =3Ddb43ab66 r8 =3Dc096383c, r9 =3D00000000, r10=3Ddb132400, r11=3Ddfb97b60 r12=3D00000000, ssp=3Ddfb97b30, slr=3Dc0b4e2c0, pc =3Dc04e6b70 panic: Fatal abort cpuid =3D 0 time =3D 1691131498 KDB: stack backtrace: db_trace_self() at db_trace_self pc =3D 0xc065f414 lr =3D 0xc007db80 = (db_trace_self_wrapper+0x30) sp =3D 0xdfb97858 fp =3D 0xdfb97970 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc007db80 lr =3D 0xc031a834 (vpanic+0x140) sp =3D 0xdfb97978 fp =3D 0xdfb97998 r4 =3D 0x00000100 r5 =3D 0x00000000 r6 =3D 0xc07c369a r7 =3D 0xc0b32e58 vpanic() at vpanic+0x140 pc =3D 0xc031a834 lr =3D 0xc031a6f4 (vpanic) sp =3D 0xdfb979a0 fp =3D 0xdfb979a4 r4 =3D 0xdfb97aa0 r5 =3D 0x00000013 r6 =3D 0xdb43ab76 r7 =3D 0x00000001 r8 =3D 0x00000001 r9 =3D 0xdfedd000 r10 =3D 0xdb43ab76 vpanic() at vpanic pc =3D 0xc031a6f4 lr =3D 0xc06849dc (abort_align) sp =3D 0xdfb979ac fp =3D 0xdfb979d8 r4 =3D 0x00000001 r5 =3D 0x00000001 r6 =3D 0xdfedd000 r7 =3D 0xdb43ab76 r8 =3D 0xdfb979a4 r9 =3D 0xc031a6f4 r10 =3D 0xdfb979ac abort_align() at abort_align pc =3D 0xc06849dc lr =3D 0xc0684a50 (abort_align+0x74) sp =3D 0xdfb979e0 fp =3D 0xdfb979f8 r4 =3D 0x00000013 r10 =3D 0xdb43ab76 abort_align() at abort_align+0x74 pc =3D 0xc0684a50 lr =3D 0xc06846a8 (abort_handler+0x45c) sp =3D 0xdfb97a00 fp =3D 0xdfb97a98 r4 =3D 0x00000000 r10 =3D 0xdb43ab76 abort_handler() at abort_handler+0x45c pc =3D 0xc06846a8 lr =3D 0xc0661cc8 (exception_exit) sp =3D 0xdfb97aa0 fp =3D 0xdfb97b60 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xdb43ab76 r7 =3D 0xdb43ab66 r8 =3D 0xc096383c r9 =3D 0x00000000 r10 =3D 0xdb132400 exception_exit() at exception_exit pc =3D 0xc0661cc8 lr =3D 0xc0b4e2c0 (__pcpu) sp =3D 0xdfb97b30 fp =3D 0xdfb97b60 r0 =3D 0xdfedd000 r1 =3D 0xdfb97b34 r2 =3D 0x00000000 r3 =3D 0x00000000 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xdb43ab76 r7 =3D 0xdb43ab66 r8 =3D 0xc096383c r9 =3D 0x00000000 r10 =3D 0xdb132400 r12 =3D 0x00000000 in6ifa_ifwithaddr() at in6ifa_ifwithaddr+0x30 pc =3D 0xc04e6b70 lr =3D 0xc04f9030 (ip6_input+0xd38) sp =3D 0xdfb97b68 fp =3D 0xdfb97c28 r4 =3D 0xdb43ab76 r5 =3D 0xdb43ab5e r6 =3D 0x00000000 r7 =3D 0xdb43ab66 ip6_input() at ip6_input+0xd38 pc =3D 0xc04f9030 lr =3D 0xc046d66c (netisr_dispatch_src+0xf8) sp =3D 0xdfb97c30 fp =3D 0xdfb97c58 r4 =3D 0xdb43ab00 r5 =3D 0x00000006 r6 =3D 0x00000007 r7 =3D 0xc0b49d50 r8 =3D 0xdafea0c0 r9 =3D 0xdb43ab00 r10 =3D 0x00000086 netisr_dispatch_src() at netisr_dispatch_src+0xf8 pc =3D 0xc046d66c lr =3D 0xc04641b0 (ether_demux+0x18c) sp =3D 0xdfb97c60 fp =3D 0xdfb97c78 r4 =3D 0x00000006 r5 =3D 0x00001201 r6 =3D 0xdb132400 r7 =3D 0x000000ff r8 =3D 0xdafea0c0 r9 =3D 0xdb43ab00 r10 =3D 0x00000086 ether_demux() at ether_demux+0x18c pc =3D 0xc04641b0 lr =3D 0xc0465880 (ether_nh_input+0x490) sp =3D 0xdfb97c80 fp =3D 0xdfb97ce0 r4 =3D 0xdb132400 r5 =3D 0xdb43ab00 r6 =3D 0xdb43ab50 r10 =3D 0x00000086 ether_nh_input() at ether_nh_input+0x490 pc =3D 0xc0465880 lr =3D 0xc046d66c (netisr_dispatch_src+0xf8) sp =3D 0xdfb97ce8 fp =3D 0xdfb97d10 r4 =3D 0xdb43ab00 r5 =3D 0x00000005 r6 =3D 0x0000000c r7 =3D 0xc0b49d30 r8 =3D 0xdafea0c0 r9 =3D 0xdb43ab00 r10 =3D 0xc098d18f netisr_dispatch_src() at netisr_dispatch_src+0xf8 pc =3D 0xc046d66c lr =3D 0xc04645c4 (ether_input+0x50) sp =3D 0xdfb97d18 fp =3D 0xdfb97d48 r4 =3D 0xdb43ab00 r5 =3D 0x00000000 r6 =3D 0x00008803 r7 =3D 0x00000000 r8 =3D 0xdafea0c0 r9 =3D 0xdb43ab00 r10 =3D 0xc098d18f ether_input() at ether_input+0x50 pc =3D 0xc04645c4 lr =3D 0xdffb3f08 ($a.10+0x108) sp =3D 0xdfb97d50 fp =3D 0xdfb97d78 r4 =3D 0xdb132400 r5 =3D 0xdaff8b00 r6 =3D 0xdaff8b10 r7 =3D 0x00000000 r8 =3D 0x00000000 r10 =3D 0xc098d18f $a.10() at $a.10+0x108 pc =3D 0xdffb3f08 lr =3D 0xc038cb2c = (taskqueue_run_locked+0x1c4) sp =3D 0xdfb97d80 fp =3D 0xdfb97dd8 r4 =3D 0xe0145100 r5 =3D 0xdaff8b2c r6 =3D 0xe0145150 r7 =3D 0x00000001 r8 =3D 0x00000000 r9 =3D 0xdfb97d90 r10 =3D 0x00000001 taskqueue_run_locked() at taskqueue_run_locked+0x1c4 pc =3D 0xc038cb2c lr =3D 0xc038e4e4 = (taskqueue_thread_loop+0x1b0) sp =3D 0xdfb97de0 fp =3D 0xdfb97e10 r4 =3D 0xe0145100 r5 =3D 0xe0145140 r6 =3D 0xc07af4c4 r7 =3D 0x00000000 r8 =3D 0xc098d18f r9 =3D 0x00000100 r10 =3D 0xc0b228a0 taskqueue_thread_loop() at taskqueue_thread_loop+0x1b0 pc =3D 0xc038e4e4 lr =3D 0xc02cdf0c (fork_exit+0xc0) sp =3D 0xdfb97e18 fp =3D 0xdfb97e38 r4 =3D 0xdfedd000 r5 =3D 0xc0b224e0 r6 =3D 0xc038e334 r7 =3D 0xdffc4f54 r8 =3D 0xdfb97e40 r9 =3D 0xc098d191 fork_exit() at fork_exit+0xc0 pc =3D 0xc02cdf0c lr =3D 0xc0661c5c (swi_exit) sp =3D 0xdfb97e40 fp =3D 0x00000000 r4 =3D 0xc038e334 r5 =3D 0xdffc4f54 r6 =3D 0xc0b45d84 r7 =3D 0xd73bcba0 r8 =3D 0x00000001 r10 =3D 0xc0b228a0 swi_exit() at swi_exit pc =3D 0xc0661c5c lr =3D 0xc0661c5c (swi_exit) sp =3D 0xdfb97e40 fp =3D 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.a= rmv7/sys/GENERIC-NODBG-CA7 arm armv7 1400093 1400093 The OrangePi+ 2Ed was the type of system booted and tested. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Aug 4 16:07:46 2023 X-Original-To: freebsd-current@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 4RHVx06KcSz4Tpft for ; Fri, 4 Aug 2023 16:07:48 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RHVx05ScSz3XQ9; Fri, 4 Aug 2023 16:07:48 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691165268; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=B+Bv1EoDs1BK3n4p5GE/1B7iP4qRiiVncqqfqaxclYY=; b=G2NJnATFagXu0EjFxmrC3Lx1Izry+7PueCd9vgkrvp2oe8Jl3/x4PFvmIZi6HnCxZNv6vq AlDeUOfi12gKJ8QsdbBO+Wm0sieC3WMnmIVzs0UNRp601rnDUMfWWR+idzq1EPvuZ4OVPT lVU1PYDFbi1EFPlTEks3vQPV2z3nVaWbR0tqX18hgINaasZ3bidl3HAUf6QCnJ9NhS0Vr6 2L1Qqt9lZ5/53EsaB2uXZzHOSqRkP3GYVam4jCI568lxcSNaVL8vPIM+vd2tIGYDA1seTD xkQwqZpC5CePsHaTqGrXe2efMUTxVW5m46/2yilPx7wLKTap4DOV76H7q2Ccvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691165268; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=B+Bv1EoDs1BK3n4p5GE/1B7iP4qRiiVncqqfqaxclYY=; b=RVOfqPoeKC79LG3cH5TSyV/iysEwRhVsxQDcISUruzkA4ODdAeBztnR6nZkx7e8QA+EU/6 hE7EnY63d3fapc6iBfNnEr5zavC4+FouWAUzeqgLk0NAr7ABuTR/TkLmrSyBcIfWaJ612r +adCi32imohHy6OV3gow1Rt9ZNC4LeFkYzOkpPvJ60Ykl1QS08mhLuoHwJxApitIw7xUI4 Z3Pzo1A4I7Up1H9zY3kH5woybvs6ddK22FSQcvapUre7aAVmfM+AG3uUkDQBIv6upI3uY0 jKf6xZ1PuiHDP7tCVYzAlOH8yqC4jWJHIDdcuNRvijcix8aeCR3uCGIJsbeSlA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691165268; a=rsa-sha256; cv=none; b=vn171FKFbm+tQfvz6SduLwJW1A1zFxHSWBFkRBn3AWSPaeO4hKeh5ZsO5XPUC8BLE1jZhh T6TH2w9kyykOlUiimY4XWStpm/BrahUZQGgBnLFaIr33geQEiMB/OtHZA0Eg8DgZfGvR/7 MOGg8bHjOgXJach+Cs7bMg9Hj0TqiteT+xFoE6nzbOFs+0EGwaSaPayJSrvpj3Dn9XMmDt vdI/d3wGIsSwHgHV5+eFC591Apt8n/K9QbR8kznC9AyT7PnwDZJltPBXKJuCshIngwba7c RFo21BAftWim6pxINdUNGeHUEOquGn0/kt1hdumup+5vVJEJBaLTqm7hfkJUoQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [192.168.1.10] (80-42-66-93.dynamic.dsl.as9105.com [80.42.66.93]) (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) (Authenticated sender: grahamperrin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RHVx02ZkKz14fp; Fri, 4 Aug 2023 16:07:48 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Message-ID: Date: Fri, 4 Aug 2023 17:07:46 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.13.1 Subject: Fwd: Unreliability with DHCP Content-Language: en-US References: <62d300c8-2c3e-58fa-334e-23a17962279a@freebsd.org> To: freebsd-net@frebsd.org Cc: FreeBSD CURRENT From: Graham Perrin Organization: FreeBSD In-Reply-To: <62d300c8-2c3e-58fa-334e-23a17962279a@freebsd.org> X-Forwarded-Message-Id: <62d300c8-2c3e-58fa-334e-23a17962279a@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Yp6yKxrX25rpRR1ktglCkql6" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Yp6yKxrX25rpRR1ktglCkql6 Content-Type: multipart/mixed; boundary="------------SngHB0XX5kk0k0UVVO3vTet0"; protected-headers="v1" From: Graham Perrin To: freebsd-net@frebsd.org Cc: FreeBSD CURRENT Message-ID: Subject: Fwd: Unreliability with DHCP References: <62d300c8-2c3e-58fa-334e-23a17962279a@freebsd.org> In-Reply-To: <62d300c8-2c3e-58fa-334e-23a17962279a@freebsd.org> --------------SngHB0XX5kk0k0UVVO3vTet0 Content-Type: multipart/alternative; boundary="------------xonAaB2lSz9728lNHo62ncvE" --------------xonAaB2lSz9728lNHo62ncvE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Q2FuIGFueW9uZSBmcm9tIGZyZWVic2QtbmV0QCBoZWxwPw0KDQoNCi0tLS0tLS0tIEZvcndh cmRlZCBNZXNzYWdlIC0tLS0tLS0tDQpTdWJqZWN0OiAJVW5yZWxpYWJpbGl0eSB3aXRoIERI Q1ANCkRhdGU6IAlTdW4sIDMwIEp1bCAyMDIzIDE2OjE3OjQzICswMTAwDQpGcm9tOiAJR3Jh aGFtIFBlcnJpbiA8Z3JhaGFtcGVycmluQGZyZWVic2Qub3JnPg0KT3JnYW5pc2F0aW9uOiAJ RnJlZUJTRA0KVG86IAlGcmVlQlNEIENVUlJFTlQgPGZyZWVic2QtY3VycmVudEBmcmVlYnNk Lm9yZz4NCg0KDQoNCjEuIFNsZWVwIChzdXNwZW5kKSB3aGlsc3QgY29ubmVjdGVkIHRvIG9u ZSBuZXR3b3JrDQoNCjIuIGNvbm5lY3QgdG8gYSBuZXR3b3JrIGVsc2V3aGVyZQ0KDQozLiB3 YWtlIChyZXN1bWUpLg0KDQpSZXN1bHQ6DQoNCi9ldGMvcmVzb2x2LmNvbmYgZnJlcXVlbnRs eSBjb250YWlucyBvdXRkYXRlZCBpbmZvcm1hdGlvbi4gSW4gc29tZSANCihtYXliZSBhbGwp IHN1Y2ggY2FzZXMsIHRoZSBJUHY0IGluZXQgYWRkcmVzcyBpcyBvdXRkYXRlZDsgYW5kIHNv IG9uLg0KDQpXaGljaCAvZXRjL3JjLmQvIGZpbGUocykgc2hvdWxkIEkgYXR0ZW1wdCB0byBm aXg/DQoNCkkgaW1hZ2luZSB1c2luZyB0aGUgcmVzdW1lIGtleXdvcmQsIHdoaWNoIGlzIGN1 cnJlbnRseSB1c2VkIGJ5IG9ubHkgb25lIA0Kc2NyaXB0Og0KDQolIHJjb3JkZXIgLWsgcmVz dW1lIC9ldGMvcmMuZC8qDQovZXRjL3JjLmQvbnRwZA0KJQ0KDQoNCkkgcm91dGluZWx5IHJ1 biB0aGUgY29tbWFuZCBiZWxvdyB0byB3b3JrIGFyb3VuZCB0aGUgYnVnIChhbmQgb2JzZXJ2 ZSANCnRoZSBzdGF0ZXMgb2YgdGhpbmdzKSDigJMgcnVuIF9hZnRlcl8gdGhlIGJ1ZyBiaXRl cy4gSSdkIHByZWZlciBhIGZpeCwgdG8gDQpwcmV2ZW50IHRoZSBiaXRlcy4NCg0KbHMgL3Zh ci9ydW4vcmVzb2x2Y29uZi9pbnRlcmZhY2VzLyA7IHJvdXRlIGRlbGV0ZSBkZWZhdWx0IDsg aWZjb25maWcgDQp3bGFuMCBkb3duICYmIGlmY29uZmlnIGVtMCBkb3duICYmIHNsZWVwIDUg OyBscyANCi92YXIvcnVuL3Jlc29sdmNvbmYvaW50ZXJmYWNlcy8gOyBpZmNvbmZpZyBlbTAg dXAgJiYgc2xlZXAgMTUNCjsgbHMgL3Zhci9ydW4vcmVzb2x2Y29uZi9pbnRlcmZhY2VzLyA7 IGNhdCAvZXRjL3Jlc29sdi5jb25mIDsgcGluZyAtYyAyIA0KLTQgZnJlc2hwb3J0cy5vcmcN Cg0K --------------xonAaB2lSz9728lNHo62ncvE Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Can anyone from freebsd-net@ help?


-------- Forwarded Message --------
Sub= ject: Unreliability with DHCP
Dat= e: Sun, 30 Jul 2023 16:17:43 +0100
Fro= m: Graham Perrin <grahamperrin@freebsd.org>
Org= anisation: FreeBSD
To:= FreeBSD CURRENT <freebsd-current@freebsd.org><= /a>


1. Sleep (suspend) whilst connected to one network

2. connect to a network elsewhere

3. wake (resume).

Result:

/etc/resolv= =2Econf frequently contains outdated information. In some (maybe all) such cases, the IPv4 inet address is outdated; and so on.

Which = /etc/rc.d/ file(s) should I attempt to fix?

I imagine using the resume keyword, which is currently used by only one script:

% rcorder -= k resume /etc/rc.d/*
/etc/rc.d/ntpd
%


I routinely run the comman= d below to work around the bug (and observe the states of things) =E2=80=93 run _after_ the bug bites. I'd prefer a fix, = to prevent the bites.

ls /var/run/resolvconf/interfaces/ ; route delete default ; ifconfig wlan0 down && ifconfig em0 down && sleep 5 ; ls /var/run/resolvconf/interfaces/ ; ifconfig em0 up && sleep 15
; ls /var/run/resolvconf/interfaces/ ; cat /etc/resolv.conf ; ping -c 2 -4 freshports.org

--------------xonAaB2lSz9728lNHo62ncvE-- --------------SngHB0XX5kk0k0UVVO3vTet0-- --------------Yp6yKxrX25rpRR1ktglCkql6 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmTNIlIFAwAAAAAACgkQt2dIb0oY1At9 /w//V1LRaEbnxfYRxu4HIGkYfwWtvUJU8fo5nChtNnDQk18mDb7EahZQTLY8ZvarPxME3Fso0gep gZaGFvobOVAuBgX3/XlC0mj6hdlE+zjaihdp1ZJsLxnjsXMGSkT6DOROQqkBWTXodA0xEd2k24ef PnwerlX/2KVP8xZfsbk26dMCLm0lPlrDNxBYkAtk/daBdjiJvz8Up8KTpOTAztPGYsAE2qdqUA1O JaZ1UiawVOXIgkb3JMvDIS3p3rsQdSc2PFFYiaDVGVs1RUB00etdkcqVlDWeLbm+K/ChZs3qoMJu UaSAJOTkcJuv2BcjJuBvPMlxO0LjN9uH9R9r6OOTrlagoALeIorFJwq7sAO7XzdUEXdyuCLL2n57 LEafi6OsPn8e64Z6SvJ7I55seRqDbUGOPkKuWsuigb6ntPbJADYYNhma/WyGTXzxT485SVz9bIFf N/KPnvdymq3Re8CxoO9SfSgF8/mhsTwDe2c0wyx+jnfb03InfZq8YzmVqmQ2xgzAx1Nxz9JKzz2p 9kqJx/Ter+TBbCB6exxt3WmRMinhIg4vJjn8GQv68lwF/9WlKg/R50Bq2Ktmy9gEx+gH51QYimwZ mjkfElIzNXCBzC5S9qZt8+z9ArOWSLsubxONcdTDam5eAJp9QCIk8QOqAXexfq9ucd0Fe0jUEYBG y9c= =tNCm -----END PGP SIGNATURE----- --------------Yp6yKxrX25rpRR1ktglCkql6-- From nobody Fri Aug 4 23:45:48 2023 X-Original-To: freebsd-current@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 4RHj5c3Nzqz4mFjD for ; Fri, 4 Aug 2023 23:45:56 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 4RHj5b4qkvz3N87 for ; Fri, 4 Aug 2023 23:45:55 +0000 (UTC) (envelope-from kob6558@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=f+EiNTbj; spf=pass (mx1.freebsd.org: domain of kob6558@gmail.com designates 2607:f8b0:4864:20::b2e as permitted sender) smtp.mailfrom=kob6558@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yb1-xb2e.google.com with SMTP id 3f1490d57ef6-d3d729a08e4so2923025276.3 for ; Fri, 04 Aug 2023 16:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691192754; x=1691797554; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=ml+kRkHxt56ed4o1h1XkIuHitbJIJCTtB4xxk4ieRCE=; b=f+EiNTbjjbLOziLk5nV1tKzmeyFBDx4MvXIKT2n/Me7hZKu+3An4dN0ceXzkYQfd25 UusbVGNNh7PmPaHVTa4UMp/EkM7xH9Ytr7bmnYuOW6iiCqRUB/cBQn3F1b1mBYAocpjM jBboyihqqYWXgGzulpsVS2OEHO0aS2nO9y/1AmbQLpaiWyMpj9w1p4Jz8KNGPLLhDLuT QJB+LY25OxDzzMDy9yJ2jSHturMK46gW0zu6+jZoGk4iXpKMpUVmgJB618Lo4AtXR/bc ikXjiHwTaRlfhkzSDQ96HxY8RfDFEB4EBhriOOzxZxGMda8OLocNbEC7byyOg00z6FDn vSbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691192754; x=1691797554; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ml+kRkHxt56ed4o1h1XkIuHitbJIJCTtB4xxk4ieRCE=; b=jsW+bEkqnAI7zKWJIhjX4xWIzZJ+g3fIAnAAhAcTi7S2NOTHHAHA67pqEcXGpgLv7w ekKAStSMuap0J/xE4rZPT2jjSlGB46Lup9uzBGD4RwYWVSjMq8OjuOOMqV9Tuz25tE17 v1qTNysdPKmChAS4sRFk2rEZKXhbWIeC/4UYVUPI1zo2t8kayJ0D68D0TlSLAG7Fv+y+ qZ+k2is1QyGlLum4Sf2bkYQiV1Q3QRm1i/GlBC7/iW6oKBr3vl8mudff33eniyF8HNi1 ySYB14MaUSJ6dMSDYnp0iRcD8sj3x+69Tx7d7TVYGMBw7j3etSKVMsi/PkKEib2z3Dnj 0Wdw== X-Gm-Message-State: AOJu0YxqHlRevEaWvlKQzOd2foOucB4OcSPZ+DeEa+f7EMSUxGHrKJnE 3k2mX0I0yuO+NMylcCL3x0CWQ6aFDVphFwjX9/+aYBEm X-Google-Smtp-Source: AGHT+IFqCaotNTwnE5V7NxyLRwvHNFxXCVvxMzFMYPiZabzxk7JnYaUm75b2OGgWQdTG6Bhm56dJqWbRQ6JXopK61nk= X-Received: by 2002:a25:ad44:0:b0:d0e:b5c8:6359 with SMTP id l4-20020a25ad44000000b00d0eb5c86359mr2951167ybe.55.1691192754636; Fri, 04 Aug 2023 16:45:54 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Kevin Oberman Date: Fri, 4 Aug 2023 16:45:48 -0700 Message-ID: Subject: 14.0 boot failure To: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000630d520602217f9b" X-Spamd-Result: default: False [-2.17 / 15.00]; NEURAL_HAM_SHORT(-0.80)[-0.800]; NEURAL_HAM_MEDIUM(-0.67)[-0.670]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FORGED_SENDER(0.30)[rkoberman@gmail.com,kob6558@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; BLOCKLISTDE_FAIL(0.00)[2607:f8b0:4864:20::b2e:server fail]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2e:from]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_NEQ_ENVFROM(0.00)[rkoberman@gmail.com,kob6558@gmail.com]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4RHj5b4qkvz3N87 --000000000000630d520602217f9b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A new kernel built from sources pulled today (4-Aug) at 5:26 UTC fails to boot. This is the output of the boot attempt: VT-x: PAT,HLT, MTF, PAUSE, EPT, UG, VPID, VID, Post Intr TSC: P-state invariant, performance statistics real memory =3D 25769883776 (24576 MB) panic: vm_phys_enq_range: page 0xfffffe00285c8a58 and npages 8 are misaligned cpuid =3D 0 time =3D 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff822abba=C5=82 vpanic() at vpanic+0x149/frame 0xffffffff822abbf0 panic() at panic+0x43/frame 0xffffffff822abc50 vm_phys_enq_range() at vm_phys_eng_range+0x12d/frame 0xffffffff822abc60 vm_phys_alloc_contig() at vm_phys_alloc_contig+8x557/frame 0xffffffff822abcf8 vm_page_find_contig_domain() at vm_page_find_contig_domain+0xbe/frame 0xffffffff822abd68 vm_page_alloc_contig_domain() at vm_page_alloc_contig_domain+0x135/frame 0xffffffff822abdf8 kmem_alloc_contig_pages() at kmem_alloc_contig_pages+8x92/frame 0xffffffff822abe88 kmem_alloc_attr_domainset() at kmem_alloc_attr_domainset+0x20d/frame Bxffffffff822abf48 vm_ksubmap_init() at vm_ksubmap_init+0x65/frame 0xffffffff822abf80 cpu_startup() at cpu_startup+0x28b/frame Bxffffffff822abfa8 mi_startup() at mi_startup+8x1f1/frame 0xffffffff822abff8 btext() at btext+0x23 KDB: enter: panic [ thread pid 8 tid 0 ] Stopped at kdb_enter+0x32: movq $0,0xdec6e3(%rip db> Any ideas? Pior working kernel (which I'm now running) is n263931-5aee3e14d491. Died too early in the boot for a dump. --000000000000630d520602217f9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A new kernel built from sources pulled today (4-Aug) at 5= :26 UTC fails to boot.

This is= the output of the boot attempt:
V= T-x: PAT,HLT, MTF, PAUSE, EPT, UG, VPID, VID, Post Intr

TSC: P-state invariant, performance statist= ics real memory =3D 25769883776 (24576 MB)

panic: vm_phys_enq_range: page 0xfffffe00285c8a58 and np= ages 8 are misaligned

cp= uid =3D 0

time =3D 1

KDB: stack backtrace:
=

db_trace_self_wrapper() at db= _trace_self_wrapper+0x2b/frame 0xffffffff822abba=C5=82

vpanic() at vpanic+0x149/frame 0xffffffff822= abbf0 panic() at panic+0x43/frame 0xffffffff822abc50

vm_phys_enq_range() at vm_phys_eng_range+0x12d= /frame 0xffffffff822abc60

vm_phys_alloc_contig() at vm_phys_alloc_contig+8x557/frame 0xffffffff822a= bcf8

vm_page_find_contig= _domain() at vm_page_find_contig_domain+0xbe/frame 0xffffffff822abd68 vm_pa= ge_alloc_contig_domain() at vm_page_alloc_contig_domain+0x135/frame 0xfffff= fff822abdf8

kmem_alloc_c= ontig_pages() at kmem_alloc_contig_pages+8x92/frame 0xffffffff822abe88 kmem= _alloc_attr_domainset() at kmem_alloc_attr_domainset+0x20d/frame Bxffffffff= 822abf48

vm_ksubmap_init= () at vm_ksubmap_init+0x65/frame 0xffffffff822abf80
=
cpu_startup() at cpu_startup+0x28b/frame Bxffff= ffff822abfa8 mi_startup() at mi_startup+8x1f1/frame 0xffffffff822abff8

btext() at btext+0x23 KDB: e= nter: panic

[ thread pid= 8 tid 0 ]

Stopped at kd= b_enter+0x32: movq $0,0xdec6e3(%rip

db>

Any i= deas?=C2=A0 Pior working kernel (which I'm now running) is n263931-5aee= 3e14d491. Died too early in the boot for a dump.
--000000000000630d520602217f9b-- From nobody Sat Aug 5 03:58:52 2023 X-Original-To: freebsd-current@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 4RHpjg4fLcz4pWfx for ; Sat, 5 Aug 2023 03:59:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 4RHpjg2XrKz4H0g for ; Sat, 5 Aug 2023 03:59:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-522382c4840so3585983a12.2 for ; Fri, 04 Aug 2023 20:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1691207940; x=1691812740; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HAlubeffy/qCvRO+r80jY7IGovS3vkyTzrOjyYE3aa0=; b=EA8/rZEOKq4ot+Z57q7/utfNZGUpXv75QrZ9aPLG6QlVZeXf05itWF9HNTNqyzKU2m 0rK+sc9xJ45UIIrA6uTTdla9b9cjhuH/By9TbgUppe7jpCpFyNIFMA1/jKmfi0iekex/ NA2EozeArRadCNZpiVvE6/THKWVEbzZZO/J2As4qll6nJxFq2a95+C2iSHWwYiZQbWqi qsMe+T0nmwyek5shnboBaL5zXg5km71lQTBNtnJ0onKbe+fqX4KUlzWu5BtyiUyybTsF bpvf8CJveuiaVMhUSECOA3hhHgZzLGD5qcajxFzbOLZp0P3QhlrI5PO8ONwv5dSJW94u rr9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691207940; x=1691812740; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HAlubeffy/qCvRO+r80jY7IGovS3vkyTzrOjyYE3aa0=; b=CbPoWEzCbtZe9d0zVhheQROU2yw7md+ZDpTx8vNKThLVqXlg3ZiZKjJyCIeGHdQJEV MiPmYAYyRjtIrpxx9BI5XBA8jROTNGoV2jEAHnjeFH/rZt2Ed5KhRABFVU2tBvxH/F0e 4epLS9OHo+KCAaOzoLcxi3SPjI+vewb3/2MB1hjHGV+rlmGxtjIoLPMdc8tJtq26LqHG pmqaz7Dq2PMDxW/qsacbO/ETPCatNHyFnXZmiwV7fivZlcfaUj2ZTImVsrY7a8vc+h+r PgO5jpfiuhzI7PEURWekiPmkSqs5/q8EqDpkwOLTCEPcI2krotl15NQPmb/zVaBZiIYT G1Yw== X-Gm-Message-State: AOJu0Yw7567+O8fMK/AHhVJr4L/XYy4BSppMXBbntS5RtnBMcDLsaCH4 ZRgnF44jnvGOzp1Y6bNpTshwfmAvkN1kjpWdjcjq6A== X-Google-Smtp-Source: AGHT+IEaJkLoROA2mslXxAGKQyCjQ01I6POwL75qhV4DiJFrTIaivoCHo5y1/52ITuKgR60SKoB2JK1OnHqxhKPzXJs= X-Received: by 2002:aa7:dc12:0:b0:522:cb97:f198 with SMTP id b18-20020aa7dc12000000b00522cb97f198mr2650534edu.38.1691207940048; Fri, 04 Aug 2023 20:59:00 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Fri, 4 Aug 2023 21:58:52 -0600 Message-ID: Subject: Re: A native armv7 panic during kyua runs: sys/netinet6/exthdr:exthdr -> Fatal kernel mode data abort: 'Alignment Fault' on read To: Mark Millard Cc: FreeBSD ARM List , Current FreeBSD Content-Type: multipart/alternative; boundary="000000000000821b9706022508cc" X-Rspamd-Queue-Id: 4RHpjg2XrKz4H0g X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --000000000000821b9706022508cc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It might make sense to work up a patch that skips this test on armv7 after filing a bug (the usual way).... Warner On Fri, Aug 4, 2023 at 12:59=E2=80=AFAM Mark Millard wr= ote: > 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=3D00000001, FAR=3Ddb43ab76, spsr=3D60000013 > r0 =3Ddfedd000, r1 =3Ddfb97b34, r2 =3D00000000, r3 =3D00000000 > r4 =3D00000000, r5 =3D00000000, r6 =3Ddb43ab76, r7 =3Ddb43ab66 > r8 =3Dc096383c, r9 =3D00000000, r10=3Ddb132400, r11=3Ddfb97b60 > r12=3D00000000, ssp=3Ddfb97b30, slr=3Dc0b4e2c0, pc =3Dc04e6b70 > > panic: Fatal abort > cpuid =3D 0 > time =3D 1691131498 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc =3D 0xc065f414 lr =3D 0xc007db80 (db_trace_self_wrapper+0x30= ) > sp =3D 0xdfb97858 fp =3D 0xdfb97970 > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc =3D 0xc007db80 lr =3D 0xc031a834 (vpanic+0x140) > sp =3D 0xdfb97978 fp =3D 0xdfb97998 > r4 =3D 0x00000100 r5 =3D 0x00000000 > r6 =3D 0xc07c369a r7 =3D 0xc0b32e58 > vpanic() at vpanic+0x140 > pc =3D 0xc031a834 lr =3D 0xc031a6f4 (vpanic) > sp =3D 0xdfb979a0 fp =3D 0xdfb979a4 > r4 =3D 0xdfb97aa0 r5 =3D 0x00000013 > r6 =3D 0xdb43ab76 r7 =3D 0x00000001 > r8 =3D 0x00000001 r9 =3D 0xdfedd000 > r10 =3D 0xdb43ab76 > vpanic() at vpanic > pc =3D 0xc031a6f4 lr =3D 0xc06849dc (abort_align) > sp =3D 0xdfb979ac fp =3D 0xdfb979d8 > r4 =3D 0x00000001 r5 =3D 0x00000001 > r6 =3D 0xdfedd000 r7 =3D 0xdb43ab76 > r8 =3D 0xdfb979a4 r9 =3D 0xc031a6f4 > r10 =3D 0xdfb979ac > abort_align() at abort_align > pc =3D 0xc06849dc lr =3D 0xc0684a50 (abort_align+0x74) > sp =3D 0xdfb979e0 fp =3D 0xdfb979f8 > r4 =3D 0x00000013 r10 =3D 0xdb43ab76 > abort_align() at abort_align+0x74 > pc =3D 0xc0684a50 lr =3D 0xc06846a8 (abort_handler+0x45c) > sp =3D 0xdfb97a00 fp =3D 0xdfb97a98 > r4 =3D 0x00000000 r10 =3D 0xdb43ab76 > abort_handler() at abort_handler+0x45c > pc =3D 0xc06846a8 lr =3D 0xc0661cc8 (exception_exit) > sp =3D 0xdfb97aa0 fp =3D 0xdfb97b60 > r4 =3D 0x00000000 r5 =3D 0x00000000 > r6 =3D 0xdb43ab76 r7 =3D 0xdb43ab66 > r8 =3D 0xc096383c r9 =3D 0x00000000 > r10 =3D 0xdb132400 > exception_exit() at exception_exit > pc =3D 0xc0661cc8 lr =3D 0xc0b4e2c0 (__pcpu) > sp =3D 0xdfb97b30 fp =3D 0xdfb97b60 > r0 =3D 0xdfedd000 r1 =3D 0xdfb97b34 > r2 =3D 0x00000000 r3 =3D 0x00000000 > r4 =3D 0x00000000 r5 =3D 0x00000000 > r6 =3D 0xdb43ab76 r7 =3D 0xdb43ab66 > r8 =3D 0xc096383c r9 =3D 0x00000000 > r10 =3D 0xdb132400 r12 =3D 0x00000000 > in6ifa_ifwithaddr() at in6ifa_ifwithaddr+0x30 > pc =3D 0xc04e6b70 lr =3D 0xc04f9030 (ip6_input+0xd38) > sp =3D 0xdfb97b68 fp =3D 0xdfb97c28 > r4 =3D 0xdb43ab76 r5 =3D 0xdb43ab5e > r6 =3D 0x00000000 r7 =3D 0xdb43ab66 > ip6_input() at ip6_input+0xd38 > pc =3D 0xc04f9030 lr =3D 0xc046d66c (netisr_dispatch_src+0xf8) > sp =3D 0xdfb97c30 fp =3D 0xdfb97c58 > r4 =3D 0xdb43ab00 r5 =3D 0x00000006 > r6 =3D 0x00000007 r7 =3D 0xc0b49d50 > r8 =3D 0xdafea0c0 r9 =3D 0xdb43ab00 > r10 =3D 0x00000086 > netisr_dispatch_src() at netisr_dispatch_src+0xf8 > pc =3D 0xc046d66c lr =3D 0xc04641b0 (ether_demux+0x18c) > sp =3D 0xdfb97c60 fp =3D 0xdfb97c78 > r4 =3D 0x00000006 r5 =3D 0x00001201 > r6 =3D 0xdb132400 r7 =3D 0x000000ff > r8 =3D 0xdafea0c0 r9 =3D 0xdb43ab00 > r10 =3D 0x00000086 > ether_demux() at ether_demux+0x18c > pc =3D 0xc04641b0 lr =3D 0xc0465880 (ether_nh_input+0x490) > sp =3D 0xdfb97c80 fp =3D 0xdfb97ce0 > r4 =3D 0xdb132400 r5 =3D 0xdb43ab00 > r6 =3D 0xdb43ab50 r10 =3D 0x00000086 > ether_nh_input() at ether_nh_input+0x490 > pc =3D 0xc0465880 lr =3D 0xc046d66c (netisr_dispatch_src+0xf8) > sp =3D 0xdfb97ce8 fp =3D 0xdfb97d10 > r4 =3D 0xdb43ab00 r5 =3D 0x00000005 > r6 =3D 0x0000000c r7 =3D 0xc0b49d30 > r8 =3D 0xdafea0c0 r9 =3D 0xdb43ab00 > r10 =3D 0xc098d18f > netisr_dispatch_src() at netisr_dispatch_src+0xf8 > pc =3D 0xc046d66c lr =3D 0xc04645c4 (ether_input+0x50) > sp =3D 0xdfb97d18 fp =3D 0xdfb97d48 > r4 =3D 0xdb43ab00 r5 =3D 0x00000000 > r6 =3D 0x00008803 r7 =3D 0x00000000 > r8 =3D 0xdafea0c0 r9 =3D 0xdb43ab00 > r10 =3D 0xc098d18f > ether_input() at ether_input+0x50 > pc =3D 0xc04645c4 lr =3D 0xdffb3f08 ($a.10+0x108) > sp =3D 0xdfb97d50 fp =3D 0xdfb97d78 > r4 =3D 0xdb132400 r5 =3D 0xdaff8b00 > r6 =3D 0xdaff8b10 r7 =3D 0x00000000 > r8 =3D 0x00000000 r10 =3D 0xc098d18f > $a.10() at $a.10+0x108 > pc =3D 0xdffb3f08 lr =3D 0xc038cb2c (taskqueue_run_locked+0x1c4= ) > sp =3D 0xdfb97d80 fp =3D 0xdfb97dd8 > r4 =3D 0xe0145100 r5 =3D 0xdaff8b2c > r6 =3D 0xe0145150 r7 =3D 0x00000001 > r8 =3D 0x00000000 r9 =3D 0xdfb97d90 > r10 =3D 0x00000001 > taskqueue_run_locked() at taskqueue_run_locked+0x1c4 > pc =3D 0xc038cb2c lr =3D 0xc038e4e4 (taskqueue_thread_loop+0x1b= 0) > sp =3D 0xdfb97de0 fp =3D 0xdfb97e10 > r4 =3D 0xe0145100 r5 =3D 0xe0145140 > r6 =3D 0xc07af4c4 r7 =3D 0x00000000 > r8 =3D 0xc098d18f r9 =3D 0x00000100 > r10 =3D 0xc0b228a0 > taskqueue_thread_loop() at taskqueue_thread_loop+0x1b0 > pc =3D 0xc038e4e4 lr =3D 0xc02cdf0c (fork_exit+0xc0) > sp =3D 0xdfb97e18 fp =3D 0xdfb97e38 > r4 =3D 0xdfedd000 r5 =3D 0xc0b224e0 > r6 =3D 0xc038e334 r7 =3D 0xdffc4f54 > r8 =3D 0xdfb97e40 r9 =3D 0xc098d191 > fork_exit() at fork_exit+0xc0 > pc =3D 0xc02cdf0c lr =3D 0xc0661c5c (swi_exit) > sp =3D 0xdfb97e40 fp =3D 0x00000000 > r4 =3D 0xc038e334 r5 =3D 0xdffc4f54 > r6 =3D 0xc0b45d84 r7 =3D 0xd73bcba0 > r8 =3D 0x00000001 r10 =3D 0xc0b228a0 > swi_exit() at swi_exit > pc =3D 0xc0661c5c lr =3D 0xc0661c5c (swi_exit) > sp =3D 0xdfb97e40 fp =3D 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. > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > > --000000000000821b9706022508cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It might make sense to work up a patch that skips thi= s test on armv7 after filing a bug (the usual way)....

=
Warner

On Fri, Aug 4, 2023 at 12:59=E2=80=AFAM Mark Millard &= lt;marklmi@yahoo.com> wrote:
While discovered v= ia 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=C2=A0 ->=C2=A0 Fatal kernel mode data abort: = 'Alignment Fault' on read
trapframe: 0xdfb97aa0
FSR=3D00000001, FAR=3Ddb43ab76, spsr=3D60000013
r0 =3Ddfedd000, r1 =3Ddfb97b34, r2 =3D00000000, r3 =3D00000000
r4 =3D00000000, r5 =3D00000000, r6 =3Ddb43ab76, r7 =3Ddb43ab66
r8 =3Dc096383c, r9 =3D00000000, r10=3Ddb132400, r11=3Ddfb97b60
r12=3D00000000, ssp=3Ddfb97b30, slr=3Dc0b4e2c0, pc =3Dc04e6b70

panic: Fatal abort
cpuid =3D 0
time =3D 1691131498
KDB: stack backtrace:
db_trace_self() at db_trace_self
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc =3D 0xc065f414=C2=A0 lr =3D 0xc007db80= (db_trace_self_wrapper+0x30)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sp =3D 0xdfb97858=C2=A0 fp =3D 0xdfb97970=
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc =3D 0xc007db80=C2=A0 lr =3D 0xc031a834= (vpanic+0x140)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sp =3D 0xdfb97978=C2=A0 fp =3D 0xdfb97998=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r4 =3D 0x00000100=C2=A0 r5 =3D 0x00000000=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r6 =3D 0xc07c369a=C2=A0 r7 =3D 0xc0b32e58=
vpanic() at vpanic+0x140
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc =3D 0xc031a834=C2=A0 lr =3D 0xc031a6f4= (vpanic)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sp =3D 0xdfb979a0=C2=A0 fp =3D 0xdfb979a4=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r4 =3D 0xdfb97aa0=C2=A0 r5 =3D 0x00000013=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r6 =3D 0xdb43ab76=C2=A0 r7 =3D 0x00000001=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r8 =3D 0x00000001=C2=A0 r9 =3D 0xdfedd000=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 r10 =3D 0xdb43ab76
vpanic() at vpanic
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc =3D 0xc031a6f4=C2=A0 lr =3D 0xc06849dc= (abort_align)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sp =3D 0xdfb979ac=C2=A0 fp =3D 0xdfb979d8=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r4 =3D 0x00000001=C2=A0 r5 =3D 0x00000001=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r6 =3D 0xdfedd000=C2=A0 r7 =3D 0xdb43ab76=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r8 =3D 0xdfb979a4=C2=A0 r9 =3D 0xc031a6f4=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 r10 =3D 0xdfb979ac
abort_align() at abort_align
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc =3D 0xc06849dc=C2=A0 lr =3D 0xc0684a50= (abort_align+0x74)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sp =3D 0xdfb979e0=C2=A0 fp =3D 0xdfb979f8=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r4 =3D 0x00000013 r10 =3D 0xdb43ab76
abort_align() at abort_align+0x74
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc =3D 0xc0684a50=C2=A0 lr =3D 0xc06846a8= (abort_handler+0x45c)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sp =3D 0xdfb97a00=C2=A0 fp =3D 0xdfb97a98=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r4 =3D 0x00000000 r10 =3D 0xdb43ab76
abort_handler() at abort_handler+0x45c
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc =3D 0xc06846a8=C2=A0 lr =3D 0xc0661cc8= (exception_exit)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sp =3D 0xdfb97aa0=C2=A0 fp =3D 0xdfb97b60=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r4 =3D 0x00000000=C2=A0 r5 =3D 0x00000000=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r6 =3D 0xdb43ab76=C2=A0 r7 =3D 0xdb43ab66=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r8 =3D 0xc096383c=C2=A0 r9 =3D 0x00000000=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 r10 =3D 0xdb132400
exception_exit() at exception_exit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc =3D 0xc0661cc8=C2=A0 lr =3D 0xc0b4e2c0= (__pcpu)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sp =3D 0xdfb97b30=C2=A0 fp =3D 0xdfb97b60=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r0 =3D 0xdfedd000=C2=A0 r1 =3D 0xdfb97b34=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r2 =3D 0x00000000=C2=A0 r3 =3D 0x00000000=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r4 =3D 0x00000000=C2=A0 r5 =3D 0x00000000=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r6 =3D 0xdb43ab76=C2=A0 r7 =3D 0xdb43ab66=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r8 =3D 0xc096383c=C2=A0 r9 =3D 0x00000000=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 r10 =3D 0xdb132400 r12 =3D 0x00000000
in6ifa_ifwithaddr() at in6ifa_ifwithaddr+0x30
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc =3D 0xc04e6b70=C2=A0 lr =3D 0xc04f9030= (ip6_input+0xd38)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sp =3D 0xdfb97b68=C2=A0 fp =3D 0xdfb97c28=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r4 =3D 0xdb43ab76=C2=A0 r5 =3D 0xdb43ab5e=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r6 =3D 0x00000000=C2=A0 r7 =3D 0xdb43ab66=
ip6_input() at ip6_input+0xd38
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc =3D 0xc04f9030=C2=A0 lr =3D 0xc046d66c= (netisr_dispatch_src+0xf8)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sp =3D 0xdfb97c30=C2=A0 fp =3D 0xdfb97c58=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r4 =3D 0xdb43ab00=C2=A0 r5 =3D 0x00000006=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r6 =3D 0x00000007=C2=A0 r7 =3D 0xc0b49d50=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r8 =3D 0xdafea0c0=C2=A0 r9 =3D 0xdb43ab00=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 r10 =3D 0x00000086
netisr_dispatch_src() at netisr_dispatch_src+0xf8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc =3D 0xc046d66c=C2=A0 lr =3D 0xc04641b0= (ether_demux+0x18c)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sp =3D 0xdfb97c60=C2=A0 fp =3D 0xdfb97c78=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r4 =3D 0x00000006=C2=A0 r5 =3D 0x00001201=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r6 =3D 0xdb132400=C2=A0 r7 =3D 0x000000ff=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r8 =3D 0xdafea0c0=C2=A0 r9 =3D 0xdb43ab00=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 r10 =3D 0x00000086
ether_demux() at ether_demux+0x18c
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc =3D 0xc04641b0=C2=A0 lr =3D 0xc0465880= (ether_nh_input+0x490)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sp =3D 0xdfb97c80=C2=A0 fp =3D 0xdfb97ce0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r4 =3D 0xdb132400=C2=A0 r5 =3D 0xdb43ab00=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r6 =3D 0xdb43ab50 r10 =3D 0x00000086
ether_nh_input() at ether_nh_input+0x490
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc =3D 0xc0465880=C2=A0 lr =3D 0xc046d66c= (netisr_dispatch_src+0xf8)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sp =3D 0xdfb97ce8=C2=A0 fp =3D 0xdfb97d10=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r4 =3D 0xdb43ab00=C2=A0 r5 =3D 0x00000005=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r6 =3D 0x0000000c=C2=A0 r7 =3D 0xc0b49d30=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r8 =3D 0xdafea0c0=C2=A0 r9 =3D 0xdb43ab00=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 r10 =3D 0xc098d18f
netisr_dispatch_src() at netisr_dispatch_src+0xf8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc =3D 0xc046d66c=C2=A0 lr =3D 0xc04645c4= (ether_input+0x50)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sp =3D 0xdfb97d18=C2=A0 fp =3D 0xdfb97d48=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r4 =3D 0xdb43ab00=C2=A0 r5 =3D 0x00000000=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r6 =3D 0x00008803=C2=A0 r7 =3D 0x00000000=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r8 =3D 0xdafea0c0=C2=A0 r9 =3D 0xdb43ab00=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 r10 =3D 0xc098d18f
ether_input() at ether_input+0x50
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc =3D 0xc04645c4=C2=A0 lr =3D 0xdffb3f08= ($a.10+0x108)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sp =3D 0xdfb97d50=C2=A0 fp =3D 0xdfb97d78=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r4 =3D 0xdb132400=C2=A0 r5 =3D 0xdaff8b00=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r6 =3D 0xdaff8b10=C2=A0 r7 =3D 0x00000000=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r8 =3D 0x00000000 r10 =3D 0xc098d18f
$a.10() at $a.10+0x108
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc =3D 0xdffb3f08=C2=A0 lr =3D 0xc038cb2c= (taskqueue_run_locked+0x1c4)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sp =3D 0xdfb97d80=C2=A0 fp =3D 0xdfb97dd8=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r4 =3D 0xe0145100=C2=A0 r5 =3D 0xdaff8b2c=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r6 =3D 0xe0145150=C2=A0 r7 =3D 0x00000001=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r8 =3D 0x00000000=C2=A0 r9 =3D 0xdfb97d90=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 r10 =3D 0x00000001
taskqueue_run_locked() at taskqueue_run_locked+0x1c4
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc =3D 0xc038cb2c=C2=A0 lr =3D 0xc038e4e4= (taskqueue_thread_loop+0x1b0)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sp =3D 0xdfb97de0=C2=A0 fp =3D 0xdfb97e10=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r4 =3D 0xe0145100=C2=A0 r5 =3D 0xe0145140=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r6 =3D 0xc07af4c4=C2=A0 r7 =3D 0x00000000=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r8 =3D 0xc098d18f=C2=A0 r9 =3D 0x00000100=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 r10 =3D 0xc0b228a0
taskqueue_thread_loop() at taskqueue_thread_loop+0x1b0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc =3D 0xc038e4e4=C2=A0 lr =3D 0xc02cdf0c= (fork_exit+0xc0)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sp =3D 0xdfb97e18=C2=A0 fp =3D 0xdfb97e38=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r4 =3D 0xdfedd000=C2=A0 r5 =3D 0xc0b224e0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r6 =3D 0xc038e334=C2=A0 r7 =3D 0xdffc4f54=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r8 =3D 0xdfb97e40=C2=A0 r9 =3D 0xc098d191=
fork_exit() at fork_exit+0xc0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc =3D 0xc02cdf0c=C2=A0 lr =3D 0xc0661c5c= (swi_exit)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sp =3D 0xdfb97e40=C2=A0 fp =3D 0x00000000=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r4 =3D 0xc038e334=C2=A0 r5 =3D 0xdffc4f54=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r6 =3D 0xc0b45d84=C2=A0 r7 =3D 0xd73bcba0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r8 =3D 0x00000001 r10 =3D 0xc0b228a0
swi_exit() at swi_exit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc =3D 0xc0661c5c=C2=A0 lr =3D 0xc0661c5c= (swi_exit)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sp =3D 0xdfb97e40=C2=A0 fp =3D 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=C2=A0 =C2=A0 = =C2=A0root@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.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


--000000000000821b9706022508cc-- From nobody Sat Aug 5 06:11:54 2023 X-Original-To: freebsd-current@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 4RHsgG1cVbz4phZZ for ; Sat, 5 Aug 2023 06:12:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (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 4RHsgF2xM4z4Zhs for ; Sat, 5 Aug 2023 06:12:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691215925; bh=SWQR1BKsKW4CgTizL4WB+Ys2F8WLEkQlPWF4CjWU0+8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=PYTAkrglt36YjqU81uk0I6IsViVBF7FGJesufBL75WRE++9tdgViWVDof2PEwlm3aJtX6Y2tC9xz7ftyKVddhjTZSCHiJr+QMA4NtJZyQy0OE5h/AKIVtMAIPOQmUzYaHekgBb2+CeQX/C/jhYpu/ayFG8RzofSGVjSxAzs5xuKkwEbvuh1/hMjoEdSPLSDi8SantlhDVZ/0hXzRIfRf2lY6Dj+645763UFVVHjzqRazanKS6coWRqNLOs4GzH/9gI+87F89O6zKHl0gZrsrOepQFiVGiPvsU7gYpa9gxAoUEDjueDmMMezLIakn3/FLmd3kPupiyq82NeDLJMqcng== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691215925; bh=VHa8pZjL55f6Q9miCSWZQgWZe0pMsZfAFYnpHj94yV0=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=AzsGcvS71RgL2+jgxDfgDSIH23DpcYsW+IEQiQYPUQrWKuhVTF2OaX98Ve3jIBoeomFz60E7iDMrdRDthBMzzf7X7ZJH6Sw9YkUdB1wsMhoe04TFlJp1jyq0Hz/9QAz+7DDHMixxDTB8dZ38NcoGu9zwxFztD7PXCQWeAzkZHW3zZf1cJs0jw42q1MqCRWjVOnSeNijl/vJpHxSVWMS03VLuvCUHGSh/hIk+D9giUvqhzN3uykwdn3gdJpbH04NhWEG5wu6oa6rkdPlGvnxPVZTvYYo1dEm83clTQpqowz70PGfvFrwq8Nd0Ju0+f9QiOxiCyG47BhII/i6Dhp61LA== X-YMail-OSG: DtJHXHsVM1lPuTPShjoziHlEsNypvQVSKxvmd.AdpB3.6Nb8C0hmBOxt04Aipxe 3.H._XJ3w2gKHMq9Fvmv4PZbqs39zj7LdFQMFhMMK0Ap9wjDskVQe6v..XyyvP8267wimIfCN38V 3EfVHOMa.y3Noy377jdHhYor.KTli_oUmN6cZcvnDGYf3VvZQp0UDFrrForHDeXKjn9t8HVMzams K3cZlyetS8ISl9sPyPVRJL9H3iSy1Zp9JSWckex82GzWa4PfDNXOENAKh6HpzShRBbmuA9kAcfNE eNTeTlHfBjpJWkqG0J4mDq6kPEdqfKZ5oWohVlBb8EXvXrPke8ndIQU98QIg.vd5eJKWA9iekNq5 _tzXOnKVVYXlxVRYrElGDjXryrFvD_p4rabNCXUSVya4gjr2.9AqTqvkETm4XNksi5ksdjX3sa7V BVGZa48NJh.BYQ34TWn3efEL2VuUvzMDfrBUmOxxmNmHBQX6hP_c9EDIZD0WgEBmVDFvmy7t6sNj MLnojQqHloyvJX0AE.FCuHEcHcd71NJFonqEH5DeXZSPKAS_yFGUi_BSVF6AEemj56pD8cTqW6WA 1vWcC0vPMd.W5fZoqNhTkeidpmfh8S1HivevoMMVOTMLtOK.DzFoOEk6tUUC4lcN8oBn87bq9ylo vXaAJ7re_ydGmSBoDeQCimJULy.OsgtJS.65KykquN9tE0uqy3ts2GE5w8pqCJj2rOl2L1C4dfvw 0D1MaDFBAuF4JeWyWupm85ATqbbKGs8lYCdER3yICQIk4C7VHJMMo502K36tfcuE6DXNGvxChSfT RpHdU9z6q_hzUHEViuw.fRyyN4h5Z4r91bXxkg68Gb2nquKpP1FFSiVGPaOC1itn1FDpjLP6jJE9 1QD48m_aO7FPQonl7ufufQiyQVn6vQGO0DJd6FyeLtCaw1yrXzwsqG8GBgSvtBImi0FePmxjVwWC rBY8BWcw_Idb23IhnYZt_N4SJh9LGufCZOlnXHOcgCnTW1RDfSyamaHWCIVbe_3EiYIaOREHUnvH qibt4B5_3ocVBwNTkfDJNyuuOZA15QAAOC5BeFlydo7fh9j_t.XeAZrDpqZmSkJ5qvBpmH1taAT8 n8KxLY81bR2MII1G9VRch2qcnTOY0cSeTL0o_uUpttkIRaf1.GuQftnZm4SM.oViKgW6wgFkGHDu aXfVAX3KArAt9POl5JjF2htvnr6NiRBdMkeNLDLXRld9UYDxHa_al3CpPsxUdEwONd.cnH6mQvlg LUmYUFb0UXl6z0WulQDTmUNrDyT80Pzxd0rmAyLhQg381dQjjwQR_y5r5cQ8MXi6hgvTHj5Q6Kmc r1jThXVYNIC_623v9fz_rpmO.bvquSk8VXBPvdXYGKfX0SxFr9Sz1XiVN9JyrPnSnO6dFjXgoMTt FdXAah4KlWLBwQLBqX3zYMPk87CXYeV6l46wpmp20HqqV_W1QFPazD17q9sRnY0h5BztZ_RTlnVr Kqxt95jt4.GW7ZtwPAgu7REgOrYunGPayyVzrlDnrFcMduaZr597CAlSfdcFa5pJYSDPphVLjsAx UrbekCLdGsbRdnZyMh50CGoCROtumUl955tQfLZxEQVZCf3VjGUtpjyS.Fjzta.o_kyb6.__PiMb BGt0nlq5efn3ucbJfiMJjdclKxwMpiwpS3VHWUqpwQIF0NPZZ5U_8yQTFruOwzEonNNreO35xg5I Adnd_s5wd.PfreRHDTE9BvR9656uEKc5VdVHN0Q3l_GEa7b91svK8mdXiGzXgY5AlQ5dWkc01fdz Etn.Yi_l5Ur43nvqkLGcI4Yuwqf48AqRi1kwCL6eoL_rue05sBl84miL8hGHGujHp1Hf1QxZFl86 xYYh8rTy_mJkeQZ7YWFnBaUq.hEId1N3j00gThubuT1WCDSgh7AQMk7ESQjH4UW_XeRyRYbGunN8 vAP7BKJojmkxY9MAtyOWpvVB8tT2ta6hESxGTzwelCXlq6d0lldfZs5bNzLtNlkDom1J6WPJqtNF Wn3WhlWtUYpsKj8bSogVfiDZmP4_dmkLlMZnNzeggP5vUqilxk5iX4JE3JsBLIuSPyLA3Q7Yox3_ S_CwdEi8kEfFg.WwsV2fEZ.jrvWPUxEw83ZosLwn6hftnzx7.hxKuUVXY.o7Qd_emGn0gyWlaBhF wPSiVlUBubetJv19zIcltn360qztjTGDQkfKR.k0WZagZW.TN0FYUsBfxrBHH.leOX5uUZT7Evyg fnC3941m3q03KCUtL4r9tuPBUGSOuaa8gWTcDJs75hVpMEy1dSWesSTwMJ30AjQl10NYfvuAhtt8 F X-Sonic-MF: X-Sonic-ID: 841b9743-540d-446b-8bb8-4ef92198e062 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Aug 2023 06:12:05 +0000 Received: by hermes--production-gq1-7d844d8954-psjqr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 68d446670156984f7b813f8ee2519236; Sat, 05 Aug 2023 06:12:05 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@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: Date: Fri, 4 Aug 2023 23:11:54 -0700 Cc: FreeBSD ARM List , Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warner Losh X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RHsgF2xM4z4Zhs X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] 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).... >=20 > 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=3D271759 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=E2=80=AFAM Mark Millard = wrote: > While discovered via an attempted overall kyua run, the following is > sufficient to get the crash in my native armv7 context: >=20 > # /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=3D00000001, FAR=3Ddb43ab76, spsr=3D60000013 > r0 =3Ddfedd000, r1 =3Ddfb97b34, r2 =3D00000000, r3 =3D00000000 > r4 =3D00000000, r5 =3D00000000, r6 =3Ddb43ab76, r7 =3Ddb43ab66 > r8 =3Dc096383c, r9 =3D00000000, r10=3Ddb132400, r11=3Ddfb97b60 > r12=3D00000000, ssp=3Ddfb97b30, slr=3Dc0b4e2c0, pc =3Dc04e6b70 >=20 > panic: Fatal abort > cpuid =3D 0 > time =3D 1691131498 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc =3D 0xc065f414 lr =3D 0xc007db80 = (db_trace_self_wrapper+0x30) > sp =3D 0xdfb97858 fp =3D 0xdfb97970 > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc =3D 0xc007db80 lr =3D 0xc031a834 (vpanic+0x140) > sp =3D 0xdfb97978 fp =3D 0xdfb97998 > r4 =3D 0x00000100 r5 =3D 0x00000000 > r6 =3D 0xc07c369a r7 =3D 0xc0b32e58 > vpanic() at vpanic+0x140 > pc =3D 0xc031a834 lr =3D 0xc031a6f4 (vpanic) > sp =3D 0xdfb979a0 fp =3D 0xdfb979a4 > r4 =3D 0xdfb97aa0 r5 =3D 0x00000013 > r6 =3D 0xdb43ab76 r7 =3D 0x00000001 > r8 =3D 0x00000001 r9 =3D 0xdfedd000 > r10 =3D 0xdb43ab76 > vpanic() at vpanic > pc =3D 0xc031a6f4 lr =3D 0xc06849dc (abort_align) > sp =3D 0xdfb979ac fp =3D 0xdfb979d8 > r4 =3D 0x00000001 r5 =3D 0x00000001 > r6 =3D 0xdfedd000 r7 =3D 0xdb43ab76 > r8 =3D 0xdfb979a4 r9 =3D 0xc031a6f4 > r10 =3D 0xdfb979ac > abort_align() at abort_align > pc =3D 0xc06849dc lr =3D 0xc0684a50 (abort_align+0x74) > sp =3D 0xdfb979e0 fp =3D 0xdfb979f8 > r4 =3D 0x00000013 r10 =3D 0xdb43ab76 > abort_align() at abort_align+0x74 > pc =3D 0xc0684a50 lr =3D 0xc06846a8 (abort_handler+0x45c) > sp =3D 0xdfb97a00 fp =3D 0xdfb97a98 > r4 =3D 0x00000000 r10 =3D 0xdb43ab76 > abort_handler() at abort_handler+0x45c > pc =3D 0xc06846a8 lr =3D 0xc0661cc8 (exception_exit) > sp =3D 0xdfb97aa0 fp =3D 0xdfb97b60 > r4 =3D 0x00000000 r5 =3D 0x00000000 > r6 =3D 0xdb43ab76 r7 =3D 0xdb43ab66 > r8 =3D 0xc096383c r9 =3D 0x00000000 > r10 =3D 0xdb132400 > exception_exit() at exception_exit > pc =3D 0xc0661cc8 lr =3D 0xc0b4e2c0 (__pcpu) > sp =3D 0xdfb97b30 fp =3D 0xdfb97b60 > r0 =3D 0xdfedd000 r1 =3D 0xdfb97b34 > r2 =3D 0x00000000 r3 =3D 0x00000000 > r4 =3D 0x00000000 r5 =3D 0x00000000 > r6 =3D 0xdb43ab76 r7 =3D 0xdb43ab66 > r8 =3D 0xc096383c r9 =3D 0x00000000 > r10 =3D 0xdb132400 r12 =3D 0x00000000 > in6ifa_ifwithaddr() at in6ifa_ifwithaddr+0x30 > pc =3D 0xc04e6b70 lr =3D 0xc04f9030 (ip6_input+0xd38) > sp =3D 0xdfb97b68 fp =3D 0xdfb97c28 > r4 =3D 0xdb43ab76 r5 =3D 0xdb43ab5e > r6 =3D 0x00000000 r7 =3D 0xdb43ab66 > ip6_input() at ip6_input+0xd38 > pc =3D 0xc04f9030 lr =3D 0xc046d66c = (netisr_dispatch_src+0xf8) > sp =3D 0xdfb97c30 fp =3D 0xdfb97c58 > r4 =3D 0xdb43ab00 r5 =3D 0x00000006 > r6 =3D 0x00000007 r7 =3D 0xc0b49d50 > r8 =3D 0xdafea0c0 r9 =3D 0xdb43ab00 > r10 =3D 0x00000086 > netisr_dispatch_src() at netisr_dispatch_src+0xf8 > pc =3D 0xc046d66c lr =3D 0xc04641b0 (ether_demux+0x18c) > sp =3D 0xdfb97c60 fp =3D 0xdfb97c78 > r4 =3D 0x00000006 r5 =3D 0x00001201 > r6 =3D 0xdb132400 r7 =3D 0x000000ff > r8 =3D 0xdafea0c0 r9 =3D 0xdb43ab00 > r10 =3D 0x00000086 > ether_demux() at ether_demux+0x18c > pc =3D 0xc04641b0 lr =3D 0xc0465880 (ether_nh_input+0x490) > sp =3D 0xdfb97c80 fp =3D 0xdfb97ce0 > r4 =3D 0xdb132400 r5 =3D 0xdb43ab00 > r6 =3D 0xdb43ab50 r10 =3D 0x00000086 > ether_nh_input() at ether_nh_input+0x490 > pc =3D 0xc0465880 lr =3D 0xc046d66c = (netisr_dispatch_src+0xf8) > sp =3D 0xdfb97ce8 fp =3D 0xdfb97d10 > r4 =3D 0xdb43ab00 r5 =3D 0x00000005 > r6 =3D 0x0000000c r7 =3D 0xc0b49d30 > r8 =3D 0xdafea0c0 r9 =3D 0xdb43ab00 > r10 =3D 0xc098d18f > netisr_dispatch_src() at netisr_dispatch_src+0xf8 > pc =3D 0xc046d66c lr =3D 0xc04645c4 (ether_input+0x50) > sp =3D 0xdfb97d18 fp =3D 0xdfb97d48 > r4 =3D 0xdb43ab00 r5 =3D 0x00000000 > r6 =3D 0x00008803 r7 =3D 0x00000000 > r8 =3D 0xdafea0c0 r9 =3D 0xdb43ab00 > r10 =3D 0xc098d18f > ether_input() at ether_input+0x50 > pc =3D 0xc04645c4 lr =3D 0xdffb3f08 ($a.10+0x108) > sp =3D 0xdfb97d50 fp =3D 0xdfb97d78 > r4 =3D 0xdb132400 r5 =3D 0xdaff8b00 > r6 =3D 0xdaff8b10 r7 =3D 0x00000000 > r8 =3D 0x00000000 r10 =3D 0xc098d18f > $a.10() at $a.10+0x108 > pc =3D 0xdffb3f08 lr =3D 0xc038cb2c = (taskqueue_run_locked+0x1c4) > sp =3D 0xdfb97d80 fp =3D 0xdfb97dd8 > r4 =3D 0xe0145100 r5 =3D 0xdaff8b2c > r6 =3D 0xe0145150 r7 =3D 0x00000001 > r8 =3D 0x00000000 r9 =3D 0xdfb97d90 > r10 =3D 0x00000001 > taskqueue_run_locked() at taskqueue_run_locked+0x1c4 > pc =3D 0xc038cb2c lr =3D 0xc038e4e4 = (taskqueue_thread_loop+0x1b0) > sp =3D 0xdfb97de0 fp =3D 0xdfb97e10 > r4 =3D 0xe0145100 r5 =3D 0xe0145140 > r6 =3D 0xc07af4c4 r7 =3D 0x00000000 > r8 =3D 0xc098d18f r9 =3D 0x00000100 > r10 =3D 0xc0b228a0 > taskqueue_thread_loop() at taskqueue_thread_loop+0x1b0 > pc =3D 0xc038e4e4 lr =3D 0xc02cdf0c (fork_exit+0xc0) > sp =3D 0xdfb97e18 fp =3D 0xdfb97e38 > r4 =3D 0xdfedd000 r5 =3D 0xc0b224e0 > r6 =3D 0xc038e334 r7 =3D 0xdffc4f54 > r8 =3D 0xdfb97e40 r9 =3D 0xc098d191 > fork_exit() at fork_exit+0xc0 > pc =3D 0xc02cdf0c lr =3D 0xc0661c5c (swi_exit) > sp =3D 0xdfb97e40 fp =3D 0x00000000 > r4 =3D 0xc038e334 r5 =3D 0xdffc4f54 > r6 =3D 0xc0b45d84 r7 =3D 0xd73bcba0 > r8 =3D 0x00000001 r10 =3D 0xc0b228a0 > swi_exit() at swi_exit > pc =3D 0xc0661c5c lr =3D 0xc0661c5c (swi_exit) > sp =3D 0xdfb97e40 fp =3D 0x00000000 > KDB: enter: panic > [ thread pid 0 tid 100230 ] >=20 > For reference: >=20 > # 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.a= rmv7/sys/GENERIC-NODBG-CA7 arm armv7 1400093 1400093 >=20 > The OrangePi+ 2Ed was the type of system booted and tested. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Aug 5 07:01:35 2023 X-Original-To: freebsd-current@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 4RHtmP3KR0z4plD9 for ; Sat, 5 Aug 2023 07:01:41 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RHtmN2M7Rz4g8T for ; Sat, 5 Aug 2023 07:01:40 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of guru@unixarea.de designates 178.254.4.101 as permitted sender) smtp.mailfrom=guru@unixarea.de; dmarc=none Received: from [188.174.61.234] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSBI9-0007s1-2y for freebsd-current@freebsd.org; Sat, 05 Aug 2023 09:01:37 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.16.1/8.14.9) with ESMTPS id 37571axi009385 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sat, 5 Aug 2023 09:01:36 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.16.1/8.14.9/Submit) id 37571auB009384 for freebsd-current@freebsd.org; Sat, 5 Aug 2023 09:01:36 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 5 Aug 2023 09:01:35 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: poudriere && git Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.61.234 X-Spamd-Result: default: False [-0.72 / 15.00]; NEURAL_HAM_MEDIUM(-0.95)[-0.955]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:178.254.4.101]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.04)[0.036]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[unixarea.de]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_XOIP(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; HAS_REPLYTO(0.00)[guru@unixarea.de] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4RHtmN2M7Rz4g8T Hello, I'm updating my poudriere build server, not used for some time. I've already fetched /usr/src and /usr/ports from git, compiled world and kernel... In the past I created the jails based on svn, for example with # poudriere jail -c -j freebsd-r368166 -m svn+http -v head@r368166 How this is nowadays done with git? Also the documentation I consulted in https://github.com/freebsd/poudriere/wiki/poudriere.8-devel is more outdated than my buildhost (from Nov 2020) :-) Where could I find a recent tutorial? Thanks matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Sat Aug 5 07:21:02 2023 X-Original-To: freebsd-current@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 4RHvCL33hYz4TkJp for ; Sat, 5 Aug 2023 07:21:34 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx2.enfer-du-nord.net (mx2.enfer-du-nord.net [135.125.211.209]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 4RHvCK6TNfz4jTv for ; Sat, 5 Aug 2023 07:21:33 +0000 (UTC) (envelope-from trashcan@ellael.org) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (p5b2e5613.dip0.t-ipconnect.de [91.46.86.19]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.enfer-du-nord.net (Postfix) with ESMTPSA id 4RHvBw5KX2zPZD; Sat, 5 Aug 2023 09:21:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellael.org; s=dkim; t=1691220077; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PL3U/tSXUUT6fhX/+3MUz4omx4c5yBfdkloYKGtbWhw=; b=rGblBExjuDlFN0ew+/H9e5y2OqxO63d+BWFWFGCqHolUB4WUjZL9BBfmvieAst5BmNi3na LCS0N3hG/mYdDqUQFvs7qckIkk/RVv+hetYb8fqc4KA3JT7XZ9u8LdQvJhNEAsEWHsmW93 WKTJdOoGb6swvkWm8dvmvOnC+7sm55nIAOGd8IpsqWKXCXMzmSveLGGek5LpOHguHd2JaT d0lbp6YQNhUG9RqEQdc7j6KYb+Ya6hmf/aUWkRRz9pKRIoJuiWr9V2w0grlLFC8RV8cIxa SY8Qq2m/djESAhswDkmau47gnjHgm9ofMZac4wRbNrnpJrqXThiwhJuXPkjUlw== Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: poudriere && git From: Michael Grimm In-Reply-To: Date: Sat, 5 Aug 2023 09:21:02 +0200 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Matthias Apitz X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RHvCK6TNfz4jTv X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16276, ipnet:135.125.128.0/17, country:FR] Matthias Apitz wrote: > In the past I created the jails based on svn, for example with >=20 > # poudriere jail -c -j freebsd-r368166 -m svn+http -v head@r368166 Use "-m src=3D/usr/src" instead. It is documented in man poudriere-jail: -m method Specify which method to use to create the jail. = The default is http. Pre-built distribution options: [=E2=80=A6] src=3Dpath Install from the given directory at = path. This directory will not be built = unless -b is given. It is expected that it is already built and maps to a = corresponding /usr/obj directory. HTH and regards, Michael= From nobody Sat Aug 5 08:08:11 2023 X-Original-To: freebsd-current@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 4RHwFM5cDhz4TnmX for ; Sat, 5 Aug 2023 08:08:23 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 4RHwFM0h9Xz4mCM for ; Sat, 5 Aug 2023 08:08:23 +0000 (UTC) (envelope-from pi@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 2001:14f8:200::1 is neither permitted nor denied by domain of pi@freebsd.org) smtp.mailfrom=pi@freebsd.org; dmarc=none Received: from pi by home.opsec.eu with local (Exim 4.95 (FreeBSD)) (envelope-from ) id 1qSCKZ-000NH7-K0 for freebsd-current@freebsd.org; Sat, 05 Aug 2023 10:08:11 +0200 Date: Sat, 5 Aug 2023 10:08:11 +0200 From: Kurt Jaeger To: freebsd-current@freebsd.org Subject: Re: poudriere && git Message-ID: <20230805080811.GA11506@home.opsec.eu> References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [2.00 / 15.00]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_SPAM_SHORT(1.00)[0.997]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; R_DKIM_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12502, ipnet:2001:14f8::/32, country:DE]; RCPT_COUNT_ONE(0.00)[1]; R_SPF_SOFTFAIL(0.00)[~all]; DMARC_NA(0.00)[freebsd.org]; FREEFALL_USER(0.00)[pi]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-Spamd-Bar: + X-Rspamd-Queue-Id: 4RHwFM0h9Xz4mCM Hi! > In the past I created the jails based on svn, for example with > > # poudriere jail -c -j freebsd-r368166 -m svn+http -v head@r368166 I have the src repo in /usr/src, build the host system from that tree and then use: poudriere jail -j head -u -m null -S /usr/src -- pi@opsec.eu +49 171 3101372 Now what ? From nobody Sat Aug 5 11:39:54 2023 X-Original-To: freebsd-current@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 4RJ0xh73Nsz4gwFb for ; Sat, 5 Aug 2023 11:40:08 +0000 (UTC) (envelope-from shuriku@shurik.kiev.ua) Received: from mail.flex-it.com.ua (mail.flex-it.com.ua [193.239.74.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 4RJ0xb2Mfpz3L3f for ; Sat, 5 Aug 2023 11:40:03 +0000 (UTC) (envelope-from shuriku@shurik.kiev.ua) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of shuriku@shurik.kiev.ua designates 193.239.74.7 as permitted sender) smtp.mailfrom=shuriku@shurik.kiev.ua; dmarc=none Received: from 93.183.208.50.ipv4.datagroup.ua ([93.183.208.50] helo=[192.168.200.125]) by mail.flex-it.com.ua with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.96 (FreeBSD)) (envelope-from ) id 1qSFdT-0003hm-0L for freebsd-current@freebsd.org; Sat, 05 Aug 2023 14:39:55 +0300 Message-ID: Date: Sat, 5 Aug 2023 14:39:54 +0300 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: Fwd: Unreliability with DHCP Content-Language: uk-UA To: freebsd-current@freebsd.org References: <62d300c8-2c3e-58fa-334e-23a17962279a@freebsd.org> From: Oleksandr Kryvulia In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ACL-Warn: SPF failed. 93.183.208.50 is not allowed to send mail from shurik.kiev.ua. X-Spamd-Result: default: False [1.41 / 15.00]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; NEURAL_SPAM_SHORT(0.71)[0.710]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:35297, ipnet:193.239.72.0/22, country:UA]; BLOCKLISTDE_FAIL(0.00)[93.183.208.50:query timed out,193.239.74.7:query timed out]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[shurik.kiev.ua]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Spamd-Bar: + X-Rspamd-Queue-Id: 4RJ0xb2Mfpz3L3f 04.08.23 19:07, Graham Perrin пише: > > Can anyone from freebsd-net@ help? > > > -------- Forwarded Message -------- > Subject: Unreliability with DHCP > Date: Sun, 30 Jul 2023 16:17:43 +0100 > From: Graham Perrin > Organisation: FreeBSD > To: FreeBSD CURRENT > > > > 1. Sleep (suspend) whilst connected to one network > > 2. connect to a network elsewhere > > 3. wake (resume). > > Result: > > /etc/resolv.conf frequently contains outdated information. In some > (maybe all) such cases, the IPv4 inet address is outdated; and so on. > > Which /etc/rc.d/ file(s) should I attempt to fix? > > I imagine using the resume keyword, which is currently used by only > one script: > > % rcorder -k resume /etc/rc.d/* > /etc/rc.d/ntpd > % > > > I routinely run the command below to work around the bug (and observe > the states of things) – run _after_ the bug bites. I'd prefer a fix, > to prevent the bites. > > ls /var/run/resolvconf/interfaces/ ; route delete default ; ifconfig > wlan0 down && ifconfig em0 down && sleep 5 ; ls > /var/run/resolvconf/interfaces/ ; ifconfig em0 up && sleep 15 > ; ls /var/run/resolvconf/interfaces/ ; cat /etc/resolv.conf ; ping -c > 2 -4 freshports.org > As dirty workaround I have in my /etc/rc.resume service netif restart service routing restart From nobody Sat Aug 5 22:16:05 2023 X-Original-To: freebsd-current@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 4RJH3b27Qkz4TptD for ; Sat, 5 Aug 2023 22:16:11 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RJH3b1czKz3TKY for ; Sat, 5 Aug 2023 22:16:11 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691273771; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MwMYmJ8hSeEDBrsCVCAlNkTBLkf5tg859vbw/Trn2YY=; b=jVKLA8WMTkqCQ4kFufaQMGMAkmIj9FTSS7sicPgQN5ee/6coQkG6X/ZrhGMEmh42b6S49J D2IaajQi2SsoG4orb1v6ZbVa8ViHMvxFXwhfSwm18zJZO0IkxBp66L4Btyo4GgobEn+vQ9 ARNTh4RVMLkOYqFfEqfB+MBu+EUOovlQwD2xnN4WbFLtADmmK04GEIWFHuWYeL0HN4NVoO WZ2PLWQVX1o9nzmU0dnxzKjbFSw2PUUI3pLoXh2/BviJAtX+Oh0XDkPapz0YzbLEMM8J9o lq6GsXVKjUTGGtTl/Jr7SmekR0fOzBgo+TO4Dwa7bUQPC/s4nYr7aYbv1kz4qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691273771; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MwMYmJ8hSeEDBrsCVCAlNkTBLkf5tg859vbw/Trn2YY=; b=wsBpC/5tEiof72ak8b0le3ph3gIKpA7XkXfSn++9GZB/yC8tTFLZKs1JvQRdn7gbVdu3Em ISqXTeAPe3mkTL3lLAW1zHhKzuUeKO58+oAqOnb0IS6myCVf1+nk0ng2HfHLvOWH3lWIXz hJigWWkYHW+ZClBUzze4Bhbh6MZ71nzBQuFwsGs4enGz+9dbpzzMrJkFmqjQp8suLTHuck C3rXhAI29LY1vyfNd62PNSzx5SdiqrsyM7qMlC4qPWDs00vJ/0ZuJIelNMltjwsC8/2P6I EzHp8hBh+LPCnsEXqPV55SdHS9TgOOHDZqbgPv5kjNKYMS4GUSbx/aLkHBxSiA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691273771; a=rsa-sha256; cv=none; b=V0poOaVBHSPJT7acA00Thx3YmY2Qmdo5iosqYTNsoDyoy+0F89EJlcS4LcRwoy0HadTq1+ nEM9Fp0mbZMHoVK348bglDGmFlNYyHoyQjIcOc54tl13DtSYrXk1fv1F9LLj/dgkkejR6F H+/WLRC5m42dIu9evRL2cnXJJ3J/lkNAwnbi0q0Z4Dz5e1ubrZJ98oKoULbMVbu1bJv38k gvyWwy5Hi+iY1xPxy4OJaugcrmnmtL9Pp4+XaX6Yi4HhXkOzemgaxI8wyXFkOOW4PxX4bx TfcsyP/yf7P1OUKB4zk21fz20U245Hs66WPUCSyNloEp2JxtRPfXxPtMuclJnA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: grahamperrin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RJH3Z6Vgzz1dlm for ; Sat, 5 Aug 2023 22:16:10 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Message-ID: <753f3990-9903-3718-445c-49fc01f960a7@freebsd.org> Date: Sat, 5 Aug 2023 23:16:05 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.13.1 Content-Language: en-US To: freebsd-current@freebsd.org References: <62d300c8-2c3e-58fa-334e-23a17962279a@freebsd.org> From: Graham Perrin Subject: Re: Fwd: Unreliability with DHCP Organization: FreeBSD In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 05/08/2023 12:39, Oleksandr Kryvulia wrote: > 04.08.23 19:07, Graham Perrin пише: >> >> Can anyone from freebsd-net@ help? >> >> >> -------- Forwarded Message -------- >> Subject:     Unreliability with DHCP >> Date:     Sun, 30 Jul 2023 16:17:43 +0100 >> From:     Graham Perrin >> Organisation:     FreeBSD >> To:     FreeBSD CURRENT >> >> >> >> 1. Sleep (suspend) whilst connected to one network >> >> 2. connect to a network elsewhere >> >> 3. wake (resume). >> >> Result: >> >> /etc/resolv.conf frequently contains outdated information. In some >> (maybe all) such cases, the IPv4 inet address is outdated; and so on. >> >> Which /etc/rc.d/ file(s) should I attempt to fix? >> >> I imagine using the resume keyword, which is currently used by only >> one script: >> >> % rcorder -k resume /etc/rc.d/* >> /etc/rc.d/ntpd >> % >> >> >> I routinely run the command below to work around the bug (and observe >> the states of things) – run _after_ the bug bites. I'd prefer a fix, >> to prevent the bites. >> >> ls /var/run/resolvconf/interfaces/ ; route delete default ; ifconfig >> wlan0 down && ifconfig em0 down && sleep 5 ; ls >> /var/run/resolvconf/interfaces/ ; ifconfig em0 up && sleep 15 >> ; ls /var/run/resolvconf/interfaces/ ; cat /etc/resolv.conf ; ping -c >> 2 -4 freshports.org >> > > > As dirty workaround I have in my /etc/rc.resume > > service netif restart > service routing restart Thanks, I'll try when I'm next on campus. I do know that 'service routing restart' can be problematic. Please, see, for example, ; I had something similar a few minutes ago.