Bug 1791273 - ThinkPad T430 broken flicker free boot
Summary: ThinkPad T430 broken flicker free boot
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 31
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Hans de Goede
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-01-15 12:05 UTC by Jia Yuan Lo
Modified: 2020-11-04 12:22 UTC (History)
21 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2020-11-04 12:22:10 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jia Yuan Lo 2020-01-15 12:05:14 UTC
Description of problem:
https://www.reddit.com/r/Fedora/comments/eo0ytj/guide_fixing_thinkpad_t430_flicker_free_boot/

Long story short, BGRT version of T430 needs to be fixed and i915.fastboot=1 needs to be enabled

Version-Release number of selected component (if applicable):
n/a

How reproducible:
Always

Steps to Reproduce:
Fresh boot from a live USB of Fedora Workstation on T430

Actual results:
Fedora does not have flicker free boot on ThinkPad T430. Lenovo logo shows up when booting, then a black screen, then the Plymouth spinner.

Expected results:
Plymouth spinner with Lenovo logo should appear. Black screen is now reduced to a few millisecond flicker though with the "fix".

Additional info:
I think this bug should be reported against the kernel(?) because of the nature of the workaround, but the flicker free boot effort is part of plymouth(?) I think. I am conflicted here... Maintainer can change as desired.

Comment 1 Hans de Goede 2020-01-15 13:20:12 UTC
Thank you for the bug report. If I understand the problem correctly from the reddit post, there are 2 separate issues, which both need to be fixed for flicker-free boot to work, correct?

1) You need to pass i915.fastboot=1
2) The BGRT table reports a version field of 0 causing the kernel to not accept it as valid

So 1. is more or less by design, currently flickerfree is only enabled by default on Skylake or newer i915 gfx. There has been some discussion about lowering this to Haswell, but your hardware is even older. If you want to discuss changing this you should really send an email to intel-gfx <intel-gfx.org>.

2. is clearly a real bug, I do not believe that overriding the BGRT is the right answer here though. I think we can do DMI checks at the time the bgrt code giving the error runs, so we can just add a DMI quirk table for models on which we will accept 0 as a valid BGRT version, then things will just work without needing to override the table. Can you run as regular user:

