Date: Thu, 14 Jan 2021 17:39:33 -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: <02EACD59-674C-49F2-8E68-D08A33BC4523@yahoo.com> In-Reply-To: <C503A323-A82A-49E1-9F71-3155F9A30ADD@yahoo.com> References: <C503A323-A82A-49E1-9F71-3155F9A30ADD@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Jan-13, at 14:35, Mark Millard <marklmi@yahoo.com> wrote: > 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. I've now tried the kernel in (the first 13.0-ALPHA1 there): = https://download.freebsd.org/ftp/snapshots/powerpc/powerpc64/13.0-ALPHA1/k= ernel.txz and it stops on the 2-socket/1-core-each G5 after the same type of message that the earlier reports above did: Kernel entry at 0x100580 ... So this is a very early failure. 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): smu0: providing initial system time start_init: trying /sbin/init 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. (Note: It is the same media, moved between machines.) =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?02EACD59-674C-49F2-8E68-D08A33BC4523>