From nobody Sat Jul 16 06:32:07 2022 X-Original-To: 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 4LlJL85t1Gz4WbPv for ; Sat, 16 Jul 2022 06:32:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4LlJL734S1z3tRM for ; Sat, 16 Jul 2022 06:32:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657953133; bh=kJW0notRRNGjh04a6mGHlg2Bl4ORfehu7fKBJ2QV5b4=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=lGKoHFEWNOkRlhMe9mlTVQM3n0rFkok49/R/64gs6ZGaV905iphxA37B3pt2AW8eoY9eG0/014e3tCt7gWx5Jba9OqvFHXY+nh3sj6vLF6acFde/bQMXHTSvKGSa90qKn03J9d8rSLnCIVB3hyBCNgsO00R6yw90p61gKNheSSeKjXPcKqfL+1ZEuvHL8swPFPICDfFXhcgTXhZcO6pgxyju/CxAB/ackL9c+13dcTpWlP63jlqwCuWvuLLOGzYjNmFF8Kpyo/zxmEMlQ1ZABFTkgsI817Eq30GdXpyqy0NkGZboIGOAowFn0BRNwEp6q+wSymQ2/XXi2/R6NY06Vw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657953133; bh=ehl23IisRT8Yj44XT1P46myO4XgldCwBli740ZxtwK/=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Lgz3TpTazuPb8I1fWPqFV20rqfrS4LJncang8g5NWQ2mrMUjckHbPiKwm6JsOQGroFac1YgytMCVaD0evhiCJ+N96EGLummXmXoDLs2FWJ4z4lMaHDhoNvqvhlqo/Joq40WO3PCgkWVFBLyZU4J+x8IO/QxBmeUcvPE60TH+g1XgZq/Ao0GdSeXLS4a9DmClDJcXzsyjZU+k8+7m8XhjUMU1YcGL4UBGKQW0rN61P1gWLbT3FoWwNqNvyKmp5CN7Cmu6R/QD4ek/dMdgCrLLORe/xKlrR7VOtxXkm5p8kL5tcvsz3vjmKXjw1/57e48nBUeJw6SKNIpwGQDhnOQ5Cg== X-YMail-OSG: gxARXcEVM1k_GpvM_z6BiffLAU6FHGKlwxe9qKjXT0j5_fADXfmez4ywditKI4p dJS8XdrkenaE65rsqc9vDTtFdOkD6Y3fYDHxKmE3PY3LOUvBWSU.18hIbhfvxonGhV_navuArbDL pwPaJlaitGuhP0o49KVOYTvoddtkzCF4I5b3p8R3X7Pp.wj.BhlO2e0QUitymy2pn.BjS7zPsTtw z_DpjZWxblwfQiJcaMj7XBp5k.qxjmgdmaZuc7I0gDNsvMSJtPbiKIxmgCvhFJ8U4TK6zg9n17_4 4RQDKwqfRqk.pPNz748UQ77.FW4eAEK5uiGorU2YlR5IhRbxPz4md2Os_lDyaVswHc1qpQJ9jtEi aIE7Oul49RdRfe98tyAvn4bK3tiDGbwBf_Q4iI.pJQ_NBvkCxthxKpMpbC7PB3tsFFDOtShnO4vU 7B_GGWq2mG3e5tMpvfgPoA3728IRB51BbjkrimDb3TcvPWYjH04uJY8ffJxBBwqifefXUr.AeR27 KgPlxWq7Ts2mLtNtjR0Xbrb2Q5zqCRU.6rxPinz00drxBb2I6mXfpcm4rk5r9jYb5ocsmwlsWunc LxOI13IeIkkbphlmF6gYGmJX0XlSDFfDr2bLubQUPw2CGfiFYiAlUPlF2u6vm5MPC1KQGj9QxmTq byZIoGQ3hi5uEEzuj0fn9_kKM8LU2..WR33_sRvUwgFgmapVUk0SsBliGNxFUMNBAg05ngDfohE8 BRr_TrejBJ9ZqFZX4wN6l7ySYz8enV6xow72xhMZEHGxYYb476lF9ymKRBpKoPaERTlflXLMOVji m4EHAL9Klf5WuC85Rb8keFHTizxDVMTzVmAP2z8X_v0LaJNXwngACwwZDT5bfSrEO49BC8aeQ498 _zjvDjt1dXvjeO4eUm.BTCAe9aqXCfLOreUUWOSgFPTFSJFhIVes.1EASozTexrAiduHDezfUgCT C4s1TFAobbK6mf73MqmzH.3M0JqDMd.FnOSq.z2nnui8uawu0o.B89G8yhwaYa2pbjedNqy0EVpz 3kNm6SmFsnJObAJmigS784Q.uo.jpVj8.xZmSAqPZ6.o6QOGSRdlr2ZEAfW1og7LXNu5baYW1AAO SUoG9PNw20.Tcqf3rM0q9KZxbIGuUtvxJnPpBhCla7AxczjBrKq4r34jqXcXMDOzMkVZxmLk67Xv JXGmSm_irHZc.zx6hfdGXaC6ZhqZoi5Phc6czIhrrg7pYkaNz0hrDBNvEL87sKfwt04BhAncvw8P m36zi0L30SWiC0O1KOXf4p4KoX2uNRe8uriGy7MFsk4xKAeOQj0_ceoEC0vtEeHqbog45hpfTt50 2VasEzji_DQLr8V1fp1wMzArBWxPq4RP04i_ueA3XyNbhLE5tUwszzYxWDJjAGbfGXpQ6Sy3cWCL CjKNITZwPLYKsQ7LuKh8mpadyuxnmRxziEnyX5olOk7NF0_SwKvnl4xc1iWxjW3K5EiUulzOk4ws NL20mkZ92IZB0ru9FX.0AK_hmPfwgAxlMZbScM8xig2JXvkwfFrtYXuko9coFBzY_fcDDz2unyw6 xUNZslVYSlNVW4nzVJgzkht_EbLjsF90q1R2QflO.4Iin1tZ5wInR1M1IwRAd74ua4qTBDsUpBJQ MaUpNqdNu.SxY5cNcPvT3vjeKBcYtT3RsVn0bvwCgEfeHbJEVw48fgzkK4Qj.exWr2rTpy5ZSZzp XSJTI5rObAbNGdx_xN.GA.f0y388NQBWJVf1M5n0jMzWKBgFVCe1J_vazJP6RwW.izI1d0tFdUpG 7OkLAsSoBhrF4a7d9h.rKPltJIHzrB9ERT597w0doZJcNhaUDBzeQ9gzyOcX4leaajwZF6ShHP_W u3PpdlPXCi9.PuOPlmxSVxUd4Tyre.D5JXoPRx0q2bgqne9UeSbz07bwkA3mUers2UoFmmO5wjCq CKfZWutdyjfiXpZ_q0P94nGekI.4NcINTfWoNZguTbtd64aNfgJZjZpUUrosj78cuQ4Cvjr7kViP WTByZ3yejFJoM.n6uEcIwIzV4sdJsVBo9sN2z_2xsTxjVLqa_1jxv6IQqgZguoxZtxHYIpSs0t1X CXtrDJ3vpKO4JlAJscLIEAl_KScKZ7Cw2NwtUCtjODb1zTy9IOIMXeWA9vGTzBjoaAzvXSSAxS0t H6ypLjQwU1Re7x8d6OOgZHKtSvWo7mqiYVYWeOx1sxSbe41dPOPZplz0kvywY3jHMeGgRyU0Cmb1 SRG.TQqcEg0qRYNrOhHmjoLsFOZtAE9i5jckfbdtHTWGXr1RJcH4YbxrHoMrlh9C2bwKNMkOPnnX q11TFKIlj9tantQKuzbCVc3GnFJM_Veb1XmVXe6JBhpbMFwEkPu5oxA9RGQw_ X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sat, 16 Jul 2022 06:32:13 +0000 Received: by hermes--production-bf1-58957fb66f-qrtmg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3b5ba8c9ac817423d9ea2b2238e7577f; Sat, 16 Jul 2022 06:32:09 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 14.0 \(3654.120.0.1.13\)) Subject: Re: 13.1-RELEASE image fails to boot Rev 1.4 8 GiByte RPi4B (B0T vintage SOC) when dd'd to the example USB3 media then used to try to boot via USB3 port Date: Fri, 15 Jul 2022 23:32:07 -0700 References: <77F18A4B-6B89-478A-A0CF-306866014536@yahoo.com> <0AB0761B-4E22-4181-A29D-F0260B6F8055@yahoo.com> To: "freebsd-arm@freebsd.org" In-Reply-To: <0AB0761B-4E22-4181-A29D-F0260B6F8055@yahoo.com> Message-Id: <62DD9052-449B-4FA6-8669-0FF1EC1D8D3A@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LlJL734S1z3tRM X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=lGKoHFEW; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.43 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.93)[-0.931]; 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)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[arm]; 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.146:from] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jul-9, at 21:23, Mark Millard wrote: > On 2022-Jul-9, at 18:59, Mark Millard wrote: >=20 >> On 2022-Jul-5, at 15:45, Mark Millard wrote: >>=20 >>> On 2022-Jul-5, at 14:17, Mark Millard wrote: >>>=20 >>>> Summary for Rev 1.4 8 GiByte RPi4B (B0T vintage SOC) context: >>>>=20 >>>> A) One type of USB3 media (USB2 compatible) works for booting via = USB2-port. >>>> B) The same media fails for USB3-port based boot attempts. >>>> C) I boot the same type of media for main [so: 14] instead of = 13.1-RELEASE. >>>> D) An alternate type of USB3 media (USB2 compatible) booted via = USB3 just >>>> fine via 13.1-RELEASE. >>>>=20 >>>> The details . . . >>>>=20 >>>> I intended for for use in the Rev 1.4 8 GiByte RPi4B's >>>> by first going onto USB3 media (of the same kind I >>>> normally use on the RPi4B's with main and the like). >>>> So, I tried:=20 >>>>=20 >>>> # dd if=3DFreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img of=3D/dev/da0 = \ >>>> bs=3D1m conv=3Dsync status=3Dprogress >>>>=20 >>>> and then tried to boot the RPi4B via the media and it gets >>>> the following (the kernel loads and runs but . . .): >>>>=20 >>>> . . . >>>> Trying to mount root from ufs:/dev/ufs/rootfs [rw]... >>>> uhub0: 5 ports with 4 removable, self powered >>>> ugen0.2: at usbus0 >>>> uhub1 on uhub0 >>>> uhub1: = on usbus0 >>>> Root mount waiting for: usbus0 >>>> uhub1: 4 ports with 4 removable, self powered >>>> Root mount waiting for: usbus0 >>>> uhub_reattach_port: port 3 reset failed, error=3DUSB_ERR_TIMEOUT >>>> uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling = port 3 >>>> mountroot: waiting for device /dev/ufs/rootfs... >>>> Mounting from ufs:/dev/ufs/rootfs failed with error 19. >>>>=20 >>>> Loader variables: >>>> vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs >>>> vfs.root.mountfrom.options=3Drw >>>>=20 >>>> Manual root filesystem specification: >>>> : [options] >>>> Mount using filesystem >>>> and with the specified (optional) option list. >>>>=20 >>>> eg. ufs:/dev/da0s1a >>>> zfs:zroot/ROOT/default >>>> cd9660:/dev/cd0 ro >>>> (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) >>>>=20 >>>> ? List valid disk boot devices >>>> . Yield 1 second (for background tasks) >>>> Abort manual input >>>>=20 >>>> mountroot>=20 >>>>=20 >>>> Plugging into the other USB3 port and attempting the >>>> power on boot just changes the port numbers from 3 to 2 >>>> in the sequence. >>>>=20 >>>> Plugging into a USB2 port does not have the problem and >>>> it completes the boot and operates. (The media is USB3 >>>> but USB2 compatible as well.) >>>>=20 >>>> Adding to /boot/loader.conf : >>>>=20 >>>> # First, 3 additions: >>>> kern.cam.boot_delay=3D10000 >>>> vfs.mountroot.timeout=3D10 >>>> vfs.root_mount_always_wait=3D1 >>>>=20 >>>> and retrying via a USB3 port just results in: >>>>=20 >>>> . . . >>>> Root mount waiting for: usbus0 CAM >>>> uhub_reattach_port: port 3 reset failed, error=3DUSB_ERR_TIMEOUT >>>> uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling = port 3 >>>> Root mount waiting for: CAM >>>> Root mount waiting for: CAM >>>> Root mount waiting for: CAM >>>> Root mount waiting for: CAM >>>> Root mount waiting for: CAM >>>> Root mount waiting for: CAM >>>> Mounting from ufs:/dev/ufs/rootfs failed with error 2; retrying for = 10 more seconds >>>> Mounting from ufs:/dev/ufs/rootfs failed with error 2. >>>>=20 >>>> Loader variables: >>>> vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs >>>> vfs.root.mountfrom.options=3Drw >>>>=20 >>>> Manual root filesystem specification: >>>> : [options] >>>> Mount using filesystem >>>> and with the specified (optional) option list. >>>>=20 >>>> eg. ufs:/dev/da0s1a >>>> zfs:zroot/ROOT/default >>>> cd9660:/dev/cd0 ro >>>> (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) >>>>=20 >>>> ? List valid disk boot devices >>>> . Yield 1 second (for background tasks) >>>> Abort manual input >>>>=20 >>>> mountroot>=20 >>>>=20 >>>> So: same problem. >>>>=20 >>>> For reference, from the media being plugged into a different >>>> aarch64 FeeBSD machine running main: >>>>=20 >>>> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage = device Samsung PSSD T7 Touch (0x04e8:0x4001) >>>> ugen1.5: at usbus1 >>>> umass0 on uhub4 >>>> umass0: = on usbus1 >>>> umass0: SCSI over Bulk-Only; quirks =3D 0x0100 >>>> umass0:6:0: Attached to scbus6 >>>> da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 >>>> da0: Fixed Direct Access SPC-4 SCSI = device >>>> da0: Serial Number REDACTED >>>> da0: 400.000MB/s transfers >>>> da0: 953869MB (1953525168 512 byte sectors) >>>> da0: quirks=3D0x2 >>>>=20 >>>> The RPi4B is of a vintage that has the "3 GiByte DMA" issue >>>> present, not that it would be likely to be contributing here. >>>>=20 >>>>=20 >>>> So I then tried the sequence using a different type of USB3 >>>> media (also USB2 compatible), placed in a USB3 port to boot: >>>>=20 >>>> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage = device OWC Envoy Pro mini (0x1e91:0xa2a5) >>>> ugen1.5: at usbus1 >>>> umass0 on uhub4 >>>> umass0: on = usbus1 >>>> umass0: SCSI over Bulk-Only; quirks =3D 0x0100 >>>> umass0:6:0: Attached to scbus6 >>>> da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 >>>> da0: Fixed Direct Access SPC-4 SCSI device >>>> da0: Serial Number REDACTED >>>> da0: 400.000MB/s transfers >>>> da0: 228936MB (468862128 512 byte sectors) >>>> da0: quirks=3D0x2 >>>>=20 >>>> For this media, the sequence worked and booted successfully. >>>>=20 >>>>=20 >>>> So the issue is somehow specific to some USB3 media=20 >>>> used in the USB3 ports but not to others. "reset failed, >>>> error=3DUSB_ERR_TIMEOUT" may need more time or better >>>> recovery if a wider range of boot devices are to be >>>> supported. May be the T7 Touch needs more than the >>>> standard amount of time to reset as a USB3 device or >>>> some such. (I've no clue about the details.) >>>=20 >>> I substituted a 13-STABLE kernel.txz expansion and got the >>> same result using that kernel. (There are not .img files >>> for this currently.) >>=20 >> I took a different path of setting up a stable/13 based >> media, based on my own build context but upgrading a >> 13.1-RELEASE starting point. This stable/13 variant boots >> the RPi4B's just fine via the USB3 media that 13.1-RELEASE >> failed to boot with. I'm not sure what the differences >> that matter are. >>=20 >=20 > Well, the kernel.txz was based on: >=20 > Thu, 30 Jun 2022 > =E2=80=A2 git: 70fd40edb869 - stable/13 - debugnet: Fix an error = handling bug in the DDB command tokenizer Mark Johnston >=20 > via: >=20 > Fri, 01 Jul 2022 > =E2=80=A2 New FreeBSD snapshots available: stable/13 (20220701 = 70fd40edb86) Glen Barber >=20 > while my build was based on: >=20 > stable/13-n251684-815db559eccc-dirty > (815db559eccc is from Wed, 06 Jul 2022) >=20 > Between those are: >=20 > Fri, 01 Jul 2022 > =E2=80=A2 git: 39cd7aa134df - stable/13 - USB: add quirks to = XHCI Bjoern A. Zeeb > =E2=80=A2 git: 66754c01ff95 - stable/13 - XHCI: clear warm and = port reset Bjoern A. Zeeb >=20 > and that last mentions port reset handling explicitly. > It is, at least, suggestive. Nope. Turns out that the problem still exists but my config.txt content was hiding the problem. Once I have "force_turbo=3D1" in config.txt , the problem stops. Without it, the problem occurs. This is for stable/13 based and releng/13.1 based. main [so: 14] does not show the problem wither way. (The boot contexts being U-Boot style, like is normal for FreeBSD.) See: = https://lists.freebsd.org/archives/freebsd-arm/2022-July/001585.html >> For reference for the working stable/13 context and >> other content involved: >>=20 >> # strings -a /boot/efi/start4.elf | grep VC_BUILD_ID_=20 >> VC_BUILD_ID_USER: dom >> VC_BUILD_ID_TIME: 12:10:40 >> VC_BUILD_ID_VARIANT: start >> VC_BUILD_ID_TIME: Feb 25 2021 >> VC_BUILD_ID_BRANCH: bcm2711_2 >> VC_BUILD_ID_HOSTNAME: buildbot >> VC_BUILD_ID_PLATFORM: raspberrypi_linux >> VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) >>=20 >> (/boot/efi/armstub8-gic.bin does not have very useful >> version-string information.) >>=20 >> # strings -a /boot/efi/u-boot.bin | grep 'U-Boot 20' >> U-Boot 2021.07 (May 12 2022 - 07:00:33 +0000) >>=20 >> Note: To my knowledge, the RPi* firmware, armstub8-gic.bin >> file, and u-boot.bin file above are all as they were for >> 13.1-RELEASE's image, other that for 13.1-RELEASE I had >> also tried adding /boot/efi/timeout and I've left that >> in place since then and I've added my usual >> /boot/efi/config.txt material (that had also not made a >> difference for 13.1-RELEASE). >>=20 >> (/boot/efi/EFI/BOOT/bootaa64.efi and >> /boot/efi/EFI/freebsd/loader.efi do not have very useful >> version-string information.) >>=20 >> # uname -apKU # manually line split >> FreeBSD 13S-ufs 13.1-STABLE FreeBSD 13.1-STABLE #40 >> stable/13-n251684-815db559eccc-dirty: Sat Jul 9 14:02:23 PDT 2022 >> = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.= aarch64/sys/GENERIC-NODBG-CA72 >> arm64 aarch64 1301505 1301505 >>=20 >>=20 >> Unfortunately, it has been some time since a >>=20 >> FreeBSD-13.1-STABLE-arm64-aarch64-RPI-*.img >>=20 >> (a snapshot) has managed to build and be distributed. >> I'm not sure what the result would be like for such at >> this point. >>=20 >> Once such is available, I may do an experiment based on >> just a stable/13 snapshot. Done, using: FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220715-831c6b8edda-251792.img That is when I figured out the "force_turbo=3D1" issue for config.txt being involved in hiding the problem. >>> But using: >>>=20 >>> = FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220701-9aa02d5120a-256480.img >>>=20 >>> does not have the problem. >>=20 I still do not see the problem in main [so: 14]. =3D=3D=3D Mark Millard marklmi at yahoo.com