Date: Thu, 14 Jan 2021 22:50:50 -0800 From: Mark Millard <marklmi@yahoo.com> To: Brandon Bergren <bdragon@FreeBSD.org>, freebsd-ppc <freebsd-ppc@freebsd.org> Subject: Re: Modern 13 has early-fail boot for 2-socket/1-core-each PowerMac7,2 G5; r365932 boots it fine; artifact.ci r368820 hangs later Message-ID: <88B7B643-8B34-479F-8D95-EB684650F488@yahoo.com> In-Reply-To: <02EACD59-674C-49F2-8E68-D08A33BC4523@yahoo.com> References: <C503A323-A82A-49E1-9F71-3155F9A30ADD@yahoo.com> <02EACD59-674C-49F2-8E68-D08A33BC4523@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Jan-14, at 17:39, Mark Millard <marklmi at yahoo.com> wrote: > On 2021-Jan-13, at 14:35, Mark Millard <marklmi at yahoo.com> wrote: >=20 >> I attempted moving the media I use with the 2-socket/2-cores-each >> G5 into the 2-socket/1-cores-each G5 that I have access to. It >> silently hangs up almost immediately after the loader's timeout >> prompt is "returned to" (or finishes the timeout). This happened >> for both vt and sc for kern.vty . >>=20 >> An older system that still boots (with an oddity) with is as >> follows, also showing some about the type of machine: >>=20 >> FreeBSD 13.0-CURRENT #18 r365932M: Tue Sep 22 13:46:46 PDT 2020 >> = root@FBSDFHUGE:/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powe= rpc.powerpc64/sys/GENERIC64vtsc-NODBG powerpc >> FreeBSD clang version 11.0.0 (git@github.com:llvm/llvm-project.git = llvmorg-11.0.0-rc2-91-g6e042866c30) >> VT(ofwfb): resolution 1680x1050 >> cpu0: IBM PowerPC 970 revision 2.2, 2000.20 MHz >> cpu0: Features dc000000<PPC32,PPC64,ALTIVEC,FPU,MMU> >> cpu0: HID0 511081<NAP,DPM,NHR,TBEN,ENATTN> >>=20 >> model: >> 50 6f 77 65 72 4d 61 63 37 2c 32 00=20 >> 'PowerMac7,2' >>=20 >> cpu-version: >> 00 39 02 02=20 >>=20 >> model: >> 41 70 70 6c 65 20 50 6f 77 65 72 4d 61 63 37 2c 32 20 35 2e=20 >> 31 2e 34 66 30 20 42 6f 6f 74 52 4f 4d 20 62 75 69 6c 74 20=20 >> 6f 6e 20 31 31 2f 32 31 2f 30 33 20 61 74 20 31 37 3a 34 31=20 >> 3a 34 38 00=20 >> 'Apple PowerMac7,2 5.1.4f0 BootROM built on 11/21/03 at 17:41' >> ':48' >> BootROM-version: >> 24 30 30 30 35 2e 31 34 66 30 00=20 >> '$0005.14f0' >> BootROM-build-date: >> 31 31 2f 32 31 2f 30 33 20 61 74 20 31 37 3a 34 31 3a 34 38=20 >> 00=20 >> '11/21/03 at 17:41:48' >>=20 >> # uname -apKU >> FreeBSD FBSDG5L2 13.0-CURRENT FreeBSD 13.0-CURRENT #18 r365932M: Tue = Sep 22 13:46:46 PDT 2020 = root@FBSDFHUGE:/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powe= rpc.powerpc64/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1300115 1300115 >>=20 >> The above has my normal patches involved and is a non-debug >> build. >>=20 >> The oddity in this boot is that the following sequence >> happens each time: >>=20 >> . . . >> ada0 at ata2 bus 0 scbus2 target 0 lun 0 >> ada0: <OWC Mercury Electra 3G SSD 541ABBF0> ATA8-ACS SATA 2.x device >> ada0: Serial Number **REPLACED** >> ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 512bytes) >> ada0: 457862MB (937703088 512 byte sectors) >> cd0 at ata0 bus 0 scbus0 target 0 lun 0 >> cd0: <PIONEER DVD-RW DVR-111D 1.23> Removable CD-ROM SCSI device >> cd0: Serial Number **REPLACED** >> cd0: 66.700MB/s transfers (UDMA4, ATAPI 12bytes, PIO 65534bytes) >> cd0: Attempt to query device size failed: NOT READY, Medium not = present >> Mounting from ufs:/dev/ufs/FBSDG5L2rootfs failed with error 2; = retrying for 10 more seconds >> Mounting from ufs:/dev/ufs/FBSDG5L2rootfs failed with error 2. >>=20 >> Loader variables: >> vfs.root.mountfrom=3Dufs:/dev/ufs/FBSDG5L2rootfs >> vfs.root.mountfrom.options=3Drw,noatime >>=20 >> Manual root filesystem specification: >> <fstype>:<device> [options] >> Mount <device> using filesystem <fstype> >> 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) >> <empty line> Abort manual input >>=20 >> mountroot>=20 >> List of GEOM managed disk devices: >> label/FBSDG5LBswap ufs/FBSDG5LBrootfs cd0 ada0s4 ada0s3 ada0s2 ada0 >>=20 >> mountroot> Trying to mount root from ufs:/dev/ufs/FBSDG5LBrootfs = []... >> lo0: link state changed to UP >> gem0: link state changed to DOWN >> gem0: link state changed to UP >> . . . >>=20 >> (Despite what is shown, I did type "ufs:/dev/ufs/FBSDG5LBrootfs".) >>=20 >>=20 >> The early-fail media is based on main's 19cca0b9613d (but with my = patches >> involved): >>=20 >> # ~/fbsd-based-on-what-freebsd-main.sh mm-src >> 19cca0b9613d7c3058e41baf0204245119732235 >> CommitDate: 2021-01-09 16:21:33 -0800 >> 5d333ee67ac3 19cca0b9613d (HEAD -> mm-src) mm-src snapshot for mm's = patched build in git context. >> FreeBSD FBSDG5L2 13.0-CURRENT FreeBSD 13.0-CURRENT = mm-src-c255807-g5d333ee67ac3 GENERIC64vtsc-NODBG powerpc powerpc64 = 1300134 1300134 >>=20 >> This media boots the 2-socket/2-cores-each G5 just fine. >>=20 >>=20 >> I tried the artifacts.ci.freebsd.org r368820 powerpc64 debug=20 >> kernel with the r365932 world and it does not have the same >> early-fail problem, but it hangs later, after (last message): >>=20 >> cryptosoft0: <software crypto> on nexus0 >>=20 >>=20 >> Unfortunately, git's main still has no artifact materials after >> r368820 so there are no official/ready-made materials to >> approximately bisect with in order to identify when the early-fail >> started. >>=20 >> r368820 did not have distinctions based on vt vs. sc. So it >> looks like I was just out of date for the status of that on >> the PowerMac7,2 system, not having tested it in so long: it >> got far beyond where it used to stop. >=20 > I've now tried the kernel in (the first 13.0-ALPHA1 there): >=20 > = https://download.freebsd.org/ftp/snapshots/powerpc/powerpc64/13.0-ALPHA1/k= ernel.txz >=20 > and it stops on the 2-socket/1-core-each G5 after the > same type of message that the earlier reports above did: >=20 > Kernel entry at 0x100580 ... >=20 > So this is a very early failure. >=20 > This debug kernel gets much farther on the 2-socket/2-cores-each > G5 but runs into what I'd guess are mismatched time issues for > sleeping and such after (boot -v style boot): >=20 > smu0: providing initial system time > start_init: trying /sbin/init >=20 > It seems to take a stab at corrupting the boot ufs file > system if one waits long enough for something more to > be displayed and /sbin/init eventually dies. fsck_ffs > seemed to fix it okay. >=20 > (Note: It is the same media, moved between machines.) >=20 When I cross-build a 3cc0c0d66a06 kernel ( so: r368820 ), even without any patches, and I use it in the 2-socket/1-core-each G5, I get the very early failure. I've not found a controlling distinction with the artifact.ci.freebsd.org build of r368820. This means that I've been unable to bisect what I reported. I used (up to some name edits): # more = ~/sys_build_scripts.amd64-host/make-GENERIC64-pure-clang-bootstrap-amd64-h= ost.sh=20 kldload -n filemon && \ script = ~/sys_typescripts/typescript_make_powerpc64_pure_clang-amd64-host-$(date = +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/dev/null" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/dev/null" TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 \ WITH_META_MODE=3Dyes \ MAKEOBJDIRPREFIX=3D"/usr/obj/powerpc64pure_clang/powerpc.powerpc64" \ KERNCONF=3DGENERIC64 \ make $* I did both kernel-toolchain and, later, buildkernel . Building other, more recent, commits got the same result. Absent artifact.ci.freebsd.org materials for various versions over the appropriate time range, it does not look like I'll be much help isolating what contributes to the very early failure on the 2-socket/1-core-each G5. I assume that the likes of: = https://download.freebsd.org/ftp/snapshots/powerpc/powerpc64/13.0-ALPHA1/k= ernel.txz and artifact.ci.freebsd.org builds are essentially equivalent when the commit involved matches. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?88B7B643-8B34-479F-8D95-EB684650F488>