[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ACPI VFCT table too short on PVH dom0 (was: Re: E820 memory allocation issue on Threadripper platforms)





On Wed, Jan 24, 2024 at 3:23 AM Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
> >
> >>
> >> > I had been working with ASRock support ever since I got my brand
> >> > new motherboard because I couldn't see the BIOS/UEFI screens. I could
> >> boot
> >> > up, and once native linux took control amdgpu got the screens/gpu
> >> working
> >> > fine. I finally managed to be able to see the UEFI/BIOS setup screens by
> >> > patching my VBIOS: I extracted the VBIOS image of a cheap R5 430 OEM,
> >> ran
> >> > GOPupd to update the VBIOS UEFI component (GOP) from version 1.60 to
> >> 1.67.
> >> > That allowed the UEFI to actually initialize and use a screen. However,
> >> I
> >> > later realized that only 1 monitor was lighting up in the bios: my
> >> monitor
> >> > plugged into the Radeon RX 480 that was still on VBIOS GOP 1.60. It
> >> appears
> >> > the GOP was initializing the RX 480 too, despite not being flashed with
> >> the
> >> > latest itself. I am working on an email to asrock support about that.
> >> Once
> >> > I get into linux (native or PV), both monitors light up as expected.
> >> Also,
> >> > If I boot linux PVH from grub, they also work.
> >>
> >> OK, that's good, so that would be UEFI -> grub -> Xen -> Linux PVH?
> >>
> >
> > Correct. Inserting grub into the chain "fixes" the acpi tables and things
> > work correctly.
> >
>
> Ok, I am not sure what I did the other day to get it to work, but I can't
> replicate *any* PVH success today. One driver (radeon or amdgpu) always
> complains the VFCT table is wrong, and leads to the symptoms previously
> reported.

Are you sure you are using Xen 4.18?  Some of the Xen logs you
provided did use Xen 4.17, which doesn't have the VFCT fix.

Can you please provide the `xl dmesg` for the non-working case when
using grub2?

Yes, I expected it to fail on 4.17, but failing on 4.18 surprised me. I tried this build with several kernels, with similar results.

Interestingly, with xen 4.18 + Debian 12 + Linux 6.1 (recompiled with the working start address), I get the following graphics modes:
Grub, old low resolution with matching low resolution colXrow count
Xen font, xen boot, high resolution with low resolution colXrow count
Xen font, kernel early boot, high resolution with low resolution colXrow count
Linux font, kernel later boot, high resolution with high resolution colxrow count
At ~18s in the kernel logs, no graphics anymore

I have attached the log of serial output (xen+linux) after grub
 

Thanks, Roger.

Attachment: xen18grubpvh.txt
Description: Text document


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.