Re: FreeBSD 12.0-ALPHA4 fails to boot on POWER9/KVM

In order to get this working with libvirt/virt-manager, simply do:
virsh edit <guest-name>

And add the following under your "<domain type='kvm'>" line.
   <memoryBacking>
     <hugepages/>
   </memoryBacking>

Apparently you can turn this further, but this little snippet is enough.

I had to use "virsh edit" to force remove the VGA device to get a serial 
console to see what was going on.

I/O seems really slow... I booted into a non-debug kernel, but that 
didn't seem to make much of a difference. Anyone know how much of this 
due to not supporting virtio yet vs lack of optimization for PPC/PPC64?

Anyway, the last issue for me, and it's not major, is that shutting down 
doesn't work. Ie, "virsh shutdown <guestname>" simply doesn't do 
anything. Shutting down from within the guest itself works fine though, 
so I guess this isn't a HUGE issue.

Anyway, I hope this all eventually helps someone.

Thanks!

-Cameron

On 10/13/2018 04:18 PM, Cameron Berkenpas wrote:
> Whoops, that would be:
>
> make buildworld buildkernel TARGET=powerpc TARGET_ARCH=powerpc64
> make cdrom TARGET=powerpc TARGET_ARCH=powerpc64
>
>
> Good catch. Turns out that's the bootloader of my install that no 
> longer boots...
>
> So you can either manually select to boot from the cd-rom in the 
> firmware, or here's how to boot from the cd-rom via kvm/qemu:
> qemu-system-ppc64 -enable-kvm -m 2048 -nographic -vga none -boot 
> order=d -cdrom bootonly.iso -drive 
> file=/var/lib/libvirt/images/freebsd-ppc.qcow2,format=qcow2 
> -mem-prealloc -mem-path /dev/hugepages -smp 2
>
> Then after installing, of course remove the '-boot' option and its 
> argument to boot from the disk.
>
> Interestingly, disc1.iso still won't boot:
> Trying to load:  from: /vdevice/v-scsi@71000003/disk@8200000000000000 
> ... failed to load CHRP boot loader.failed to load CHRP boot loader.
> E3404: Not a bootable device!
>
> There's probably something wrong with my disc1.iso. 
> FreeBSD-12.0-ALPHA9-powerpc-powerpc64-20181009-r339271-disc1.iso boots 
> successfully in spite of the "NOT FOUND" errors.
>
> My earlier attempts with bootonly.iso failed due to some foolishness 
> on my part. The above examples will work.
>
> However, during the install, I'm getting a checksum error with 
> base.txz. Looking at the MANIFEST, it seems correct.
>
> I used the ALPHA9 ISO and was able to install successfully. Anyway, 
> just remember to use the MBR partition scheme or your install won't boot.
>
> I still can't get FreeBSD to boot through virt-manager/libvirt, but 
> I'm still trying to see if I get that working too.
>
> -Cameron
>
> On 10/13/2018 01:08 PM, Nathan Whitehorn wrote:
>>
>> On 10/13/18 12:53 PM, Cameron Berkenpas wrote:
>>> Hello,
>>>
>>> Finally had some time to spin up my own ISO from 12-CURRENT.
>>> Unfortunately, it still fails. Looks like there's no real change from
>>> before.
>>>
>>> # This is how I built the cdrom image:
>>> make cdrom TARGET=powerpc TARGET_ARCH=powerpc64
>>> make cdrom TARGET=powerpc TARGET_ARCH=powerpc64
>>>
>>> I tried this with revision r339340.
>> [...]
>>
>>>>> FreeBSD/powerpc Open Firmware boot block
>>>     Boot path: /pci@800000020000000/scsi@7/disk@100000100000000
>>>     Boot loader: /boot/loader
>>>     Boot volume: /pci@800000020000000/scsi@7/disk@100000100000000:2
>>> Consoles: Open Firmware console
>>>
>>> FreeBSD/powerpc64 Open Firmware loader, Revision 0.1
>>> (Sun Aug 19 13:30:54 PDT 2018 root@freebsd-ppc)
>>
>> I think you aren't using the loader you think you are using judging by
>> the date above.
>> -Nathan
>>
>>> Memory: 2097152KB
>>> Booted from: /pci@800000020000000/scsi@7/disk@100000100000000
>>>
>>>
>>> block-size NOT FOUND
>>> #blocks NOT FOUND|
>>> block-size NOT FOUND
>>> #blocks NOT FOUND\
>>> block-size NOT FOUND
>>> #blocks NOT FOUND
>>>
>>> ( 700 ) Program Exception [ 0 ]
>>>
>>>
>>>      R0 .. R7           R8 .. R15         R16 .. R23 R24 .. R31
>>> 0000000000000040   000000000345cdc4   ffffffffffffffff 0000000002c50468
>>> 0000000002c548c0   0000000000000000   0000000002c56ba0 0000000002c513a0
>>> 0000000000000000   0000000002c67780   0000000002c56b98 0000000002c51c18
>>> 000000000345d8f0   0000000002c67300   0000000002c62200 000000000345d8f0
>>> 0000000002c67340   0000000020000048   000000000040e78e 0000000000000000
>>> 0000000000000000   0000000000000000   0000000001802118 0000000000000000
>>> 0000000000000040   0000000002c4baec   0000000002c71980 0000000000000000
>>> 0000000000000040   000000007fffffff   0000000002c5bb84 000000000345d8f0
>>>
>>>      CR / XER           LR / CTR          SRR0 / SRR1 DAR / DSISR
>>>          80000044   0000000002c02938   0000000000000000 
>>> 0000000000000000
>>> 0000000020040000   0000000000000000   0000000000083000 00000000
>>>
>>>
>>> e >
>>>
>>> Hope this is helpful!
>>>
>>> On 10/11/2018 12:00 PM, Dennis Clarke wrote:
>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> [email protected] mailing list
>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
>>>> To unsubscribe, send any mail to "[email protected]"
>>> _______________________________________________
>>> [email protected] mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
>>> To unsubscribe, send any mail to "[email protected]"
>>>
>> _______________________________________________
>> [email protected] mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
>> To unsubscribe, send any mail to "[email protected]"
>>
>

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[email protected]"