FS#36551 - [gummiboot] Hard freeze with gummiboot-35-1
Attached to Project:
Arch Linux
Opened by Kirill Churin (reflexing) - Thursday, 15 August 2013, 19:09 GMT
Last edited by Tom Gundersen (tomegun) - Monday, 23 September 2013, 02:52 GMT
Opened by Kirill Churin (reflexing) - Thursday, 15 August 2013, 19:09 GMT
Last edited by Tom Gundersen (tomegun) - Monday, 23 September 2013, 02:52 GMT
|
Details
Description:
Upgrading to gummiboot-35-1 causes hard freeze after showing it's menu. Booting with UEFI shell and downgrading to gummiboot-33-1 (with "gummiboot install" as it complains newer version installed) resolves issue. It happens on my Asus Sabertooth Z77. Steps to reproduce: Install gummiboot 35-1 |
This task depends upon
Closed by Tom Gundersen (tomegun)
Monday, 23 September 2013, 02:52 GMT
Reason for closing: Fixed
Additional comments about closing: in testing
Monday, 23 September 2013, 02:52 GMT
Reason for closing: Fixed
Additional comments about closing: in testing
The only changes since v33 are to the keyboard/menu handling. Does it work if you don't press any key and wait for the default entry to boot? How about disabling the menu (set the timeout to 0), does that still hang?
If everything else fails, any chance you could try to bisect it? git sources: http://cgit.freedesktop.org/gummiboot/
Yes, I have different entries, I will provide configs and try your suggestions a bit later.
find . -type f -printf "\n%p\n" -exec cat {} \;
./entries/linux.conf
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=/dev/mapper/arch-root init=/usr/lib/systemd/systemd resume=/dev/mapper/arch-swap nomodeset quiet rw
./entries/linux-lts.conf
title Arch Linux LTS
linux /vmlinuz-linux-lts
initrd /initramfs-linux-lts.img
options root=/dev/mapper/arch-root init=/usr/lib/systemd/systemd nomodeset rw
./entries/linux-ck.conf
title Arch Linux
linux /vmlinuz-linux-ck
initrd /initramfs-linux-ck.img
options root=/dev/mapper/arch-root init=/usr/lib/systemd/systemd nomodeset quiet elevator=bfq rw
./loader.conf
timeout 1
default linux
bc043b288f0531acf85643dd37e03b7bf344842 is the first bad commit
commit 1bc043b288f0531acf85643dd37e03b7bf344842
Author: Kay Sievers <kay@vrfy.org>
Date: Fri Aug 2 15:08:39 2013 +0200
handle Alt-key in line editor; use 'Q' to quit; use 'P' for print dump
:040000 040000 f170ba76cdb159be931ea44d43d207eea0f2a0a3 f3fb67a4abae8bbe0052886e8f70fb86c4fb01e6 M src
I don't know how to debug it further :)
causes the issue? With that, only the old key handling should be used, which will
not recognize Alt and CTRL, but all normal keys should work.
Thanks!
--- a/src/efi/gummiboot.c
+++ b/src/efi/gummiboot.c
@@ -353,7 +353,7 @@ static EFI_STATUS key_read(UINT64 *key) {
UINT32 shift = 0;
EFI_STATUS err;
- if (!checked) {
+ if (0 && !checked) {
err = LibLocateProtocol(&EfiSimpleTextInputExProtocolGuid, (VOID **)&TextInputEx);
if (EFI_ERROR(err))
TextInputEx = NULL;
If you press 'P' (shift 'p') in the menu, what are the values of:
UEFI version:
firmware vendor:
firmware version:
?
firmware vendor: American Megatrends
firmware version: 4.653
I really have no better idea than to add Print() statements. If you
like, it would be great if you could watch what it prints on your box.
There are 3 second sleeps after the print and the console gets messed up,
but maybe it will show if it really gets stuck in the firmware.
Patch and screenshot how it looks here is attached.
Thanks!
Screenshot from 2013-08-19 02... (10.4 KiB)
You see the seconds printed, counting down?
After it reached the timeout, does it boot the default entry?
If you press a key, does the debug output something like:
ReadKeyStroke: Success
?
no
> After it reached the timeout, does it boot the default entry?
no, all I see is on screenshot, repeating
> If you press a key, does the debug output something like: ReadKeyStroke: Success?
no
After first ReadKeyStrokeEx: success it waits for some second
then prints return
then prints first CallLocateProtocol…CallReadKeystrokeEx
then stops until I press any key
then it cycles as I showed before. Hope it helps.
to add different Print()s. This patch makes it print the key codes.
The drawn menu is garbled and makes no sense any more, but I
can see all keys I press, and Enter will also boot the entry.
Do you see key codes with multiple key presses, like:
return key=0-0-73
or do you see only:
return: Not Ready
?
print.patch (1 KiB)
Enter doesn't boot the entry, actually no matter what I press the result is the same. Nothing.
>Do you see key codes with multiple key presses, like:
>return key=0-0-73
no
>or do you see only:
>return: Not Ready
>?
Yep.
On the screenshot is all I see after boot without pressing any keys. After I press any key it loops with "return: Not Ready" no matter I press.
Enter doesn't boot the entry, actually no matter what I press the result is the same. Nothing.
>Do you see key codes with multiple key presses, like:
>return key=0-0-73
no
>or do you see only:
>return: Not Ready
>?
Yep.
On the screenshot is all I see after boot without pressing any keys. After I press any key it loops with "return: Not Ready" no matter I press.
the key presses.
This consolidates all key press handling into one function and uses only one or
the other interface, never both at the same time. Thanks!
http://cgit.freedesktop.org/gummiboot
(Looks cleaner, regardless if this is the reason for the issues on your box.)
Do you have access to Asus Sabertooth Z77? Maybe it will simplify your work…
No, I don't have any access to ASUS hardware, only 4 different laptops, which all seem to work fine.
I'm running out of ideas, maybe a reset of the input device makes a difference:
+++ b/src/efi/gummiboot.c
@@ -359,6 +359,7 @@ static EFI_STATUS key_read(UINT64 *key, BOOLEAN wait) {
if (EFI_ERROR(err))
TextInputEx = NULL;
+ uefi_call_wrapper(TextInputEx->Reset, 2, TextInputEx, TRUE);
checked = TRUE;
}
Btw, there is not maybe a firmware update for your box? Is the version kind of up-to-date?
Firmware is up-to-date, on latest version 2003.
Ok, another try. Pushed to upstream git. Would be great,
if you could git it a try again. Thanks a lot!
Just a loop of "return: Not Ready"
in the patch here.
Are you sure you really run the clean git repo's version?
Here is another try with prints and a fallback. Maybe it reveals what's going wrong. Thanks!
Now I'm confused. :)
someone messed up the call in the ASUS firmware.
Now that we have at least some ideas what's going on: If you are still willing
to test, this patch should reliably fall back to the old API, but also print
where things went wrong.
Thanks!
changes that don't work with the above patch any more.
Git has a version now that is supposed to reliably fall back to
the old and working API as soon as the new API returns unexpected
errors.
For now, I just tagged the current git as 36. If the problem still persists, we need to tune the workaround, I guess.
nm: 'src/efi/gummiboot.so': No such file
GEN gummibootx64.efi
objcopy: 'src/efi/gummiboot.so': No such file
@Kay:
Something with timeouts:
After the menu fired up, it doesn't count to timeout — just responds to keys.
When I select "EFI Default Loader" in menu (which is the same gummiboot, but another file, I think), it fires up it's menu, and starts to count to the timeout, BUT doesn't respond to keypresses. After the timeout it boots default option.
http://cgit.freedesktop.org/gummiboot/commit/?id=f1d3094025dada8460ca9ecfd46a363a2d30c887
Latest GIT: keypresses works, timeout works. :) Thanks!
BUT this problem still exists: When I select "EFI Default Loader" in menu (which is the same gummiboot, but another file, I think), it fires up it's menu, and starts to count to the timeout, BUT doesn't respond to keypresses.
but maybe doesn't matter… :)
in the way we call the key API, which could be, the firmware seems
really broken regarding the extended key API.
According to your debug, this is what happens:
The only indication we get is that get a "key" returned by the firmware
which has all bits set to 0, which should never happen. An that indication
only works one time after a reboot.
If we run the default loader a second time in the already running firmware,
the next calls into the firmware will always tell us that there is no key pressed.
Ideally someone would report that to ASUS, the EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL
seems not to do the right thing. All other vendors I've tested work just fine.
I'm using an ASRock 890GX Pro3, which uses American Megatrends.
Mainboard is a Gigabyte G1.Sniper M5 (rev. 1.0), bios F7 (American Megatrends, IIRC).
(The only related issue I had was that gummiboot wouldn't let me downgrade for testing. Got around that by "faking" the version number to the highest previously installed.)
I would report this upstream, but I am not sure where gummiboot's bugtracker is.
Motherboard: ASRock P67 Extreme4
We *try* harder now to work around the broken firmwares, but it's just a guess that this could work ...
-t