UEFI Doom hangs started on hardware
Opened this issue · 32 comments
I've installed a UEFI shell, and booted from it. This works great. So then I start doom.efi (doom.efi and doowm.wad were copied to the EFI partition). doom.efi starts, and finds doom.wad, but then hangs when it's displaying the following:
M_Init: Init miscellaneous info.
R_Init: Init DOOM refresh daemon -
R_Init
I've waited a while, but it never continues.
I didn't use Qemu, I've booted into the UEFI shell, and started doom.efi. I've tried various ways to boot into the shell: booting from an USB stick, from the BIOS, and from GRUB2, but it hangs every time at the same point.
Make sure you aren't using an outdated firmware that can't drive EDK2's C standard library implementation.
The latest repo also contains some changes to allow it to load sprites without hanging indefinitely, so do try building it if you encounter issues.
Also, can you tell me your hardware specs?
This is an Asrock Z97 Extreme6 MB with an Intel i5 4460, 16 GB RAM, and an AMD RX Vega 64 GPU.
What's you UEFI firmware version? (Hint: check the BIOS Version/Date field in System Information if you are running Windows)
I'm using version 2.80 with microcode 24, the latest firmware available, but I've also tried 2.80 updated with microcode 28.
Did you check the UEFI version output you get when you start the EDK2's UEFI shell binary? Mine happens to be UEFI 2.50.
Edit: Check if your keyboard is working when the hang happens. Usually the Key Locks won't work when the computer is frozen.
ver says:
UEFI Interactive Shell v2.2
EDK II
UEFI v2.31 (American Megatrends, 0x0004028F)
I got this from tianocore/edk2. It's edk2-stable202002 (release Date 2020-03-04), the most recent binary version I could find. There a version edk2-stable202005 (release Date 2020-06-03) as well, but that one didn't have any binaries. Do you know where I can find 2.50?
It looks like your computer's UEFI version is v2.31, which seems to be lower than what I have.
Try compiling the binary by yourself (git clone the repo inside the EDK2 workspace root, then build it with "build -t VS2015 -p uefidoom/uefidoom.dsc"). Copy the IWAD file again too; I noticed that the program would glitch out sometimes when loading, and replacing the IWAD file seemed to work around such issues.
I had no problems compiling ShellPkg, or AudioPkg, but compiling uefidoom failed. I'm now going to try the new shell.efi, that may do the trick.
/home/ableeker/src/edk2/uefidoom/uefidoom/am_map.c: In function 'AM_updateLightLev':
/home/ableeker/src/edk2/uefidoom/uefidoom/am_map.c:786:12: error: type defaults to 'int' in declaration of 'nexttic' [-Werror=implicit-int]
786 | static nexttic = 0;
| ^~~~~~~
/home/ableeker/src/edk2/uefidoom/uefidoom/am_map.c: In function 'AM_clipMline':
/home/ableeker/src/edk2/uefidoom/uefidoom/am_map.c:859:14: error: type defaults to 'int' in declaration of 'outcode1' [-Werror=implicit-int]
859 | register outcode1 = 0;
| ^~~~~~~~
/home/ableeker/src/edk2/uefidoom/uefidoom/am_map.c:860:14: error: type defaults to 'int' in declaration of 'outcode2' [-Werror=implicit-int]
860 | register outcode2 = 0;
| ^~~~~~~~
/home/ableeker/src/edk2/uefidoom/uefidoom/am_map.c:861:14: error: type defaults to 'int' in declaration of 'outside' [-Werror=implicit-int]
861 | register outside;
| ^~~~~~~
/home/ableeker/src/edk2/uefidoom/uefidoom/am_map.c: In function 'AM_drawFline':
/home/ableeker/src/edk2/uefidoom/uefidoom/am_map.c:992:12: error: type defaults to 'int' in declaration of 'fuck' [-Werror=implicit-int]
992 | static fuck = 0;
| ^~~~
cc1: all warnings being treated as errors
make: *** [GNUmakefile:568: /home/ableeker/src/edk2/Build/DoomPkg/RELEASE_GCC5/X64/uefidoom/uefidoom/doom/OUTPUT/am_map.obj] Error 1
build.py...
: error 7000: Failed to execute command
make tbuild [/home/ableeker/src/edk2/Build/DoomPkg/RELEASE_GCC5/X64/uefidoom/uefidoom/doom]
build.py...
: error F002: Failed to build module
/home/ableeker/src/edk2/uefidoom/uefidoom/doom.inf [X64, GCC5, RELEASE]
- Failed -
Build end time: 17:22:16, Jun.13 2020
Build total time: 00:00:09
The shellx64.efi is still version 2.31, but I've just compiled it from the most recent source, so it should be all right. It still hangs at the same point unfortunately.
I've copied the wad-file again, and have tried some other wads, but that didn't help.
Oh, I forgot to mention: GCC compiler isn't supported; last time I attempted to build UEFI Doom with the GCC compiler with intentionally disabling the warnings and errors, it failed at the linker stage all times.
Try with the clang compiler with Microsoft extensions on. Or if Windows is an option, try compiling it inside a Windows VM with MSVC.
I've tried following your instructions to compile UEFI Doom, using edk2, edk2-libc, and AudioDxe. This time I'm using VC 2019 (the version I have) under Windows but the instructions don't tell me how to compile a specific project, UEFI Doom. If I use ShellPkg/ShellPkg.dsc for instance, I can compile Shell.efi. But when I tried to compile using AppPkg/Applications/uefidoom/uefidoom.dsc, it failed to start. So I modified uefidoom.dsc, it has 'uefidoom/uefidoom.inf' under Components, but shouldn't that be 'AppPkg/Applications/uefidoom/uefidoom.inf'? After that it started, but it fails to complete.
First I get the following message (repeated 6 times about 6 lines in the file):
h:\source\edk2\StdLib\EfiSocketLib\Socket.c(573): error C2220: the following warning is treated as an error
h:\source\edk2\StdLib\EfiSocketLib\Socket.c(573): warning C4459: declaration of 'errno' hides global declaration
And somewhat further on, I get the following error:
LibGdtoa.lib(ldtoa.obj) : error LNK2001: unresolved external symbol __fpclassifyd
Do you have any idea what wrong?
EDK2 libc has problems when compiled under anything later than VS 2015. Try compiling it with VS 2015.
With VS 2015 I was finally able to compile an up-to-date doom.efi. However, it still hangs at the same point.
It seems like a firmware bug at this point really. Try loading the AudioDxe driver and then launching.
Compiling the AudioDxe driver went without a hitch, and it loaded successfully in the EFI Shell. However, Doom still hangs at the same point.
Then at this point it's a firmware specific bug.
Unless someone else also experiences hanging at the same time, I am keeping this closed.
I have upgraded my computer, and I've replaced the Intel CPU with an AMD one, and because of this, the motherboard, and RAM as well. However, when I start doom.efi with this new configuration, it hangs at exactly the same point.
Unless someone else also experiences hanging at the same time, I am keeping this closed.
@Cacodemon345, I'm also experiencing this at the same point.
This is on an HP Envy x360 (15m-ee0013dx) on the latest UEFI firmware, and using the latest release of UEFI DOOM (1.4). I haven't tested any other hardware yet.
Same issue on a Dell OptiPlex 9020.
HP Pavilion 15-cs3055wm actually manages to get into DOOM and is playable, but keyboard and mouse inputs are very slow and only appear to work in small steps at a time.
Last time I tested on a HP Pavillion 8th gen Kaby Lake R laptop it was working fine.
Not all HP laptops are equal. This issue should be reopened, because two separate people are having the same exact issue on three separate machines.
Hi,
Thank you for this great project! Same issue here too.
Dell Latitude 5490
External UEFI Shell
edk2-stable202205
UEFI v2.60 (American Megatrends, 0x0005000B)
For me it also hangs at the same point. This is on a Medion Akoya P2214T. I'm using the latest binary of UEFI Doom available at Releases (1.4, March 4, 2020)
UEFI v2.31 (America Megatrends, 0x00050009)
I recently got rid of alloca usages in the latest Git revision 1d1acb286ce5a79306548928575e459a142c868b. Try it and see if it helps.
Can you provide an efi file to test with?
an precompiled EFI would be very nice
I'm busy nowadays, so I can't.
yep, having the same issue here