Modern 13 has early-fail boot for 2-socket/1-core-each PowerMac7,2 G5; r365932 boots it fine; artifact.ci r368820 hangs later

Fri Jan 15 01:39:42 UTC 2021

On 2021-Jan-13, at 14:35, Mark Millard <marklmi at 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 .
> 
> An older system that still boots (with an oddity) with is as
> follows, also showing some about the type of machine:
> 
> FreeBSD 13.0-CURRENT #18 r365932M: Tue Sep 22 13:46:46 PDT 2020
>    root at FBSDFHUGE:/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG powerpc
> FreeBSD clang version 11.0.0 (git at 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>
> 
>  model:
>    50 6f 77 65 72 4d 61 63 37 2c 32 00 
>    'PowerMac7,2'
> 
>      cpu-version:
>        00 39 02 02 
> 
>      model:
>        41 70 70 6c 65 20 50 6f 77 65 72 4d 61 63 37 2c 32 20 35 2e 
>        31 2e 34 66 30 20 42 6f 6f 74 52 4f 4d 20 62 75 69 6c 74 20 
>        6f 6e 20 31 31 2f 32 31 2f 30 33 20 61 74 20 31 37 3a 34 31 
>        3a 34 38 00 
>        '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 
>        '$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 
>        00 
>        '11/21/03 at 17:41:48'
> 
> # uname -apKU
> FreeBSD FBSDG5L2 13.0-CURRENT FreeBSD 13.0-CURRENT #18 r365932M: Tue Sep 22 13:46:46 PDT 2020     root at FBSDFHUGE:/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG  powerpc powerpc64 1300115 1300115
> 
> The above has my normal patches involved and is a non-debug
> build.
> 
> The oddity in this boot is that the following sequence
> happens each time:
> 
> . . .
> 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.
> 
> Loader variables:
>  vfs.root.mountfrom=ufs:/dev/ufs/FBSDG5L2rootfs
>  vfs.root.mountfrom.options=rw,noatime
> 
> Manual root filesystem specification:
>  <fstype>:<device> [options]
>      Mount <device> using filesystem <fstype>
>      and with the specified (optional) option list.
> 
>    eg. ufs:/dev/da0s1a
>        zfs:zroot/ROOT/default
>        cd9660:/dev/cd0 ro
>          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
> 
>  ?               List valid disk boot devices
>  .               Yield 1 second (for background tasks)
>  <empty line>    Abort manual input
> 
> mountroot> 
> List of GEOM managed disk devices:
>  label/FBSDG5LBswap ufs/FBSDG5LBrootfs cd0 ada0s4 ada0s3 ada0s2 ada0
> 
> 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
> . . .
> 
> (Despite what is shown, I did type "ufs:/dev/ufs/FBSDG5LBrootfs".)
> 
> 
> The early-fail media is based on main's 19cca0b9613d (but with my patches
> involved):
> 
> # ~/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
> 
> This media boots the 2-socket/2-cores-each G5 just fine.
> 
> 
> I tried the artifacts.ci.freebsd.org r368820 powerpc64 debug 
> kernel with the r365932 world and it does not have the same
> early-fail problem, but it hangs later, after (last message):
> 
> cryptosoft0: <software crypto> on nexus0
> 
> 
> 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.
> 
> 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/kernel.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.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)