[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 Fri, Jan 19, 2024 at 03:44:35PM +0800, Patrick Plenefisch wrote: > On Thu, Jan 18, 2024 at 7:41 AM Roger Pau Monné > <[1]roger.pau@xxxxxxxxxx> wrote: > > From that environment (PVH dom0) can you see if you can dump the > contents of the VFCT table? I don't have a system with that table, > so > not sure if this will work (because iasl is unlikely to know how to > decode it): > # acpidump -n VFCT -o table.dump > # acpixtract -a table.dump > # iasl -d vfct.dat > # cat vfct.dsl > Would be good if you can compare the output from what you get on a > PV > dom0 or when running native Linux. > I'm also adding some AMD folks, as IIRC they did some fixes to Linux > in order to get some AMD graphics cards running on a PVH dom0, maybe > they can provide some additional input. > > Well, this is pretty weird. I'll go into more details because it may be > relevant. 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. Those usage > scenarios have acpidump output as identical. Booting linux PVH directly > from UEFI (no grub), the monitors go to sleep on the RX 480, and amdgpu > errors out about VFCT, but the R5 430 OEM does still have output. > Interestingly, there is a different screen mode booting UEFI+PVH, the > characters are basically squares, with more vertical lines than > "default", maybe close to native screen resolution, but horizontally > it's still "default". Booting from grub gives everything in the > "default" resolution. > So what is in the VFCT Table? VFCT contains the non-GOP VIOS image of Thanks Roger to involve us. The VFCT table is to expose video BIOS image by AMD GPUs. You can see details here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/include/atombios.h Did you apply this patch? https://lore.kernel.org/xen-devel/20230312075455.450187-2-ray.huang@xxxxxxx/ Thanks, Ray > my Radeon RX 480 GPU. You can compare it to the VBIOS hosted at > [2]https://www.techpowerup.com/vgabios/185789/msi-rx480-4096-160720 > (Compare the end at E667 in the VFCT table to E5ff in that vbios link). > I find this extra suspicious due to the above. > Now for the extra horrible things: > UEFI-booted PVH Linux doesn't support keyboard getty input, and at > least some of the USB devices are not in lsusb. It also decided to > vanish one of my HDD's. The `reboot` command hangs. The Power button > doesn't do anything. There are several stack traces in dmesg. But > Alt-SysRq-B does reboot! Luckily I could ssh in and capture the ACPI > tables. They are much smaller, and VFCT is empty. Booting back to one > of the working scenarios (direct linux, Grub PV, Grub PVH, UEFI PV), > all of this is normal. > I've attached: > xenboot.log which is the serial log of xen+linux booting in UEFI PVH > (kernel is debian's config, but patched to start at 2MiB) > dmesg.txt which is the linux dmesg that contains some nice stack traces > (kernel is debian's config, but patched to start at 2MiB) > efipvh-tables.dump is ALL acpi tables from UEFI+PVH mode (acpidump -o > efipvh-tables.dump) > working-tables.dump is ALL acpi tables from the other modes (acpidump > -o working-tables.dump) > efipvh-vfct.dump is attached in spirit, as it is 0 bytes long (acpidump > -n VFCT -o efipvh-vfct.dump) > I ran iasl, but it just said **** Unknown ACPI table signature [VFCT] > and spat out the raw data table, nothing interesting > Something I can try, but have been nervous to try due to GOPupd > warnings is to also flash the 1.67 GOP to the VBIOS on the RX 480. The > R5 430 OEM had no such warnings. > Patrick > > References > > 1. mailto:roger.pau@xxxxxxxxxx > 2. https://www.techpowerup.com/vgabios/185789/msi-rx480-4096-160720
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |