Date: Wed, 23 Sep 2020 14:07:49 -0700 From: Mark Millard <marklmi@yahoo.com> To: Brandon Bergren <bdragon@FreeBSD.org> Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: head -r365932 on PowerMac G5 (2 dual-core sockets): Crashes before login prompt if powerd is enabled in /etc/rc.conf Message-ID: <B8000BA4-572E-4ADC-B7DB-2E61E961EB6B@yahoo.com> In-Reply-To: <4e63a5ee-a452-4f04-99f2-3ab99c68944c@www.fastmail.com> References: <52783D16-5DCA-45BC-9238-2518326454A1@yahoo.com> <6E99EE39-D2B8-415A-A5BF-823C0F0C22D6@yahoo.com> <cd9d2b72-219f-4550-a437-4ac3aa1da66d@www.fastmail.com> <AF27169A-00FC-4984-83C2-307EA885D7A1@yahoo.com> <11fe573a-24c3-47be-95ed-c601ec54f168@www.fastmail.com> <E23CF7F6-B69C-44C7-B356-4AB65E011268@yahoo.com> <B4D16405-1B0C-4500-866F-75F32FED235A@yahoo.com> <92f57afb-33cb-4d38-be17-4b8c81cb9c89@www.fastmail.com> <D6DC1C60-E50D-4A12-9F3B-6CEBA6A76748@yahoo.com> <6a0ade9d-26f2-4448-b066-0b06ed3ba5ef@www.fastmail.com> <9D4314E7-92C9-4BDD-B023-8C9BC3DCCAB0@yahoo.com> <E1EEDF91-42B1-4319-9513-7DE6FDE6E5F3@yahoo.com> <F1808C34-3C1A-44DC-BB23-2F0959AC64F5@yahoo.com> <db3de197-eb27-40ef-89ac-433b7fa72fe4@www.fastmail.com> <5E79BB07-D54B-4A8E-B592-F480211D0B92@yahoo.com> <88052e3f-4b79-45ca-8ebb-9fc19cbc558b@www.fastmail.com> <07E0C1EE-647C-4BFD-A60F-71B02EA3FB13@yahoo.com> <4e63a5ee-a452-4f04-99f2-3ab99c68944c@www.fastmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Sep-23, at 10:17, Brandon Bergren <bdragon@FreeBSD.org> wrote: I got around to using: = https://artifact.ci.freebsd.org/snapshot/13.0-CURRENT/r365932/powerpc/powe= rpc/ materials on another SSD to see if an official debug build would also end up failing. (boot1.elf not updated but the UFS file system rm -fr'd and then expansion of the .txz's into place.) It booted. It has been a long time since I've had a "debug boots, non-debug does not" problem. I wish there were also non-debug head builds for such cases so that I could substitute such too see if it is some build oddity of my context. (Historically all the examples were not just local to my context.) So now I can try some substitutions on the two 32-bit powerpc SSDs and see what the problem tracks. > On Wed, Sep 23, 2020, at 11:47 AM, Mark Millard wrote: >>=20 >> I've been doing things this way with the SSDs since sometime >> in 2014 on the same machines since then. I've never run into >> the problem prior to now. >=20 > OK, you would have likely tripped over it by now then if any of your = machines were affected by the bug, as it was breaking things on and off = for *years* on specific machines until I finally went in and figured out = what was ACTUALLY going on there. (FWIW, this had also been breaking = Linux for years, especially where GRUB 2 was involved.) >=20 >>>>>> FreeBSD/powerpc Open Firmware boot block >>>> Boot path: /pci@f2000000/mac-io@17/ata-4@1f000/@0: >>>> Boot loader: /boot/loader >>>> Boot volume: /pci@f2000000/mac-io@17/ata-4@1f000/@0:3 >>>> END QUOTE >>>=20 >=20 > What is your boot command? >=20 > Is it just the usual "boot hd:,\\:tbxi" or are you manually invoking = boot1? (i.e. "boot hd:2,\ppc\boot1.elf /boot/loader") Well, nvram -p reported on a G4: # grep -i boot /mnt/root/nvram.txt=20 auto-boot?=3Dtrue boot-device=3D/pci@f2000000/mac-io@17/ata-4@1f000/@0:2,\\:tbxi boot-file=3D boot-screen=3D boot-command=3Dmac-boot boot-script=3D boot-args=3D boot-once=3D boot-last-label=3DLinux But ofwdump -ap reported: # grep -i boot /mnt/root/ofwdump.txt=20 'bootrom' bootpath: '/pci@f2000000/mac-io@17/ata-4@1f000/@0:2,\134ppc\134boot1.el' bootargs: 'BootROM' supports-bootinfo: boot-syntax: Node 0xff840498: boot-rom 'boot-rom' 'Apple PowerMac3,4 4.2.8f1 BootROM built on 10/11/01 at 14:12' BootROM-version: BootROM-build-date: auto-boot?: boot-device: boot-file: boot-screen: boot-command: 'mac-boot' boot-script: boot-args: boot-once: boot-last-label: last-boot: Node 0xff858bb8: bootinfo-loader 'bootinfo-loader' Node 0xff8d6d78: bootpath-search 'bootpath-search' Node 0xff8f3660: multiboot 'multiboot' (which also answers the BootROM version for that specific PowerMac) >>=20 >> The build is my own (cross build). For the kernel I install >> on the host to a directory, tar that to a PowerMac, and >> later expand the tar to the SSD in question. Like I've been >> doing since 2014 on the same set of PowerMacs. (The procedure >> avoids the little-endian host vs. big-endian UFS on the >> PowerMacs.) >=20 > My normal procedure is to do cd release; make release TARGET=3Dpowerpc = TARGET_ARCH=3Dpowerpc KERNCONF=3DGENERIC after doing a world / kernel = build so I have fresh install media to burn to cd / usb. (Except for the = machines that netboot. For those, I just installworld = DESTDIR=3D/path/to/nfs/mount and use mergemaster to manage config file = updates) >=20 >>=20 >>> When was the last time you reinstalled boot1.hfs? >>=20 >> It been a while but this setup was working before the >> update to head -r365932 . When was the last time >> boot1.hfs had a required change? Recently? >=20 > May 1. I fixed a load address problem. Well the SSD that just booted was last used before May and so has older boot1.elf content but worked just fine. I wonder if there is a good way to check the vintage on each SSD for the issue. (I may have updated some SSDs for the May change, I'm not sure. It seems vaguely familiar.) May be looking with hd would be enough. . . . Looks like I do not have examples (hd output) of: 00 38 00 00 in appropriate places after "ELF" (prefixed with 0x7f). > Actually, now that I think about it, I think that that's actually what = you're tripping over here. It seems like identical symptoms. Okay. > See https://reviews.freebsd.org/rS360537 >=20 > This was previously only working by accident. >=20 =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?B8000BA4-572E-4ADC-B7DB-2E61E961EB6B>