Attempted to install 12.0 Release on PowerMac G5 Quad using DVD and CD created from iso images ftp'd from freebsd.org. Both boot into black screen. I also attempted to build kernel from source and upgrade FBSD 11.1, with similar results.
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.
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.
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