From nobody Mon Jul 22 16:26:14 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WSQdh5cfkz5RDff for ; Mon, 22 Jul 2024 16:26:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.31]) (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 4WSQdh2ryrz43w9 for ; Mon, 22 Jul 2024 16:26:32 +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=1721665590; bh=D6nZ/hxGdoQq2bADSUPeKnuhwvQTt8AHNPL4Ld8+HEU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=X7iNHw5m/o6EBR/ntkxb+qknLEqNOdO/AnNgdAjnecPUymhqCXTOkwoY0OnK6mLfZezKk45K1aSGX2HO7JahNYnQOGgz+jVUajJo87S8QIl+c4Es6nlSuzqTMkElG4IM3b9bsg+sY9c7K3ii2rgGXvp0ZAFnWZpeUaLq+xDDr659GPiytdj8VWxkjXwWUIqeFPLdVKEsv3bL8ux/5D02LIGROYllr0/SkO9bAhd071WlGFef6sSQDTPWhw/OZyfb5Q6iQcZJw+21m8l9MAHe4KD8L7o8Ql+mu2j0DzYof0mOSWeXD6oX18415BJXV26xgda7GA34fvEbCsXvbb2I5g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721665590; bh=ReH5nAtWY1k6Gap8+NhU8KrviyFgjAG90FWJo7Frdrt=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=J9ce6WCbh0cX8YLvGa9N2uRlEvLCvstbaG84ZvQc5yJoOgmTCbe1G8jlOfw/kU2MMI7EOUkLbWB90iujrkDlSfM0/XuYu8VFjjuGxHxfQElhrBuowdNEmi7Q3ul2DVrqn+k6wu8IR5o6LnEWQNLDRktrPCcYm541Noweb23opPTUgAL2FolYOmOWXsjnwy9hMuHWWV1E3dovIaekGDJBZBz+Xs4eWc/rBb6vfEDmJG6JJGIgkkSXCqoEyHi2/NVag8OCDPBmhrE9MQdYaKyYlbd8kObwVuvrV8lAyO3VHyrFDEktQWjK+KchxuDcQHv9V+62IXc8KT9S9Bbw5XS+Og== X-YMail-OSG: BPrGsMQVM1mdrgLgCi.301nVjX9VcELozFCwY_dr2j6c7eQH5DI1HFt9MdkEJMC FGgoRweIP4bdORbUv06TqZ3P7CLuytOXkWB68uEaCO22ZI.5gJbpJ6hDJ4J6soHm1eH2FBN0ccim UYOgzl1SN25TgIwR.BBjQKPUFJnCJzJiR_QIwS0c0vI81CsHGNHkOOBdZ5bADvTeEzoljfGj4KsZ LY7nZMUjBc.MWJ7bby6KXYjHIUgh951b6CcFQ23SAXRlqcDNVBVyK4XdCas8hU2ee.JRv8LskU.k m57SY4V.l0eVKrqAcsLOO9Jt6VFt8mgGDc6ZatjK2hIe0vkjrKDfsKuyGONlCoKwmi.5ve5YROtb yX62t6qfL1DvFOXg3_PEvIqe9wy_K5aHHnvkXkZVe5MGLg5i5c4vON39NSObwNGoLaffEeVOJiJh G.rEIsP_UnAsMnujLGgCNxD.GF10UIeQV8Zs4iWZF4Q2_80ioK6iw4Nba2Lar8EXeFwnEjuJCQ3K 3rIjegusWYPEqLOG9ZfUCLwaz20mIhtXh_LWh.i.xbIRi6R2caoZdzWod6sxY7akWuyQjA7xO1So KloGMZilQNVIwbZUVX8mskDj1a.Te0ANvJKLbDf.f3tn3IZwew._Soump2_Qxv8_xcFyfTcSyUEo w6HL8kGJRJnOCXcG3ioiHLaLbAWVwmWyrtAqgesWq1EPPVBm18aClOVZVY6zgVDIAJ387aYhu1MF 6.GLxDBVrQzws9rb6wPBnq8ghUThNJsAjrOU51Pp_QfE6XAZhv8l6fOhtVRfMbGcU9aBLbJD8GIe L90i.Fc0Qq8deYsBeYS1RqaxyZE2j0Q7Q5C6.TnLUfJ1iv.gKAF0Nz2BmOoKBjjQ7WpljJenRNO3 NSrTfYJXI5lHiLz4wTg2j3.uRLFd1G4FvrUG38B4awQ7zdVxgg5nMMi68KV1nsYwljcyQ5RwOrC5 WV7ArTYTYmD1uAGcqqMgr3oO4ofKdq194Uss6mZ1kV9c82u4xQ8.oaF4SSIUJESvrZuxDiaq.vRm xmta3.YfNudtZfykIG_OlbisBafOIkmBDuv6S8c5Qzm0TTxblFju.bQ1PRuE_uFEuM5KX5lBZa6M 00ygMxP5l8YlcSzFfD_mTPcKymxMgv.hyMBHVgwmiJwDbMnKzf4RmBk.7B8k55y_N85yLevXvcBZ b.eA5oPiOP48YxdRqb.zpTxsNYptSCjTjtleW2thcSJlm8wFmUdGNRISTT7wKWTEoPyXE8pQcJy9 z6ehWuNP.b9dwwIDS0kN7K0IKvDdEFU47wy.VHuhK1LHR8mAtk7NL9amnCn65VSAbsTWaPi_JGVz FrZ.zUfZWWxt1fn27vZBl4GM_o3.zj5mxewOon67yXuInEIO6B3rc957peiJBvR.Kpxtlfp2xown y1KGaeiFOufjhrREibEHXjAT8NMATx0P5UUhmbSQvmgQh9c_Oeqzl9rF7uPafa4YboqcPTrCjHeE 5zbwO14JoM59XE_aI9iH0UYNgZ595WrBkcVSUtoA.CxBjqzZHae326vRj6c2yUD1oqIs1aI9OD8y CqPZ3WhIIAXO3ARPdRQz7gyKj5z.FpJnm_hXdDKf7V5v7_ExA7rbyDWM.BFy7nj1mt8BDQ3OjPL7 72xErUoZ5pTBQr44A8QxoxHyJYiNA1_1sV1UwVk5hzd5spBda_u_S05mzTiJLUBDgL3EtUEeYWF3 hPjxCkISF6CYxREIPNJASO466cnnpn0wYbjF5afjs59qEVd3lysLD3kJyi1qf97FDANEnRTFN3f2 8w6Ka2nCa.aYLfdTdPoDnXA7FbN2vtDIWf.4mgpm6juyZ2T7cjRJ75E7LvM8j0HWD7xNLmzZwFFx 67akKO4B3JLx5V8pjO1ukN7OiADiTqEFwBIVsOXot8JYush5ogiSK9AgHtxMy4XjC4nUN8kPsdaJ i6tm0TUYh9rGOdI4o.ho7S0mbAgK.Nh4Yluf2hEcAi2fCmASsHjqbnXfhFHJrAwMQ2lbxbNWrDyw V7ABCfozPrquRb8QAsdVtpkSfX5DntrD025Lv4AIILPpBHPfh_EXeHJnGZFBLREASw66sW6QhrKt TIWtXgf1rbg2CWBiefcV.jY64RHtACcfcfossO7an1szj5uwnbZEAWO7F5IQA0bAnJcxE8rtut.V dIjL0ywbZzOI_nXmEIHCo0Vix4MDT_vZWLxMczsq2FzQcXBOkAKz6toIvXEJ2LA031FC5zrN1Zx. 0.HmaniqNGTOkxLReD1KSTKoiwhnzHmnnmxzPdVkuwSp2dI8Mrh1fmC.Xkx_CESvZo8jrNMkFWYZ _01Q- X-Sonic-MF: X-Sonic-ID: 4cda7c25-14a7-4c5e-992e-c7bddb5fe3a1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Mon, 22 Jul 2024 16:26:30 +0000 Received: by hermes--production-gq1-799bb7c8cf-2sgrv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c89e7fcf82c31228c985f178405d8b42; Mon, 22 Jul 2024 16:26:25 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: armv7-on-aarch64 stuck at urdlck From: Mark Millard In-Reply-To: <86185657-e521-466b-89e2-f291aaac10a6@freebsd.org> Date: Mon, 22 Jul 2024 09:26:14 -0700 Cc: FreeBSD Current , "freebsd-arm@freebsd.org" , "kib@freebsd.org >> Konstantin Belousov" Content-Transfer-Encoding: quoted-printable Message-Id: <0EF18174-8735-46A4-BD71-FFA3472B319F@yahoo.com> References: <724db42b-5550-4381-8277-2971e6b3e8f1@freebsd.org> <86185657-e521-466b-89e2-f291aaac10a6@freebsd.org> To: mmel@freebsd.org X-Mailer: Apple Mail (2.3774.600.62) 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] X-Rspamd-Queue-Id: 4WSQdh2ryrz43w9 On Jul 22, 2024, at 06:40, Michal Meloun = wrote: > On 22.07.2024 13:46, Mark Millard wrote: >> On Jul 21, 2024, at 22:59, Michal Meloun = wrote: >>> I don't want to hijack the original thread, so I'm replying in a new = one. >>>=20 >>> My tegra track current, has been running 24/7 by building = kernel/world and kde5 in a loop for a few years now. But I have never = encountered the aforementioned lockup in native armv7. >>>=20 >>> I have seen usermode mutex lockup in arm32 jail on aarch64, but only = very rarely (once a month or so) and all my attempts to reproduce it in = a more deterministic way have failed. Also, I don't think I've ever seen = this with the debug version of libc. >>>=20 >>> Unfortunately I also failed to reproduce given lockup using = dlopen_test.c, neither on native armv7 or arm32 jail. >>>=20 >>> Michal Meloun >> What is the output of: >> # readelf -a /libexec/ld-elf.so.1 | grep -E "(^[^ = 0-9]|.*_rtld_get_stack_prot)" >> in your armv7 context(s)? Does it include for likes of: >> QUOTE >> Symbol table '.symtab' contains 911 entries: >> 903: 000000000001b9ac 16 FUNC GLOBAL DEFAULT 11 = _rtld_get_stack_prot >> END QUOTE >> ` >> vs. not? >> Note that the "debug version of libc" being involved likely means = that >> DEBUG_FLAGS was defined. That in turn likely means that strip is not >> being used. In such a case, I expect that the .symtab entry for >> _rtld_get_stack_prot (and more) exists for such a context. > At tis time, I have standard (thus stripped, non-debug) version of = runtime linker library installed. Thus it have only dynamic relocation = record for _rtld_get_stack_prot: >=20 > root@tegra124:~/dlopen_test # readelf -a /libexec/ld-elf.so.1 | grep = -E "(^[^ 0-9]|.*_rtld_get_stack_prot)" > ELF Header: > Elf file type is DYN (Shared object file) > Entry point 0x1449c > There are 10 program headers, starting at offset 52 > Program Headers: > There are 23 section headers, starting at offset 0x1a448: > Section Headers: > Key to Flags: > Dynamic section at offset 0x19fa4 contains 15 entries: > Relocation section (.rel.dyn): > r_offset r_info r_type st_value st_name > Symbol table '.dynsym' contains 27 entries: > 5: 000000000001ba0c 16 FUNC GLOBAL DEFAULT 12 = _rtld_get_stack_prot@@FBSDprivate_1.0 (11) > Notes at offset 0x00000174 with length 0x00000018: > Histogram for bucket list length (total of 6 buckets): > Histogram for bucket list length (total of 27 buckets): > Version symbol section (.gnu.version): > Version definition section (.gnu.version_d): > Attribute Section: aeabi >=20 > ------ >=20 > root@tegra124:~/dlopen_test # ./dlopen_test > root@tegra124:~/dlopen_test # Just to be sure . . . Did you at some point "pkg install cairo" (or analogous) so that the following (or some vintage) were in place? # ls -lodT /usr/local/lib/libcairo.so* lrwxr-xr-x 1 root wheel - 21 Apr 29 19:45:15 2024 = /usr/local/lib/libcairo.so -> libcairo.so.2.11704.0 lrwxr-xr-x 1 root wheel - 21 Apr 29 19:45:15 2024 = /usr/local/lib/libcairo.so.2 -> libcairo.so.2.11704.0 -rwxr-xr-x 1 root wheel - 1118272 Apr 29 19:45:15 2024 = /usr/local/lib/libcairo.so.2.11704.0 # file /usr/local/lib/libcairo.so.2.11704.0=20 /usr/local/lib/libcairo.so.2.11704.0: ELF 32-bit LSB shared object, ARM, = EABI5 version 1 (FreeBSD), dynamically linked, for FreeBSD 15.0 = (1500018), stripped (Installing cairo would also install other things it needs.) For the failing contexts, the a.out from dlopen_test.c will only hang if the library (and what it requires) is actually there to load. =3D=3D=3D Mark Millard marklmi at yahoo.com=