From nobody Sat Jun 26 02:52:32 2021 X-Original-To: freebsd-toolchain@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 7543011E1A65 for ; Sat, 26 Jun 2021 02:52:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GBdhT73z3z4dhm for ; Sat, 26 Jun 2021 02:52:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624675959; bh=M0xQ5tU1gniF4ZeQX0RBwcI2XScmRE5Jctt6P2OT0bA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=jkOmpGHczIk7MGzOhkJvXcgFe9tM+8esSFceTU4kw31lr3RxXyl56pt9MZ2xpAKo0Dr7mZNNp7v2YK8jIaMDdS8RZDizMLSNYSo/RQnq90QoN0pqCydHkS62Rhxedft2f4ZLgrKJxJppU8JJsySOIFhCChZks3GnK5cM7ZwFeNuz7ADobRbgYCzGZWFdItQ+dCBHtuLGQn0NLRBDt4XmajKwhIGTG8/E1Xnk/L7OXeFH9t8f8ygsIzx94D/Y59Jcbchgbjve2UeSh56rfr1VCEdeoZb5EySPqOUIR7w2uL4B0oZlNBjMZMZF2ZdSyQMweq1wFfJ+BDjttzi4Mr0syw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624675959; bh=aKOrK5IdYJ4YZegyS/4Qo1oTOPmUgGDHWW4M4KnJH2F=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=pnmA5o22WVH1CKCL57EYUgZDhx6mMfo7TchxA+veoNZ3sLPQvQDc65q1yIkhXeJj9fr8TglYLe4WWIYX+NXnBAr3AqDRuztOoQrsDSBtoj5/TCM76ycydGdb4IXwwibI4HzLvhnt1Yb4DGsWWIHwH6zUh+TUzuK2gkBa+KotpOX5hNQffy+weta/jAyR+Hr/mrH+JGiNG+ppsJXNNPIKdHZekKGmfZwY+hkdykETrmsbzR8QlCpyt4hUs7OFu77OsMWCVdILA5LNQ2ARvCdrsVM/Z5oRQZk+9Z5pdMn7bgsPBR3g6W79j6toh8+KmnTxDKYq9bFnZ8Om5KoYut+6Ag== X-YMail-OSG: y1Q1lb0VM1nF5aVbpgeDWMy70DEY9HA4vcA3Al5z.eHtYmH8MkuAg3aWCjUpG3B oskJ1ElF8dvEC2gtRldn_qzmoJiY5XR6UkG6XS4UHvl3pZGbl2HlTk.QfLCesqHL1AwbDioRdSIK jC1Cw2P4aWiBa_IW89G0PgEtPdZitsgHzecidzAYPZPcUjR2VXGrlsH0rYcCjqxpC3p18mUbqDux lILvogYptOZH2xIQ3jFcgBtnf69v8PoKnvxN8xcUGPbzggDPlZFr6287q1uZTZz9xLBJgR3PUVKN l9DvdtAUcHaNnkdYObkI0zhvraJrVJioLJ.Gtg3MLfN.R6MHlLRzbJn4pyNCwuauI_3jmdQ2nl1_ GF3chHT_eDfaio2h8zqjabU.1x8sJnapbVVuTt1o.v0D7Wc2lb1pItjczqUd6FDveyME9zAhYq_7 Yd2IbnJVL_CdexoLjs6u8XQ5QDpEJDzzK5qmo3Qg923gAVazs9lM6GmpdDFCME9IvmjLYUg48teT ahnAStbN9TZtr6wD1sxrPmFTpB.RuIL8JvffiUBVWOwEJgVMePGL6YKJDNQB3ob73tcAqURy1VD8 fEOIQrEubCPO4zzYA7f64EUkps3vhB.fjSgpsJqodK6k0zFyojSnjy8xvvUhxtg97ZGaFewUPknK BMctdPLOKatGb85D9ro2fN_f6GtFlMUhWG5QPXL4_SoEdyDYSZTO.knLCKM.101T_OBLUhSPUcPm 4ehRuZT_1jllpQTU.4KEfxPRJU05jMTmEIse0K5gwpczU8GJ0GacYi.Hu5VUqZDvD0ahrIU1jsr8 IxN25jWWXtdRzX4.CT59arC5UVLuI48Yq2jIADbLKGhsEYzB9MFj2bj3rI5qbyMRWWXroM6MpFOa u7nuuXbjBFHM8jjxCqLB9E.mTWuljU4uGh0llU2OsWeMRhY0sWk11T8wIz7GkYj5B6KqqU1TjUaG 2NbYm4zvOga2JGcbrhzbY4O_Y6rP3JDDO4GrZIevv8qvIVkjQupLFo62lrYQFT0JxSxOS8KPn6p2 bFPm92eQpdo9rIPj9G_IwGiCnLEyymRUxndif6OT9E.Kp6jpY6jiRxJDw6Et1gCsb1pqiBugc_A9 LSJn7287DIKJNmdm0KF2f1cdGxDQ_JM4VCgDkC1yRaBQoBE.N4aMfDk2au779ebjhqM6fi.oZz0N WDitv_dpFm6avzOgvOwjyv5y.f7y2.v5dhhiw8p993ZrIrt4Ua.T1b4ViVn977MDt1CCCzQQMfqS xwA0fjVg4bl3Qqz54BzZS9weTsQbgv89WC5.R7UedjzXxXTVuT9AK4tEl1pOqkP_WNMNvd9TwIi1 MCW3giAnxW9W_OD9_OEn3LxH8rVsHPkyDsqRIacS2vDPH1No9QiwrcPuGoDkaJJItMZVX9SFnk7H keyxNciJFL3jcAcu9JFE_jvEDebmbjtTfBIE7L92STwInjNAX4wc6JjpeftVBxHhvU30OdTuYLue eXKNJxa1fTCaYkA_qmIaCzJo.iPkiuKsEj2pp4papFLu_WYLam_fUD3Ir2hAyTEQPcAxXZVzV5kf fwolN7KQW4GmI2w.pUMwe_zt8Gh2kRJZSOsaGFu4opAscO6zNfNN6xOzivHerlajdUubQnFkmuyR LAhnD4Dz9V6ghC.54iYDUVUdSaN0q554PJbiiz0dT7La9Tz_KMHDZZOMwIhSm8bGNoHpXEF6jJag UK_W.iBut58DIukzy2NSNUFy_H3IZDr8Ktct6tl0EKx3fY2Uvxf3Wiuzv1731ErfWctf_BNC.ppL .1xrKFYQvALUyIn62bfpVOAvj_pjbQ3AwwotCGa6hsMmYx_D1WVKJU5SjlZuJqrt4w5jB_jMZkyC iViUEMrJi2KfBfKZP.gkyRdLAuxQrV_GXLpxCqdcPVaFnJ8g5CkDn3iELhYjelK.OFd8yk8i78fn hktcUKjE.dqtbaxfaIh6JGsMxuE515JxVKjPviiGzgZRWufVs10Q0W17fnCM61kO2JWQSd66Cs.i aU92GuAbH1DT507U9_vCuaY83ZL7H6PmJf7TLdF9KkzrpKbovCrGCIEPU17cnZGuGCvx4nKkEx5u EwY4JleLuZ.phSWx7flMnBKSlPiDdPPxUVtYwG_53vM_IeaFFsD0iBjfclNLnfMp4TiejVUw3qYa XoxHtn0CYz9N091pV7LZRIwQ2.oBenh92OOF7K0GnOWRu8p8u.CGzVGtZQUlX_JUhcbHEFU2cEgM 8X8q7Xixnvx8UQWbYKPpN.XOAIbB4TmX9ILHfzdYaECICe5tlGKVPZ9PNEwnJu6tapQDqqVPQAXa 5RnxH5tYFB07uzFECnHg4CAYTtsfREQHiJqg46QpW1tuN1oH.H61RAhNItT7Oh5y2vneocAovScP GxBfyk_ooZCG9p_jzyzjbmagcPXhZR9tqu1QAlMscGhcKdYewt1JjTwOLaYrdbTQv6YG6omnwIKY 8MrwJ6MQWR_BlduwW4GaYyszHZICigkocBT3pON5.SLrN4eSEVS_5QgSQkiFzTNkgBRKIeIVuWkh nLyDC3E_ZMypCIWryr85kN2t890.anQ30Nl5YGAqCWlWi92iZltxpXE_bySLi0Ct36wLHVK8kTKp MwC3E_C8uZLTH3ZU2LlR88KfgCwHcxxOAgHxO7.9hkBl_fuleLzly74jrfsonPajZcgRpqjqmSyV XHkY.pxXW.APguML09g-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 26 Jun 2021 02:52:39 +0000 Received: by kubenode505.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ad59790cb08a79b560463ebe1bc01d60; Sat, 26 Jun 2021 02:52:35 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: llvm10 build failure on Rpi3 In-Reply-To: Date: Fri, 25 Jun 2021 19:52:32 -0700 Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <5A26965D-2DFD-4A46-A171-A382A61E3CFB@yahoo.com> References: <20210623050958.GA79888@www.zefox.net> <20210623174338.GA84853@www.zefox.net> <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> <20210624043000.GA87740@www.zefox.net> <22B941CA-3AFF-42FD-98D1-D40EC2F6EC43@yahoo.com> <20210624160109.GB87740@www.zefox.net> <3B41633E-AAFC-422A-8D73-3B1B001023F0@yahoo.com> <20210625001651.GA98214@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GBdhT73z3z4dhm X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=jkOmpGHc; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.65.84:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.65.84:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.84:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-toolchain] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-24, at 17:54, Mark Millard wrote: > On 2021-Jun-24, at 17:16, bob prohaska wrote: >=20 >> On Thu, Jun 24, 2021 at 10:41:38AM -0700, Mark Millard wrote: >> [huge snip] >>>=20 >>> So: Even going back to June 9 may messed up nfs >>> use. (I've no clue what services you depend on >>> or in what contexts.) You might need to disable >>> nfs even trying to start at the next boot before >>> booting into such an older kernel. >>=20 >> No NFS involved. Right now the machine is running >> FreeBSD 13.0-CURRENT #5 main-c255664-g4d64c7243d26: Sat Jan 9 = 11:27:58 PST 2021 >> = bob@www.zefox.org:/usr/obj/usr/freebsd-src/arm64.aarch64/sys/GENERIC-MMCCA= M arm64 >=20 > I'll note that the output of -apKU fpr uname: >=20 > # uname -apKU > FreeBSD CA72_16Gp_ZFS 13.0-STABLE FreeBSD 13.0-STABLE #3 = stable/13-n246090-6e2623c012c3-dirty: Thu Jun 24 13:59:44 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.= aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300509 1300509 >=20 > has some extra text at the end that would indicate > when the world is mismatched with the kernel: the > last 2 numbers end up not equal and the prefix 13 > vs. 14 would indicate crossing a major version. > (Kernel newer, world older can be valid/supported.) >=20 >> and repeating the previous attempt to build devel/llvm10 with no = other >> intentional changes.=20 >>=20 >>> Jan 9 predates 14 and 13.0-RELEASE: sys/sys/param.h got >>> #define __FreeBSD_version 1400000 back on Jan-22. >>>=20 >>> Running newer worlds on older kernels is not supported. >>> Generally folks to not track the KBI changes vs. the >>> consequences of not having the right KBI. This makes >>> interpreting results difficult even when it appears to >>> work. There can be mixes like NFS not working but other >>> things working. There could be corruptions but such >>> may not be likely. Do you have what you consider >>> sufficient backups it case things get messed up? (That >>> might be the status of being okay with starting over >>> if something really bad happens.) >>>=20 >> No backups, but I'm not averse to starting from scratch on >> this particular machine. >>=20 >> As it happens, the poudriere session ended much as before: >>=20 >> FAILED: = lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSel= ector.cpp.o=20 >> /usr/bin/c++ -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS = -D__STDC_LIMIT_MACROS -Ilib/Target/AArch64 = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AArch64 = -Iinclude -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include = -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem /usr/local/include = -fno-strict-aliasing -DNDEBUG -isystem /usr/local/include -fPIC = -fvisibility-inlines-hidden -Werror=3Ddate-time = -Werror=3Dunguarded-availability-new -Wall -Wextra -Wno-unused-parameter = -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic = -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default = -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor = -Wstring-conversion -fdiagnostics-color -ffunction-sections = -fdata-sections -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem = /usr/local/include -fno-strict-aliasing -DNDEBUG -isystem = /usr/local/include -fvisibility=3Dhidden -fno-exceptions -std=3Dc++14 = -MD -MT = lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSel= ector.cpp.o -MF = lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSel= ector.cpp.o.d -o = lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSel= ector.cpp.o -c = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AArch64/AA= rch64InstructionSelector.cpp >> In file included from = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AArch64/AA= rch64InstructionSelector.cpp:312: >> lib/Target/AArch64/AArch64GenGlobalISel.inc:33194:41: error: expected = expression >> /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/0, = /*RC*//*AArch64::FPR64RegClassID: @0*/, >> ^ >> lib/Target/AArch64/AArch64GenGlobalISel.inc:33194:99: error: expected = expression >> /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/0, = /*RC*//*AArch64::FPR64RegClassID: @0*/, >> = ^ >> lib/Target/AArch64/AArch64GenGlobalISel.inc:40087:39: error: expected = expression >> /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/2, = /*RC*//*AArch64::FPR64RegClassID: @0*/, >> ^ >> lib/Target/AArch64/AArch64GenGlobalISel.inc:40087:97: error: expected = expression >> /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/2, = /*RC*//*AArch64::FPR64RegClassID: @0*/, >> = ^ >> 4 errors generated. >> [ 25% 1396/5364] >=20 > This still had junk:false in /etc/malloc.conf ? >=20 > So, if it is a kernel problem, it is an old one and > likely also in releng/13 and stable/13. >=20 > Beyond other things that I've listed, there is also > that you have an unusual context in that you use > GENERIC-MMCCAM. >=20 > So I'm going to suggest using an official kernel build > as built by the ci.freebsd.org systems, one that is not > GENERIC-MMCCAM. In: >=20 > = https://artifact.ci.freebsd.org/snapshot/main/66aec14a5391bda1e9a20f5e4381= 626797c3e0fb/arm64/aarch64/ >=20 > there is: >=20 > kernel.txz >=20 > and, if you want the debug information to match: >=20 > kernel-dbg.txz >=20 > These are compressed tar archives. Possibly after > first uncompressing, a command of the form: >=20 > # tar -xpf NAME -C / >=20 > will overwrite what you now have installed. (Make any > desired copies first.) Then you can reboot and use > the kernel. The debug info ends up places like: >=20 > # ls -Tld /usr/lib/debug/boot/*/ > drwxr-xr-x 2 root wheel 647 May 27 12:39:52 2021 = /usr/lib/debug/boot/kernel.old/ > drwxr-xr-x 2 root wheel 647 Jun 24 14:14:08 2021 = /usr/lib/debug/boot/kernel/ > drwxr-xr-x 2 root wheel 2 Apr 8 22:40:04 2021 = /usr/lib/debug/boot/modules/ >=20 > So appropriate copies from there may be involved. >=20 > (I do this sort of https://artifact.ci.freebsd.org/snapshot/. . . > thing to approximately bisect without spending time on doing > builds and if a problem reproduces that means my personal > builds are not at fault.) >=20 >> Not sure what to try next. >=20 > I gather that no RPi4B is available to move the media > to? (Having more RAM but being able to force much of > it to be ignored can be handy as a test environment > for this kind of context.) >=20 I have a RPi4B 8 GiByte with total_mem=3D1024 (MiBytes) in config.txt that is attempting a devel/llvm10 build in a poudriere jail. But the host FreeBSD has: # uname -apKU FreeBSD Rock64_RPi_4_3_2v1p2 14.0-CURRENT FreeBSD 14.0-CURRENT #0 = main-n247562-66aec14a5391-dirty: Fri Jun 25 03:25:00 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA53 arm64 aarch64 1400024 1400024 and the chroot that poudriere is using has releng/13 (patch -p2 based): # uname -apKU FreeBSD Rock64_RPi_4_3_2v1p2 14.0-CURRENT FreeBSD 14.0-CURRENT #0 = main-n247562-66aec14a5391-dirty: Fri Jun 25 03:25:00 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA53 arm64 aarch64 1400024 1300139 So it is not like your context in some ways. Another is: my typical USB3 SSD based file system, not spinning rust. It is UFS in this case. The swap/paging partition shows as (for example): # swapinfo Device 1K-blocks Used Avail Capacity /dev/gpt/Rock64swp2 3145728 56360 3089368 2% So: no warning about being mis-tuned vs. the 1 GiByte of used RAM. (I do not know about your context for this.) All the ports that devel/llvm10 needs are already in place for poudriere's use for this experiment. Another point is: # more /usr/local/etc/poudriere.d/options/devel_llvm10/options=20 # This file is auto-generated by 'make config'. # Options for llvm10-10.0.1_3 _OPTIONS_READ=3Dllvm10-10.0.1_3 _FILE_COMPLETE_OPTIONS_LIST=3DBE_AMDGPU CLANG DOCS EXTRAS LIT LLD LLDB = LLD_LINK OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD OPTIONS_FILE_SET+=3DBE_AMDGPU OPTIONS_FILE_SET+=3DCLANG OPTIONS_FILE_SET+=3DDOCS OPTIONS_FILE_SET+=3DEXTRAS OPTIONS_FILE_SET+=3DLIT OPTIONS_FILE_SET+=3DLLD OPTIONS_FILE_SET+=3DLLDB OPTIONS_FILE_SET+=3DLLD_LINK OPTIONS_FILE_SET+=3DOPENMP OPTIONS_FILE_UNSET+=3DPYCLANG OPTIONS_FILE_UNSET+=3DBE_FREEBSD OPTIONS_FILE_SET+=3DBE_NATIVE OPTIONS_FILE_UNSET+=3DBE_STANDARD (So I normally build less than BE_STANDARD or BE_FREEBSD would build.) We will see if this is enough common context to replicate the general type of build problem. (Your details very from one attempt to the next so an exact match need not be expected, even if if this does also fail.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)