Bug 202309 - [uefi] smashed screen on HP Probook 430 G1 with UEFI
Summary: [uefi] smashed screen on HP Probook 430 G1 with UEFI
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-13 19:29 UTC by Oliver Pinter
Modified: 2020-11-22 14:47 UTC (History)
7 users (show)

See Also:


Attachments
loader with 'gop' command (343.47 KB, application/octet-stream)
2015-08-30 03:22 UTC, Marcel Moolenaar
no flags Details
BIOS information (8.45 KB, text/plain)
2015-11-06 05:45 UTC, Douglas King
no flags Details
Dmidecode output (8.45 KB, text/plain)
2015-11-06 05:45 UTC, Douglas King
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Pinter freebsd_committer 2015-08-13 19:29:32 UTC
After Marcel's latest fix the system able to boot with enabled UEFI, when the CSM mode is enabled. When I disable the CSM and try to boot with pure UEFI, I got smashed screen. Seems like the frame buffer's size miscalculated.

See the linked video: http://jenkins.hardenedbsd.org/~op/freebsd-efi.mp4
Comment 1 Marcel Moolenaar freebsd_committer 2015-08-18 02:36:34 UTC
If I can read the screen correctly, it looks like the resolution is 1366x768, with a stride of 1366 and a color depth of 32 bits per pixel (or 4 bytes per pixel).

The console output seems to be using a stride that's just wrong. Since the stride is coming from UEFI, it's hard to think of a reason why the kernel would do this.

Have you tried updating the firmware?
Comment 2 Oliver Pinter freebsd_committer 2015-08-19 18:58:14 UTC
Yes, today I updated to latest bios from HP, but the issue still exists.