grep . /sys/class/dmi/id/* 2> /dev/null

And copy and paste the output here? Then I can prepare a patch for this and give you a test kernel build to test the patch.

Comment 2 Jia Yuan Lo 2020-01-15 13:36:41 UTC
Hi, thanks for the quick reply. You are correct on the 2 problems listed. I guess I will keep up to date with discussion then on Intel.

This is the output of grep . /sys/class/dmi/id/* 2> /dev/null

/sys/class/dmi/id/bios_date:08/07/2019
/sys/class/dmi/id/bios_vendor:LENOVO
/sys/class/dmi/id/bios_version:G1ETC2WW (2.82 )
/sys/class/dmi/id/board_asset_tag:Not Available
/sys/class/dmi/id/board_name:2349PS3
/sys/class/dmi/id/board_vendor:LENOVO
/sys/class/dmi/id/board_version:Not Defined
/sys/class/dmi/id/chassis_asset_tag:No Asset Information
/sys/class/dmi/id/chassis_type:10
/sys/class/dmi/id/chassis_vendor:LENOVO
/sys/class/dmi/id/chassis_version:Not Available
/sys/class/dmi/id/modalias:dmi:bvnLENOVO:bvrG1ETC2WW(2.82):bd08/07/2019:svnLENOVO:pn2349PS3:pvrThinkPadT430:rvnLENOVO:rn2349PS3:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:
/sys/class/dmi/id/product_family:ThinkPad T430
/sys/class/dmi/id/product_name:2349PS3
/sys/class/dmi/id/product_sku:LENOVO_MT_2349
/sys/class/dmi/id/product_version:ThinkPad T430
/sys/class/dmi/id/sys_vendor:LENOVO
/sys/class/dmi/id/uevent:MODALIAS=dmi:bvnLENOVO:bvrG1ETC2WW(2.82):bd08/07/2019:svnLENOVO:pn2349PS3:pvrThinkPadT430:rvnLENOVO:rn2349PS3:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:

Comment 3 Hans de Goede 2020-01-16 13:49:23 UTC
Thanks for the DMI info, I've started a test/scratch build of the a Fedora kernel with a patch added which will accept a BGRT table with a version of 0 on the T430:

https://koji.fedoraproject.org/koji/taskinfo?taskID=40616802

(note still building atm this takes a couple of hours).

Here are some generic instructions for installing a kernel directly from koji:
https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

Please give this kernel a try, without doing the APCI table override through the initrd, and let me know if it fixes things for you. Once I have confirmation that the patch fixes things I will submit it upstream.

Comment 4 Hans de Goede 2020-01-17 08:59:42 UTC
The test kernel is done building now. Note please at least download it soon, koji cleans-up test builds to save disk space after aprox. a week.

Comment 5 lsg 2020-01-17 13:27:02 UTC
I've had same issue with Thinkpad T530 and Thinkpad Helix (both Intel Ivybridge). 
I've installed fedora in this thinkpads with ivy bridge, intel graphics, with Csm disabled, uefi-secure boot enabled and display "thinkpad LCD", but i don’t have any /sys/firmware/acpi/bgrt* (installer doesn't create that, don't know why) I’ve added the i915.fastboot parameter to the kernel after the first reboot but nothing changes: i always get the vendor logo, then a black screen and then only the spinner.

Comment 6 Hans de Goede 2020-01-17 15:01:58 UTC
(In reply to lsg from comment #5)
> I've had same issue with Thinkpad T530 and Thinkpad Helix (both Intel
> Ivybridge). 
> I've installed fedora in this thinkpads with ivy bridge, intel graphics,
> with Csm disabled, uefi-secure boot enabled and display "thinkpad LCD", but
> i don’t have any /sys/firmware/acpi/bgrt* (installer doesn't create that,
> don't know why) I’ve added the i915.fastboot parameter to the kernel after
> the first reboot but nothing changes: i always get the vendor logo, then a
> black screen and then only the spinner.

This is probably the same issue (BIOS bug) as on the T430 if you can provide DMI info for your model then I can also add a quirk to workaround the BIOS bug for your model and provide a test kernel for you to test to see if that helps.

Can you run as regular user:

grep . /sys/class/dmi/id/* 2> /dev/null

And copy and paste the output here?

Comment 7 lsg 2020-01-17 19:09:54 UTC
Thanks for the reply. This is the output of  grep . /sys/class/dmi/id/* 2> /dev/null
/sys/class/dmi/id/bios_date:09/16/2019
/sys/class/dmi/id/bios_vendor:LENOVO
/sys/class/dmi/id/bios_version:GFET65WW (1.44 )
/sys/class/dmi/id/board_asset_tag:Not Available
/sys/class/dmi/id/board_name:36986DG
/sys/class/dmi/id/board_vendor:LENOVO
/sys/class/dmi/id/board_version:0B98417 WIN
/sys/class/dmi/id/chassis_asset_tag:No Asset Information
/sys/class/dmi/id/chassis_type:10
/sys/class/dmi/id/chassis_vendor:LENOVO
/sys/class/dmi/id/chassis_version:Not Available
/sys/class/dmi/id/modalias:dmi:bvnLENOVO:bvrGFET65WW(1.44):bd09/16/2019:svnLENOVO:pn36986DG:pvrThinkPadHelix:rvnLENOVO:rn36986DG:rvr0B98417WIN:cvnLENOVO:ct10:cvrNotAvailable:
/sys/class/dmi/id/product_family:ThinkPad Helix
/sys/class/dmi/id/product_name:36986DG
/sys/class/dmi/id/product_sku:LENOVO_MT_3698
/sys/class/dmi/id/product_version:ThinkPad Helix
/sys/class/dmi/id/sys_vendor:LENOVO
/sys/class/dmi/id/uevent:MODALIAS=dmi:bvnLENOVO:bvrGFET65WW(1.44):bd09/16/2019:svnLENOVO:pn36986DG:pvrThinkPadHelix:rvnLENOVO:rn36986DG:rvr0B98417WIN:cvnLENOVO:ct10:cvrNotAvailable:

Comment 8 lsg 2020-01-17 19:14:36 UTC
I don't have here my T530, I will post it in a few weeks.

Comment 9 Jia Yuan Lo 2020-01-18 02:58:42 UTC
(In reply to Hans de Goede from comment #3)
> Thanks for the DMI info, I've started a test/scratch build of the a Fedora
> kernel with a patch added which will accept a BGRT table with a version of 0
> on the T430:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=40616802
> 
> (note still building atm this takes a couple of hours).
> 
> Here are some generic instructions for installing a kernel directly from
> koji:
> https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt
> 
> Please give this kernel a try, without doing the APCI table override through
> the initrd, and let me know if it fixes things for you. Once I have
> confirmation that the patch fixes things I will submit it upstream.

Err... Is *src.rpm the one I am supposed to download and install?
I am seeing failed messages here and there.
Sorry, I am still new to this koji and rpm things...

Comment 10 Hans de Goede 2020-01-18 12:11:43 UTC
Ah, the scratch-build failed because the disk of the buildsystem was full I missed that, sorry.

I've started a new scratch-build here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=40701506

Please give this one a try when it is done building.

@lsg:

I have found the DMI info I need for the T530 here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1083984

So I've extended the patch for this new build to also also apply to the T530, please give it a try. Note the scratch-build rpms will be recycled a couple of days after building to save disk-space, so even if you do not have access to the T530 right away, please download the RPMs now and save them for later, see: https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt for which files you need.

Comment 11 Jia Yuan Lo 2020-01-19 05:34:26 UTC
I can confirm that the new build works on my T430 without any workaround.

The lenovo logo persisted from boot all the way to showing up with the spinner albeit there's momentarily black screen between the 2 events.

So bug #2 is definitely fixed.

Now hoping for Intel to turn on i915.fastboot for Ivy Bridge to cut down the black screen time...

Comment 12 lsg 2020-01-19 17:17:05 UTC
(In reply to Hans de Goede from comment #10)
> Ah, the scratch-build failed because the disk of the buildsystem was full I
> missed that, sorry.
> 
> I've started a new scratch-build here:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=40701506
> 
> Please give this one a try when it is done building.
> 
> @lsg:
> 
> I have found the DMI info I need for the T530 here:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1083984
> 
> So I've extended the patch for this new build to also also apply to the
> T530, please give it a try. Note the scratch-build rpms will be recycled a
> couple of days after building to save disk-space, so even if you do not have
> access to the T530 right away, please download the RPMs now and save them
> for later, see:
> https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt for which
> files you need.



Thanks. I've installed the kernel in the Helix but I'm afraid that it doesn't work. It boots -as always- with the Lenovo logo, then a black screen and then the fedora spinner... Any clue?

Comment 13 lsg 2020-01-19 18:14:13 UTC
I've checked again the possibilities from the FAQ ( https://hansdegoede.livejournal.com/20632.html ). It seems that i'm in bios mode, but i don't know how to fix it since i've checked that the setup is in uefi only, no csm support, display in "Thinkpad LCD"... Same issue explained in comment 5.

This is the output of ls /sys/firmware/efi/efivars
AcpiGlobalVariable-af9ffd67-ec10-488a-9dfc-6cbf5ee22c2e
AmtSetup-4b9f56be-f68e-4bbc-9bab-cdf600f52d30
Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0002-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0003-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0004-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0005-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0006-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0007-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0008-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0009-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot000A-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot000B-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot000C-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot000D-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot000E-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot000F-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0010-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0011-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0012-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0013-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0014-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0015-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0016-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0017-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0019-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOrderDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
ClearFlag-7cfdc48a-df39-4c98-b8a9-d1b184629514
ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConsoleLock-368cda0d-cf31-4b9b-8cf6-e7d1bfff157e
CpuProtocolSetupVar-7d4adce1-930d-40c7-9cd2-6d2148413dc7
db-d719b2cb-3d3a-4596-a3bc-dad00e67656f
dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f
DIAGSPLSHSCRN-8be4df61-93ca-11d2-aa0d-00e098032b8c
DptfProtocolSetupVar-1054354b-b543-4dfe-558b-a7ad6351c9d8
ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
HDDPWD-8be4df61-93ca-11d2-aa0d-00e098032b8c
IEIT-955b9041-133a-4bcf-90d1-97e1693c0e30
iFfsData-f9f0b131-f346-4f16-80dd-f941072b3a7d
KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c
Key0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
Key0001-8be4df61-93ca-11d2-aa0d-00e098032b8c
Key0002-8be4df61-93ca-11d2-aa0d-00e098032b8c
Key0003-8be4df61-93ca-11d2-aa0d-00e098032b8c
Key0004-8be4df61-93ca-11d2-aa0d-00e098032b8c
Key0005-8be4df61-93ca-11d2-aa0d-00e098032b8c
Key0006-8be4df61-93ca-11d2-aa0d-00e098032b8c
LastBootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c
LBC-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBL-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOL-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP0000-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP0001-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP0002-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP0003-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP0004-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP0005-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP0006-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP0007-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP0008-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP0009-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP000A-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP000B-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP000C-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP000D-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP000E-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP000F-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP0010-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP0011-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP0012-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP0013-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP0014-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP0015-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP0016-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP0017-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOP0019-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LenovoConfig-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LenovoFlashScratch1-67c3208e-4fcb-498f-9729-0760bb4109a7
LenovoHiddenSetting-1827cfc7-4e61-4273-b796-d35f4b0c88fc
LenovoPciResource-ec0cf62f-0742-4c78-a738-8d66158969d4
LenovoScratchData-67c3208e-4fcb-498f-9729-0760bb4109a7
LenovoSecurityConfig-a2c1808f-0d4f-4cc9-a619-d1e641d39d49
LenovoSystemConfig-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LenovoThermalShutdown-943d1460-da6e-499a-af6d-4593b12bc4d7
LenovoWolInfo-0af4027f-9b58-41c0-b62f-cd3a1cef54ee
LKOP0000-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LKOP0001-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LKOP0002-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LKOP0003-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LKOP0004-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LKOP0005-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LKOP0006-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LoaderEntryRebootReason-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
LocalSecurityVars-47355e9f-0857-45e1-8a6f-a4f5eda89a77
LWO-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
MailBoxQ-67c3208e-4fcb-498f-9729-0760bb4109a7
MeBiosExtensionSetup-1bad711c-d451-4241-b1f3-8537812e0c70
MemoryOverwriteRequestControl-e20939be-32d4-41be-a150-897f85d49829
MemoryTypeInformation-4c19049f-4137-4dd3-9c10-8b97a83ffdfa
MemoryTypeInformationBackup-4c19049f-4137-4dd3-9c10-8b97a83ffdfa
MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23
MTC-eb704011-1402-11d3-8e77-00a0c969723b
OsIndications-8be4df61-93ca-11d2-aa0d-00e098032b8c
OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c
OskTrigger-8be4df61-93ca-11d2-aa0d-00e098032b8c
PbaStatusVar-0ec1a7f5-4904-40a0-8eab-4bcc4666da45
PBRDevicePath-8be4df61-93ca-11d2-aa0d-00e098032b8c
PBRDevicePath-a9b5f8d2-cb6d-42c2-bc01-b5ffaae4335e
PchInit-e6c2f70a-b604-4877-85ba-deec89e117eb
PchProtocolSetupVar-04bd8413-15f9-43f3-9675-4618e03240e3
PK-8be4df61-93ca-11d2-aa0d-00e098032b8c
PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c
PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
ProtectedBootOptions-8be4df61-93ca-11d2-aa0d-00e098032b8c
PwdStatusVar-3e72b3ad-2b91-424a-ad73-c3270e91ed88
SaPegData-c4975200-64f1-4fb6-9773-f6a9f89d985e
SaProtocolSetupVar-34f73d4d-963e-4c65-b3b3-515e720175d6
SctHotkey-4650c401-93f1-4aeb-b87d-c8204c047dec
SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
Setup-4dfbbaab-1392-4fde-abb8-c41cc5ad7d5d
SetupHotKey-8be4df61-93ca-11d2-aa0d-00e098032b8c
SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
SimpleBootFlag-8be4df61-93ca-11d2-aa0d-00e098032b8c
SMBIOSELOG000-c3eeae98-23bf-412b-ab60-efcbb48e1534
SMBIOSELOGNUMBER-c3eeae98-23bf-412b-ab60-efcbb48e1534
SMBIOSMEMSIZE-c3eeae98-23bf-412b-ab60-efcbb48e1534
System-e947fcf9-dd01-4965-b808-32a7b6815657
TcgSetup-753ab903-444c-41f8-a235-569e8341147e
TdtSetup-810b8b03-2e42-485c-bc93-c35c748e666c
Time-470733de-df43-448b-8b45-4eeb0df8c812
Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c
TpmAcpiData-6403753b-abde-4da2-aa11-6983ef2a7a69
TpmSaveState-5e724c0c-5c03-4543-bcb6-c1e23de24136


And when I try to " ls /sys/firmware/acpi/bgrt ", i get a can't access, "no such file or directory"... But I'm almost sure (I've tried every option listed in the bios-uefi setup) that i'm not in bios mode. Sorry, i'm a little bit lost here.

Comment 14 Hans de Goede 2020-01-20 09:28:56 UTC
@lsg, your "ls /sys/firmware/efi/efivars" shows that you are running in EFI mode, if there is BIOS no option to turn off the CSM or select "UEFI" only for the VGA BIOS don't worry about that, that happens sometimes.

Can you do:

dmesg | grep -i bgrt

And post the output here please?

Comment 15 lsg 2020-01-20 10:56:52 UTC
Thanks. Here is the output of  dmesg | grep -i bgrt : 

[    0.051636] ACPI: BGRT 0x00000000DAFD6000 000038 (v00 LENOVO TP-GF    00001440 PTL  00000002)
[    0.126934] efi_bgrt: Ignoring BGRT: invalid version 0 (expected 1)
[    2.821487] efifb: No BGRT, not showing boot graphics

Comment 16 Hans de Goede 2020-01-21 09:08:02 UTC
(In reply to lsg from comment #15)
> Thanks. Here is the output of  dmesg | grep -i bgrt : 
> 
> [    0.051636] ACPI: BGRT 0x00000000DAFD6000 000038 (v00 LENOVO TP-GF   
> 00001440 PTL  00000002)
> [    0.126934] efi_bgrt: Ignoring BGRT: invalid version 0 (expected 1)
> [    2.821487] efifb: No BGRT, not showing boot graphics

Ah I just read that you are testing this on the Helix. The dmesg about shows the same problem as on the T430, but the DMI match strings which I added in the new test build are for the T530 only I did not realize you where seeing this on 2 models, so this is expected to now work on the Helix with my test build, sorry.

I can do another test-build with the Helix DMI id added, but I have the feeling I need a more generic fix rather then maintaining an ever growing list of DMI ids...  So let me think about this a bit.

Comment 17 Hans de Goede 2020-01-21 09:08:30 UTC
"now work" should be "not work" above.

Comment 18 lsg 2020-01-22 16:06:33 UTC
Ok, so I'll try the test kernel in the T530 and post the results. Thanks in advance for looking for the more generic fix, hope you find it soon ;-)

Comment 19 Hans de Goede 2020-01-25 16:08:38 UTC
I've rewritten the workaround for this to simply accept version 0 for any device which has "LENOVO" as vendor. I've started a new kernel scratch-build with the new fix added:

https://koji.fedoraproject.org/koji/taskinfo?taskID=40999319
(note still building atm this takes a couple of hours).

Here are some generic instructions for installing a kernel directly from koji:
https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

This should fix the issue on all 3 reported models (T430, T530 and the Helix).

@lsg, can you please test this on both your Helix and T530 ?

@Jia Yuan Lo, can you please retest this on the T430 ?

Comment 20 lsg 2020-01-26 02:38:10 UTC
Thanks for your work.
I've tested it in the Helix and can confirm that, like explained in comment 11, the lenovo logo persisted from boot all the way to showing up with the spinner albeit there's momentarily black screen between the 2 events (sometimes 1 black screen, sometimes 2: lenovo logo-black screen-lenovo&fedoraspinner ; lenovo-black-lenovo-lenovo&fedora ).

Comment 21 lsg 2020-01-26 02:49:56 UTC
sorry to ask this, but i don't know how kernel updates and testing works, so: is this workaround going to be pushed to future updates so we can "go back" to fedora's kernels (and, if yes, it is going to be automatic with new updates or shall we do some extra tweaks)?

Comment 22 lsg 2020-01-26 11:50:40 UTC
sorry to ask this, but i don't know how kernel updates and testing works, so: is this workaround going to be pushed to future updates so we can "go back" to fedora's kernels (and, if yes, it is going to be automatic with new updates or shall we do some extra tweaks)?

Comment 23 Hans de Goede 2020-01-26 14:59:00 UTC
(In reply to lsg from comment #22)
> sorry to ask this, but i don't know how kernel updates and testing works,
> so: is this workaround going to be pushed to future updates so we can "go
> back" to fedora's kernels (and, if yes, it is going to be automatic with new
> updates or shall we do some extra tweaks)?

Now that I have confirmation from you that the more generic version of the patch works, I'm going to submit it upstream for review and merging into the official Fedora kernel.

I've marked the patch with a:

Cc: stable.org

Line in the commit message, so once it is merged upstream it should start showing up in the 5.4.z / 5.5.z kernels which Fedora ships. This process takes a while.

Once this hits the official 5.4.z / 5.5.z kernels there is nothing you need to do to get the new/fixed behavior. In the mean time I suggest you keep using the official Fedora kernels, this will bring the black screen back, but that is purely cosmetic and following the official kernels is important to get the latest security fixes.

Comment 24 Jia Yuan Lo 2020-01-26 16:50:33 UTC
Unfortunately I can't test right now as I am away from my T430 but the patch LGTM so I assume it works

Comment 25 lsg 2020-01-26 20:47:06 UTC
thanks. Is there any guide to reinstall-return to Fedora's official kernel? I've tried to delete the test-kernel but i get a "no match for argument kernel-core-5...etc".

Comment 26 Hans de Goede 2020-01-27 11:11:18 UTC
(In reply to lsg from comment #25)
> thanks. Is there any guide to reinstall-return to Fedora's official kernel?
> I've tried to delete the test-kernel but i get a "no match for argument
> kernel-core-5...etc".

There is no need to remove the test kernel, the version is such that the next official Fedora kernel update will be newer and thus will get installed automatically.

Comment 27 lsg 2020-01-30 01:50:15 UTC
Thanks. I can confirm now that it also works in T530, same as comment 20.

Comment 28 Ben Cotton 2020-11-03 16:10:29 UTC
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 29 Jia Yuan Lo 2020-11-04 00:50:29 UTC
I totally forgot about this issue.

The last time I tried, the fix only present in Rawhide kernels and never make past 31, 32 and (I think) 33.

What happened?

Comment 30 Hans de Goede 2020-11-04 12:22:10 UTC
So as mentioned at the beginning of this bug there are 2 issues at play here:

1) You need to pass i915.fastboot=1
2) The BGRT table reports a version field of 0 causing the kernel to not accept it as valid

2. has long been fixed in the kernel since, if things are still not working you are likely not passing i915.fastboot=1 on the kernel commandline. This is still necessary to enable flickerfree on (somewhat) older models where it has not been tested as much as on newer hardware.

Since the kernel bug not accepting the BGRT has been fixed, I'm going to close this bug.


Note You need to log in before you can comment on or make changes to this bug.