Bug 235060

While I do understand the frustration of downloading a "release" DVD
or CD install image and then receiving a less than perfect result
it should be said that the Apple PowerMac G5 Quad ( and similar ) is
an artifact of historical computing machinery interest and not a
current system architecture.  Whereas one may also claim that the IBM
Power architecture is very current and of very significant interest.
This does mean to say that the now ancient IBM RS/6000 Model 7317 is
not to be considered a production class machine. It was based on the
now twenty year old IBM PPC 604e and it is a fascinating system to 
perform experiments with but merely as an artifact. A reasonable and
even modern software system with very modern ZFS implementation would
be nearly impossible to run effectively on such hardware. The more
fascinating IBM PPC 970MP based Apple PowerMac G5 11,2 models are now
well over a decade old and face a similar problem. They are simply not
at all to be considered "production" class or "tier 1" type systems.

A lot of work has happened to keep such machines runnable in various
software projects and they even provide interesting data regarding low
level compiler functions but extensive testing simply is not possible
for any variation of "production" or "tier 1" level functions. Myself
and Justin Hibbits and others have done fairly extensive testing of
the FreeBSD release candidate DVD images and found that some minor
adjustments to the boot loader stage are required in order to get a
reasonable installation to work. For an example please see : 

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233579#c7

At this time there should be a warning on the FreeBSD PPC project page
which illustrates that systems such as the Apple PowerMac G5 and even
older IBM RS/6000 units may not work as expected. A more modern class
of system such as the IBM POWER9 based Talos would be expected to work
as a very reasonable day to day unit and yet it is still "tier 2". 

-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Actually .. these things may happen as r343862 iso dvd is not
bootable at all on that hardware.

I have done a test and neatly installed 12.0-RELEASE r341666 GENERIC
on a PowerMac G5 quad 11,2 thus :

hydra# uptime
 8:26AM  up 7 mins, 1 user, load averages: 0.19, 0.23, 0.16
hydra# 

hydra# sysctl hw.ncpu
hw.ncpu: 4