How could I extract these information without serial port or change the settings in loader or kernel?
Comment 3 Marcel Moolenaar freebsd_committer 2015-08-30 03:22:57 UTC
Created attachment 160509 [details]
loader with 'gop' command
Comment 4 Marcel Moolenaar freebsd_committer 2015-08-30 03:27:37 UTC
(In reply to Oliver Pinter from comment #2)

I committed revision 287299 (-current), that adds a 'gop' command to the loader. I attached a pre-compiled EFI loader with this command to this PR.

Can you run 'gop get' and 'gop list' and add the output to this PR?

Also: can you try different modes (if possible) and see if that makes a difference?
Comment 5 Douglas King 2015-11-06 05:45:09 UTC
Created attachment 162834 [details]
BIOS information

dmidecode output
Comment 6 Douglas King 2015-11-06 05:45:57 UTC
Created attachment 162835 [details]
Dmidecode output
Comment 7 Douglas King 2015-11-06 05:54:10 UTC
I am having the same issue trying to install on an HP Elitebook 2540p.
The error happens at the same point shown in the video except the whole output is "squished" in the top 5-10% of the disply.
The display changes with user interaction but none of it is viewable.
The text from the boot process remains unaffected. 
Booting without EFI freezes slightly earlier in the boot.

'gop' only has one mode listed.
Comment 8 Oliver Pinter freebsd_committer 2016-01-18 22:15:04 UTC
The issue still exists and the same on most recent stable from 2016.01.18.
Comment 9 Vaclav Mocek 2016-01-19 00:32:50 UTC
I have the same issue with an older Lenovo Ideapad S205, where during the boot the screen is garbled. I tested the snapshot 10.2-r293802 and 11-r293801, both are failing. I had the same issue with Linux three years back - the video mode was not set correctly even in Grub2 and workaround was to use the option gfxmode, which overwrites the detected values. So, I suspect that the UEFI GOP provides partly incorrect information and the efifb is not set correctly.

Unfortunately, I have no clue how to debug these thing on FreeBSD, any hint would be welcomed.
Comment 10 Vaclav Mocek 2016-01-19 00:34:04 UTC
I have the same issue with an older Lenovo Ideapad S205, where during the boot the screen is garbled. I tested the snapshot 10.2-r293802 and 11-r293801, both are failing. I had the same issue with Linux three years back - the video mode was not set correctly even in Grub2 and workaround was to use the option gfxmode, which overwrites the detected values. So, I suspect that the UEFI GOP provides partly incorrect information and the efifb is not set correctly.

Unfortunately, I have no clue how to debug these thing on FreeBSD, any hint would be welcomed.
Comment 11 Alexey Dokuchaev freebsd_committer 2016-08-31 11:23:10 UTC
Exactly the same problem is observed on HP ProBook 645 G1 against recent -CURRENT (r304729).  In CSM mode, "gop get" returns only one mode, with much larger frame buffer size compared to native (non-CSM) boot for some reason:

> OK gop get
> mode 0: 1024x768x32, stride=1024
>     frame buffer: address=c0000000, size=1000000
>     color mask: R=00ff0000, G=0000ff00, B=000000ff
In CSM mode, laptop initializes itself with 1024x768 screen resolution and FreeBSD boots fine.

Now, in native (non-CSM) mode, four modes are reported:

> OK gop get
> mode 0: 1366x768x32, stride=1366
>     frame buffer: address=c0000000, size=420000
>     color mask: R=00ff0000, G=0000ff00, B=000000ff
> 
> OK gop list
> mode 0: 1366x768x32, stride=1366
> mode 1: 800x600x32, stride=800
> mode 2: 1024x768x32, stride=1024
> mode 3: 640x480x32, stride=640
However, only modes 2 and 3 allow to have normal (non-smashed) console.  Booting in other modes looks exactly like on the video clip attached earlier.
Comment 12 Alexey Dokuchaev freebsd_committer 2016-09-02 14:17:03 UTC
Tonight I've played with it a bit more.

1. I've discovered that in Linux Matthew Garrett had patched EFI framebuffer size calculation instead of trusting what firmware provides back in 2012 (https://lkml.org/lkml/2012/7/27/407).  I've made a similar change to our code, but it didn't fix the problem:

> efifb->fb_size = efifb->fb_height * efifb->fb_stride * 4;
Side note: Linux is setting their si->lfb_linelength = pixels_per_scan_line * 4; while we use it as is: efifb->fb_stride = info->PixelsPerScanLine; I wonder why...

2. I've tried booting rather old ubuntu-11.04-desktop-amd64.iso in native UEFI mode and got very similar screen distortion in GRUB; it didn't boot further and I don't have a more recent Ubuntu version at my hands at the moment.

3. OS X Mavericks on HP Probook/Elitebook laptops guide (http://www.insanelymac.com/forum/topic/293842-guide-mavericks-on-hp-probookelitebook-laptops-with-clover-uefi-bootloader/) also mentions this problem under "Known issues" as item number one: "Distorted bootscreen with 7-series laptops using 1366x768 display + UEFI native (without CSM) setting. Changing Clover resolution to 1024x768 can fix it."

At this point I tend to believe that this is a problem on HP side, and I'm not sure if it can be efficiently mitigated other than sticking to 1024x768 (mode 2).  Any further ideas are certainly welcome.
Comment 13 Kubilay Kocak freebsd_committer freebsd_triage 2016-09-03 06:30:04 UTC
Test comment
Comment 14 bel3atar 2016-11-23 02:37:51 UTC
I have the same problem with an HP Elitebook 8470p
Comment 15 Eitan Adler freebsd_committer freebsd_triage 2018-05-20 23:54:17 UTC
For bugs matching the following conditions:
- Status == In Progress
- Assignee == "bugs@FreeBSD.org"
- Last Modified Year <= 2017

Do
- Set Status to "Open"
Comment 16 Mark Linimon freebsd_committer freebsd_triage 2018-10-09 21:27:11 UTC
Is this still a problem as of 12-ALPHA?
Comment 17 Alexey Dokuchaev freebsd_committer 2018-12-21 16:39:14 UTC
Yes, it is still a problem.  Current work-around is to add "gop set 2" to /boot/loader.rc.local (this forces 1024x768).  The problem is not very important because once KMS modules are loaded, the screen switches to native resolution.
Comment 18 greyulv 2020-11-19 20:39:36 UTC
Having same issue with HP ProBook 640 G1

Not able to see anything and NOTHING available after boot finishes.  Not able to use 12.1 RELEASE.  NOTE: This problem does not exist using NomadBSD 1.3.2 (FreeBSD 12.1-RELEASE-p6 #0 r362945M: Sun Jul 5 15:46:22 UTC 2020).

Issue is screen never switches to anything.
Comment 19 Mark Linimon freebsd_committer freebsd_triage 2020-11-20 01:58:57 UTC
I was originally merely inquiring as to whether this PR was still valid.  I don't have the cycles to work on it, sorry.

(Also I don't know why the entire Audit-Trail just got posted to the list.)
Comment 20 Mark Linimon freebsd_committer freebsd_triage 2020-11-20 02:00:35 UTC
I was originally merely inquiring as to whether this PR was still valid.  I don't have the cycles to work on it, sorry.

(Also I don't know why the entire Audit-Trail just got posted to the list.)
Comment 21 Mark Linimon freebsd_committer freebsd_triage 2020-11-20 02:02:03 UTC
I was originally merely inquiring as to whether this PR was still valid.  I don't have the cycles to work on it, sorry.

(Also I don't know why the entire Audit-Trail just got posted to the list.)
Comment 22 Mark Linimon freebsd_committer freebsd_triage 2020-11-22 14:42:35 UTC
^Triage: attempting to find out the source of invalid Bugzilla state in this PR.
Comment 23 Mark Linimon freebsd_committer freebsd_triage 2020-11-22 14:47:14 UTC
^Triage: attempt one more time to correct the content of this PR.