FreeBSD 12.0-ALPHA4 fails to boot on POWER9/KVM

[Dennis Clarke]

On 10/11/2018 02:50 PM, Mark Millard wrote:
> On 2018-Oct-11, at 11:19 AM, Dennis Clarke <dclarke at blastwave.org> wrote:
> 
>> On 10/10/2018 11:59 PM, Nathan Whitehorn wrote:
>>> The first part of this (all the errors about "NOT FOUND") I just fixed
>>> and the fixes will be included in BETA1 and subsequent builds. The
>>> remaining issue is that virtio SCSI is not part of the standard kernel
>>> on PPC (there are some endian and DMA bugs), so you will need to use an
>>> alternative storage backend. The default storage backend (VSCSI) is
>>> fine, as are more PC-ish things like AHCI emulation.
>>> This command line will work and is otherwise equivalent to the below:
>>> qemu-system-ppc64 -enable-kvm -m 2048 -nographic -vga none -cdrom
>>> FreeBSD-12.0-ALPHA9-powerpc-powerpc64-20181009-r339271-disc1.iso
>>> /var/lib/libvirt/images/freebsd-ppc.qcow2 -mem-prealloc -mem-path
>>> /dev/hugepages -smp 2
>>> -Nathan
>>
>>
>> Has anyone tried this on a PowerMac G5 yet ?
> 
> "this"? I'm unsure if the following is addressing what you are
> referring to or not. But it might be.
> 
> Until the problems with -r334498 's adjustment to VM_MAX_KERNEL_ADDRESS
> are dealt with, PowerMac G5's have boot problems (and possibly other
> problems), at least those with multiple sockets (for what I can test).
> (I've no access to other forms of PowerMac G5's.)
> 
> See:
> 
> https://lists.freebsd.org/pipermail/freebsd-ppc/2018-October/009669.html
> 
> and later in that thread. (Earlier in the thread is likely a waste of time
> to read, given what is now known.)
> 
> My G5 contexts are operational by reverting -r334498 . The contexts are
> otherwise based on -r339076 currently.
> 
> 
> Note:
> 
> My boot test on a 8 GiByte, dual-socket, one "CPU" per socket,
> PowerMac G5 met the conditions of Andreas Tobler's requested test
> conditions and the machine boot fine (VM_MAX_KERNEL_ADDRESS near
> the RAM size, on the low side).
> 
> The G5 so-called "Quad Core"s, 4 cores total in each system but
> split evenly across 2 sockets in each), one with 12 GiByte and
> one with 16 GiByte of RAM, booted fine as well. But
> VM_MAX_KERNEL_ADDRESS was somewhat under 8GiByte and so not near
> those sizes.
> 


OKay ... that is a lot of good information and I'll sum up as "no".

Was merely curious if I should give it a try.

Dennis