hydra# dmesg 
---<<BOOT>>---
Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-RELEASE r341666 GENERIC powerpc
gcc version 4.2.1 20070831 patched [FreeBSD]
VT(ofwfb): resolution 1280x1024
cpu0: IBM PowerPC 970MP revision 1.1, 2500.34 MHz
cpu0: Features dc000000<PPC32,PPC64,ALTIVEC,FPU,MMU>
cpu0: HID0 1511081<DEEPNAP,NAP,DPM,NHR,TBEN,ENATTN>
real memory  = 8542404608 (8146 MB)
avail memory = 8152752128 (7775 MB)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
random: unblocking device.
random: entropy device external interface
kbd0 at kbdmux0
ofwbus0: <Open Firmware Device Tree> on nexus0
cpulist0: <Open Firmware CPU Group> on ofwbus0
cpu0: <Open Firmware CPU> on cpulist0
pcr0: <PPC 970 Power Control Register> on cpu0
cpu1: <Open Firmware CPU> on cpulist0
pcr1: <PPC 970 Power Control Register> on cpu1
cpu2: <Open Firmware CPU> on cpulist0
pcr2: <PPC 970 Power Control Register> on cpu2
cpu3: <Open Firmware CPU> on cpulist0
pcr3: <PPC 970 Power Control Register> on cpu3
powermac_nvram0: <Apple NVRAM> mem 0xfff04000-0xfff07fff on ofwbus0
powermac_nvram0: bank0 generation 460, bank1 generation 461
unin0: <Apple UniNorth System Controller> mem 0xf8000000-0xf8ffffff on ofwbus0
unin0: Version 66
iichb0: <Keywest I2C controller> mem 0xf8001000-0xf8001fff irq 0 on unin0
iicbus0: <OFW I2C bus> on iichb0
iic0: <I2C generic I/O> on iicbus0
ds17750: <Temp-Monitor DS1775> at addr 0x94 on iicbus0
ds16310: <Temp-Monitor DS1631> at addr 0x96 on iicbus0
max66900: <Temp-Monitor MAX6690> at addr 0x98 on iicbus0
max66901: <Temp-Monitor MAX6690> at addr 0x9c on iicbus0
htpic0: <OpenPIC Interrupt Controller> mem 0xf8040000-0xf807ffff on unin0
pcib0: <IBM CPC945 PCI Express Root> mem 0xf0000000-0xf1ffffff on ofwbus0
pci0: <OFW PCI bus> on pcib0
vgapci0: <VGA-compatible display> mem 0xa1000000-0xa1ffffff,0x90000000-0x9fffffff,0xa0000000-0xa0ffffff irq 3 at device 0.0 on pci0
vgapci0: Boot video device
pcib1: <IBM CPC9X5 HyperTransport Tunnel> mem 0xf2000000-0xf47fffff,0xf8070000-0xf8070fff on ofwbus0
pcib1: 86 HT IRQs on device 7.0
pci1: <OFW PCI bus> on pcib1
pcib1: Enabling MSI window for HyperTransport slave at pci1:0:1:0
pcib2: <OFW PCI-PCI bridge> at device 1.0 on pci1
pci2: <OFW PCI bus> on pcib2
pcib3: <OFW PCI-PCI bridge> at device 2.0 on pci1
pci3: <OFW PCI bus> on pcib3
bge0: <Broadcom BCM5714 B3, ASIC rev. 0x008003> mem 0xfa530000-0xfa53ffff,0xfa520000-0xfa52ffff irq 66 at device 4.0 on pci3
bge0: CHIP ID 0x00008003; ASIC REV 0x08; CHIP REV 0x80; PCI-X 33 MHz
miibus0: <MII bus> on bge0
brgphy0: <BCM5780 1000BASE-T media interface> PHY 1 on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
bge0: Ethernet address: 00:14:51:64:67:10
bge1: <Broadcom BCM5714 B3, ASIC rev. 0x008003> mem 0xfa510000-0xfa51ffff,0xfa500000-0xfa50ffff irq 67 at device 4.1 on pci3
bge1: CHIP ID 0x00008003; ASIC REV 0x08; CHIP REV 0x80; PCI-X 33 MHz
miibus1: <MII bus> on bge1
brgphy1: <BCM5780 1000BASE-T media interface> PHY 1 on miibus1
brgphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
bge1: Ethernet address: 00:14:51:64:67:11
pcib4: <OFW PCI-PCI bridge> at device 3.0 on pci1
pci4: <OFW PCI bus> on pcib4
pcib5: <OFW PCI-PCI bridge> at device 4.0 on pci1
pci5: <OFW PCI bus> on pcib5
pcib6: <OFW PCI-PCI bridge> at device 5.0 on pci1
pci6: <OFW PCI bus> on pcib6
pcib7: <OFW PCI-PCI bridge> at device 6.0 on pci1
pci7: <OFW PCI bus> on pcib7
pcib8: <OFW PCI-PCI bridge> at device 7.0 on pci1
pci8: <OFW PCI bus> on pcib8
gem0: <Apple Shasta GMAC Ethernet> mem 0xfa200000-0xfa3fffff at device 15.0 on pci8
gem0: invalid MAC address
device_attach: gem0 attach returned 6
pcib9: <OFW PCI-PCI bridge> at device 8.0 on pci1
pci9: <OFW PCI bus> on pcib9
macio0: <Shasta I/O Controller> mem 0x80000000-0x8007ffff at device 7.0 on pci9
macgpio0: <MacIO GPIO Controller> mem 0x50-0x8a on macio0
scc0: <Zilog Z8530 dual channel SCC> mem 0x13000-0x13fff,0x8400-0x84ff,0x8500-0x85ff,0x8600-0x86ff,0x8700-0x87ff irq 23,17,18,24,19,20 on macio0
uart0: <z8530, channel A> on scc0
uart1: <z8530, channel B> on scc0
iichb1: <Keywest I2C controller> mem 0x18000-0x18fff irq 27 on macio0
iicbus1: <OFW I2C bus> on iichb1
iic1: <I2C generic I/O> on iicbus1
onyx0: <Texas Instruments PCM3052 Audio Codec> at addr 0x8c on iicbus1
iicbus1: <unknown card> at addr 0x24
pcm0: <Apple I2S Audio Controller> mem 0x10000-0x10fff,0x8000-0x80ff,0x8100-0x81ff irq 28,11,12,30,15,16 on macio0
ohci0: <NEC uPD 9210 USB controller> mem 0x80082000-0x80082fff irq 70 at device 11.0 on pci9
usbus0 on ohci0
ohci1: <NEC uPD 9210 USB controller> mem 0x80081000-0x80081fff irq 70 at device 11.1 on pci9
usbus1 on ohci1
ehci0: <NEC uPD 72010x USB 2.0 controller> mem 0x80080000-0x800800ff irq 70 at device 11.2 on pci9
usbus2: EHCI version 1.0
usbus2 on ehci0
pcib10: <OFW PCI-PCI bridge> at device 9.0 on pci1
pci10: <OFW PCI bus> on pcib10
atapci0: <ServerWorks K2 SATA150 controller> mem 0xfa402000-0xfa403fff irq 10 at device 12.0 on pci10
pcib1: failed to reserve resource for pcib10
atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, 0xffffffffffffffff).
ata2: <ATA channel> at channel 0 on atapci0
ata3: <ATA channel> at channel 1 on atapci0
ata4: <ATA channel> at channel 2 on atapci0
ata5: <ATA channel> at channel 3 on atapci0
ata0: <Shasta Kauai ATA Controller> mem 0xfa404000-0xfa407fff irq 38,37 at device 13.0 on pci10
fwohci0: <1394 Open Host Controller Interface> mem 0xfa400000-0xfa400fff irq 39 at device 14.0 on pci10
fwohci0: OHCI version 1.0 (ROM=0)
fwohci0: No. of Isochronous channels is 8.
fwohci0: EUI64 00:11:24:ff:fe:e5:13:d0
fwohci0: invalid speed 7 (fixed to 3).
fwohci0: Phy 1394a available S800, 3 ports.
fwohci0: Link S800, max_rec 4096 bytes.
firewire0: <IEEE1394(FireWire) bus> on fwohci0
fwe0: <Ethernet over FireWire> on firewire0
if_fwe0: Fake Ethernet address: 02:11:24:e5:13:d0
fwe0: Ethernet address: 02:11:24:e5:13:d0
sbp0: <SBP-2/SCSI over FireWire> on firewire0
fwohci0: Initiate bus reset
fwohci0: fwohci_intr_core: BUS reset
fwohci0: PhysicalUpperBound register is not implemented.  Physical memory access is limited to the first 4GB
fwohci0: PhysicalUpperBound = 0x00000000
fwohci0: fwohci_intr_core: node_id=0x00000001, SelfID Count=1, CYCLEMASTER mode
smu0: <Apple System Management Unit> on ofwbus0
smu0: registered as a time-of-day clock, resolution 0.001000s
iichb2: <SMU I2C controller> on smu0
iicbus2: <OFW I2C bus> on iichb2
iic2: <I2C generic I/O> on iicbus2
smusat0: <SMU Satellite Sensors> at addr 0xb0 on iicbus2
smusat1: <SMU Satellite Sensors> at addr 0xb2 on iicbus2
iicbus2: <unknown card> at addr 0xd4
iichb3: <SMU I2C controller> on smu0
iicbus3: <OFW I2C bus> on iichb3
iic3: <I2C generic I/O> on iicbus3
Timecounter "timebase" frequency 33333333 Hz quality 0
Event timer "decrementer" frequency 33333333 Hz quality 1000
Timecounters tick every 1.000 msec
firewire0: 2 nodes, maxhop <= 1 cable IRM irm(1)  (me) 
firewire0: bus manager 1 
bge0: link state changed to UP
max66900: 2 sensors detected.
usbus0: 12Mbps Full Speed USB v1.0
usbus1: 12Mbps Full Speed USB v1.0
max66901: 2 sensors detected.
ugen1.1: <NEC OHCI root HUB> at usbus1
uhub0: <NEC OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
ugen0.1: <NEC OHCI root HUB> at usbus0
uhub1: <NEC OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
usbus2: 480Mbps High Speed USB v2.0
ugen2.1: <NEC EHCI root HUB> at usbus2
uhub2: <NEC EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2
uhub0: 2 ports with 2 removable, self powered
uhub1: 3 ports with 3 removable, self powered
uhub2: 5 ports with 5 removable, self powered
ada0 at ata2 bus 0 scbus0 target 0 lun 0
ada0: <ST380013AS 3.00> ATA-6 SATA 1.x device
ada0: Serial Number 4MR3C8TG
ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
ada0: 76319MB (156301488 512 byte sectors)
SMP: AP CPU #1 launched
SMP: AP CPU #3 launched
SMP: AP CPU #2 launched
Trying to mount root from ufs:/dev/ada0s3 [rw]...
cd0 at ata0 bus 0 scbus4 target 0 lun 0
cd0: <HL-DT-ST DVD-RW GWA-4165B C006> Removable CD-ROM SCSI device
cd0: Serial Number M0063NE3358
cd0: 66.700MB/s transfers (UDMA4, ATAPI 12bytes, PIO 65534bytes)
cd0: 4482MB (2295104 2048 byte sectors)
ugen2.2: <Western Digital My Passport 0748> at usbus2
umass0 on uhub2
umass0: <MSC Bulk-Only Transport> on usbus2
umass0:  SCSI over Bulk-Only; quirks = 0x4000
umass0:6:0: Attached to scbus6
da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
da0: <WD My Passport 0748 1010> Fixed Direct Access SPC-4 SCSI device
da0: Serial Number 575857314342313333363530
da0: 40.000MB/s transfers
da0: 1907697MB (3906963456 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>
ugen1.2: <Lite-On Technology Corp. USB Multimedia Keyboard> at usbus1
ukbd0 on uhub0
ukbd0: <Lite-On Technology Corp. USB Multimedia Keyboard, class 0/0, rev 1.10/1.04, addr 2> on usbus1
kbd1 at ukbd0
uhid0 on uhub0
uhid0: <Lite-On Technology Corp. USB Multimedia Keyboard, class 0/0, rev 1.10/1.04, addr 2> on usbus1
lo0: link state changed to UP
bge0: link state changed to DOWN
bge0: link state changed to UP
module_register: cannot register gem/miibus from if_gem.ko; already loaded from kernel
Module gem/miibus failed to register: 17
module_register: cannot register pci/gem from if_gem.ko; already loaded from kernel
Module pci/gem failed to register: 17
hydra#

I have tested with usefdt=1 and I see a kernel panic.
Given that I had to capture the panic data from usefdt with
a camera I will doucment that tomorrow. 


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

I think we could re-release another dvd install image with
a loader.conf config that sets kern.smp.disabled=1 as a manner to 
deal with troublesome install hardware.

Maybe it just the system I'm using, but setting kern.smp.disabled=1 does not work at all.   This applies the 12-RELEASE r341666 ISO or any earlier candidate releases.  

Through trial and error, I've only been able to get snapshot head r341614 (13-CURRENT) to boot, as previously noted by Mark Millard.

Any ideas?

(In reply to Curtis Hamilton from comment #5)

You might want to report how much RAM for the system showing the
problem. I'm not aware of anything else likely to contribute to
variations for the G5 4-core (system total). I'd reported in list
messages for 16 GiBytes and 12 GiBytes when requested. Also for a
2-processor (one core each): 8 GiBytes.

Almost all my activity has been with the 16 GiByte case.

(In reply to Mark Millard from comment #6)
The system I'm using has 16 GiBytes RAM.

Same for me. Power Mac G5 quad, 16 GB

Yesterday, I did a buildworld and buildkernel with from releng-12.0 with the same result (black screen)

The no boot bug of FreeBSD DVD image is most like caused by an "activated Intel Management Engine bit pattern" included in the bootloader of the image. I did a lot of tests, including trying to boot the DVD image from a clone hard disk. I have figured out a similar "Intel Management Engine bit pattern" in the boot loader of the Parrot Security Linux DVD image. Compare https://forums.freebsd.org/threads/freebsd-12-0-for-ppc-does-not-support-my-dvd-rom-cant-install.70288/ .

Cheers

(In reply to consuli074 from comment #9)

PowerMacs are PowerPC-based systems, not Intel-processor-based
systems. Apple did not switch to Intel until after the PowerMac
systems. There is no "Intel Management Engine" on PowerMacs.

Exactly. The architecture of Apple G5 PPC 64bit RISC CPU is pretty different from AMD64 architecture. This is why a bit pattern that does not recognizable effect on an Intel CPU can cause the open firmware of RISC CPU hang up.

The machine's specs are

Apple G5 PowerPC Dual Core
Firmware 5.1
4 GB RAM
(OS-X 10.5.4 Leopard)

Get your hand on a similar 64bit PowerPC, try to boot your FreeBSD images and ty to copy the boot loader of a burnt DVD under OS-X. Both should fail.

(In reply to consuli074 from comment #11)

I (at times) have access to 3 PowerMac G5s, 4 PowerMac G4s,
and 1 iMac G3. I sometimes help identify boot problems and
fixes for them. I'm familiar enough with what is required
to do so with some success. (I've been doing so via my own
FreeBSD builds, including self hosted. My PowerMacs do boot,
but I do not use CD media in my normal process.)

However, you have not pointed out evidence that someone else
could follow for your claims. They would have to start from
scratch and I'll not attempt that. The mere fact that booting
would fail is not a confirmation of your specific claims.
There are other possibilities, given your lack of detail.

What is the "bit pattern"? Where is it specifically in some
specific thing (specific example of the problem)? Sufficient
information  or someone to inspect for themselves for a
specific example? And so on. Is burning from MacOSX really
required or do other forms of burning produce the problem?
Were you over specific in that detail?

Have you ever looked up what the "bit pattern" means on the
processor that you have: how would the PPC involved interpret
it? (I've assumed here that it is in a area holding machine
code that would be executed. But I've no idea how to find
it so I'm not sure.)

(In reply to Mark Millard from comment #12)

I have multiple of these old ppc64 G5 units nearby and two of them
running well. One of them is the so-called "quad" and then other has
two processors that are single core. I don't know the model name.
Regardless I stand by the suggestion that these are historical computing
artifacts which are merely popular due to the fact they are dirt cheap
and in the back of everyones warehouse gathering dust.

There are other items of greater interest at this time than the boot or
no boot issue with some release DVD.  However I can try both my PowerMac
units later today or tomorrow. 

Also see : 

Various PowerMac G5 models may require kern.smp.disabled=1 and must set usefdt=1 which causes net interface reorder
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233863

Bug 233579 - ppc64 r341455 will panic on boot with usefdt=1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233579


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

(In reply to Dennis Clarke from comment #13)

I think that it is important to have easily accesible Big Endian machines available to easily test FreeBSD on. I don't have a preference which ones. Currently, the POWER9 machines are not easily accessible. There are not many alternatives currently. The Cavium Octeon MIPS64 used on Ubiquiti Edge Router Lite is prohibitively slow. It is possible that newer ARM64 devices be programmed in Big Endian mode but nobody seems to do this in Linux or BSD. I think this should be considered since it provides modern hardware at cheap prices and is getting better not aging out.

(In reply to Dennis Clarke from comment #13)

First my overall point, then what leads to it . . .

Overall point:

I'm not sure testing anything with head -r334498
involved is worth testing for multi-socket or for
multi-core unless the code has been changed to
address the resultant slb-miss issue on the
non-bsp cpu(s) in some way.

What leads to that:

I'll note that anything form just svn at or
after head -r334498 (or later in svn that is
derived from such) has known boot problems on
at least some G5 PowerMacs that have multiple
sockets or cores. The issue in question is an
unhandled slb miss in the code during a
(non-bsp) cpu's startup code when it executes:

sp = pcpup->pc_curpcb->pcb_sp

It is the pc_curpcb based dereference that
can end up with a slb miss before things
are set up sufficiently for that processor
to correctly handle such misses.

head -r334498 changed the address ranges used
for powerpc64 and indirectly resulted in this
being possible on some old G5 PowerMacs.
(32-bit powerpc FreeBSD boots of old G5's
are a separate issue.)

I'm not here making any claims about there not
being other boot problems sometimes involved.
But, to my knowledge, all builds based on just
checked-in source code that has -r334498
involved has multi-socket/multi-core boot
problems. (They can be intermittent, sometimes
hanging-up and other times not, depending on
slb content at the time.)

Bugzilla 233863 that you reference has a
fair amount of accumulated information, but not
limited to fixing what -r334498 exposes about
the way things historically worked, so it is a
bit of a mess to go through for the slb issue.

Well, the only thing which is similar to reproducible make a CPU firmware hang up (so that it does not boot anything any more until the power cord is removed!) and to reproducible make a copy process hang up, that I know are these old school copy protection of games DVDs in the 2000 era. Some of these copy protections also included nasty bit patterns, that hung the copy process up. As FreeBSD images do not have copy protection, the next best thing that might produce nasty bit patterns is the Intel management engine (or the AMD security processor, resprectively).

My overall point is, that this bit patterns most probably are a generell security problem. Especially that those bit patterns might designed to operate some nasty switches in the Minix OS of Intel CPUs. If you FreeBSD guys want to provide a security OS, you should go after it. At least to the point, how to keep them away from your own iso images. I mean, security is the main reason why people use FreeBSD instead of Linux, isn't it?   

If you provided me a tool to search for nasty bit patterns, I will try to assist your search. However, I am not programmer, thus pretty stupid in these kind of things, I am afraid.

Hi, not sure if its useful,

I have just installed 12.0-RELEASE - using: FreeBSD-12.0-RELEASE-powerpc-powerpc64-disc1.iso - on a PowerMac G5 Quad with 8GB Ram, the system booted from the CD and installed fine with no intervention.

On rebooting after the install, I had to set usefdt=1 to get it to boot as the system would just freeze part way through the kernel loading.

(In reply to consuli074 from comment #16)

So you do not have any specific evidence of any
specific problem "bit patterns" existing but just
a hypothesis.

I'm not up for such an open-ended activity as
investigating your hypothesis or helping you
do so. If there ever was something already-identified
as something-specific to look at I might do that.

Francis Little reports in comment #17 having
successfully booted from:

FreeBSD-12.0-RELEASE-powerpc-powerpc64-disc1.iso

on a CD on a PowerMac G5 "quad". Also having installed
from it. (This would not eliminate intermittent
problems as a possibility and may indicate a dependence
on what has been installed in the various machines
folks have tried. There is also the question of how
various CDs were produced from .iso files that could
be involved.)

He also reports on later boots needing to set usefdt=1
first --but that is what bugzilla 233863 and the
patches there are about. But the content is not designed
for a non-programmer so it is not clear that going
there would help. But, for reference,

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233863

Also does not hurt to look at : 

Bug 233579 - ppc64 r341455 will panic on boot with usefdt=1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233579

However I think that flat device tree is the way forward. 
An entirely perpendicular issue here is to enforce usefdt
within the install images.  But let's not wander off topic.

Of course it is up to you developers to drive your product into the direction you want.

Finally, I just want to add one thing:

My Apple G5 machine also hangs up when trying to copy the FreeBSD 12.0 iso image for AMD64 platform (in OS-X 10.5.4). I tried the image I have downloaded and another one, which was supplemented on a DVD in a german computer magazine. So  for the last one I can defintely exclude any errors of my machines.

Comment 21 Justin Hibbits 2019-04-30 16:22:05 UTC

Hi Curtis.  It's been reported that less memory actually makes the PowerMac G5 boot correctly.  I'm trying to understand why Mark's SLB hack is necessary, since it should logically be necessary on any other AIM-architecture platform, including my POWER9, so I'm really confused.  Unfortunately, my G5 no longer works, and actually died shortly before I committed the change that reportedly broke G5s.  I was/still am hoping that someone could go beyond Mark's diving, and determine just why the APs can't handle SLB faults at that point in the boot process, because they really should be able to.

kern.smp.disabled=1 should make any G5 boot correctly, but then you're obviously stuck with only a single CPU.

To stay exact for the FreeBSD 12.0 >>AMD64<< DVD iso images (the one I downloaded and the one supplemented on the DVD in a commputer magazine):

These DVDs cannot be mounted under OS-X-10.5.4 on my machine, thus cannot not be read. (I mixed it up a little.)

It should be an easy task for you to replicate this error on your G5 machines under OS-X (or not).

(In reply to consuli074 from comment #22)

Hi so I have a G5 Quad and today I downloaded the AMD64 iamge and yes, double clicking it, it will not open in the finder, but it shouldn't be opened in the finder.

It should be burned with Disk Utility to create a working bootable CD or DVD.

So on my G5, booted in to OS 10.5.8:

Inserted a blank DVD-R.
Finder asked if I wanted to open the DVD-R in finder, I selected Ignore.
Right-Clicked the FreeBSD 12 AMD64 iso, selected Open With and Disk Utility.
Disk Utility opened, I selected the FreeBSD ISO now listed in the left of Disk Utility, then selcted Burn at the top.
The ISO was written to the DVD.

Being this is the AMD64 ISO, I removed the DVD-R from the Mac and put it in a Dell, Intel core i3, and it booted to the FreeBSD installer.

The same process also worked for a FreeBSD powerpc64 iso that I installed with the other day.

Can I suggest you double check how you are trying to write ISO images to DVD / CD's?

Regards

And if you burn the FreeBSD 12.0 AMD64 iso image BY AN INTEL MACHINE on DVD (as I did), is the burnt DVD still mountable and readable from OS-X/ PPC machine then?

You can call me burning DVDs wrong.

But how do you explain the same "not mountable error" of the FreeBSD 12.0 AMD64 DVD, that was supplemented in german computer magazine?

Do you want screenshots of all the errors?

(In reply to consuli074 from comment #24)

Most modern ISO images for AMD64 are hybrid images and be written as both DVD-R's or to USB sticks.

The Last update to Mac OS X 10.5, 10.5.8 was released in August 2009, it is nearly 10 years old, and it appears the finder does not support mounting these images.

The modern Ubuntu ISO's for example, will give the same error - specifically I tried:

ubuntu-18.04-2-desktop-amd64.iso

Like the FreeBSD ISO, the Ubuntu ISO won't open in finder, but can still be burned to a DVD-R using Disk Utility.

And if you burn the >>>FreeBSD 12.0 AMD64 iso image<<< BY AN INTEL MACHINE on DVD (as I did), is the burnt DVD still mountable and readable from OS-X/ PPC machine then?

FreeBSD has separate images for DVD and USB stick (not hybrid ones), as far as I know.

(In reply to Curtis Hamilton from comment #0)

The technical problem has been identified and
head -r347463 has a fix, listed as to be MFC'd
in a couple of weeks. See Justin's fix in:

https://lists.freebsd.org/pipermail/svn-src-head/2019-May/124910.html

So far 2 people have reported to me that the change
has fixed the booting problems they were having on their
multi-socket or multi-core PowerMac G5s (970 family
of processors).

The change is in code only used for when there are
multiple 970 cpus involved (in FreeBSD terms for "cpu").


Technically, I think this bugzilla report will end up being
declared as a duplicate of:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233863

that is now "in progress" for the change. It also has
patches for issues found during exploring/investigating
what all was blocking various machines from booting in
various modes. I'm not so sure those other issues will
be handled as part of the resolution: it will probably
be viewed as a narrower, more specific report.

(In reply to Mark Millard from comment #28)

It is my sad duty to report that this issue also exists in r350103
however one *may* be able to boot with usefdt=1.

Even kern.smp.disabled=1 has no effect on the ability to boot. 


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

(In reply to Dennis Clarke from comment #29)

Quoting some from what Dennis reported elsewhere
to give some context on ho to reproduce what he
is now reporting:

QUOTE
. . . I [...] fetched the snapshot dvd :

http://ftp.freebsd.org/pub/FreeBSD/snapshots/powerpc/powerpc64/ISO-IMAGES/13.0/FreeBSD-13.0-CURRENT-powerpc-powerpc64-20190718-r350103-disc1.iso

I carefully burned it to a DVD-RW and then used readcd to read back in
the data from the DVD-RW and did a sha512 hash check compare. Perfect.

I can confirm that usefdt=1 is required. Any attempt to boot that dvd
without that wwill provide a black screen and fans roaring. I did also
try kern.smp.disabled=1 by itself. Blank screen. Fans roaring.
END QUOTE

I've no clue at this point if use of materials from:

https://artifact.ci.freebsd.org/snapshot/head/r350103/powerpc/powerpc64/

would also reproduce the problem vs. not.

Comment 31 Graham Perrin 2023-03-22 22:16:04 UTC

Is this still an issue with any current RELEASE or pre-release version of FreeBSD?

(In reply to Graham Perrin from comment #31)
Unfortunately it is still an Issue, Starting with Release 13.0, FreeBSD is unusable on this platform.

12.4 Boots and installs just fine.

13.0 Kernel loads but painfully slow, very similar behaviour to Sergey's issue.
Loads normally until "Root mount waiting for: usbus2" then fans are roaring and takes forever to get to the Install menu.

13.1 Pretty much the same as 13.0, except even worse as it simply reboots on its own from time to time.

13.2 Doesn't load at all, Black screen with fans roaring immediately.

14.0 Latest Snapshot, Same observation as 13.2.

I've also commented on https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271826