Date: Fri, 21 Dec 2018 16:39:14 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 202309] [uefi] smashed screen on HP Probook 430 G1 with UEFI Message-ID: <bug-202309-227-dcPVbHdlMp@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-202309-227@https.bugs.freebsd.org/bugzilla/> References: <bug-202309-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D202309 Oliver Pinter <op@freebsd.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Ray"@FreeBSD.org, | |dumbbell@FreeBSD.org, | |marcel@FreeBSD.org See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=3D1= 940 | |63 CC|Ray"@FreeBSD.org |ray@FreeBSD.org Marcel Moolenaar <marcel@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open CC|ray@FreeBSD.org | Assignee|freebsd-bugs@FreeBSD.org |marcel@FreeBSD.org Status|Open |In Progress Douglas King <douglasking215@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |douglasking215@gmail.com Ed Maste <emaste@freebsd.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emaste@freebsd.org Marcel Moolenaar <marcel@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|marcel@FreeBSD.org |freebsd-bugs@FreeBSD.org Vaclav Mocek <next.little.owl@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |next.little.owl@gmail.com Alexey Dokuchaev <danfe@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |danfe@FreeBSD.org bel3atar@aol.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bel3atar@aol.com Eitan Adler <eadler@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Open Mark Linimon <linimon@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |linimon@FreeBSD.org Jean-S=C3=A9bastien P=C3=A9dron <dumbbell@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|dumbbell@FreeBSD.org | --- Comment #1 from Marcel Moolenaar <marcel@FreeBSD.org> --- If I can read the screen correctly, it looks like the resolution is 1366x76= 8, 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 w= ould do this. Have you tried updating the firmware? --- Comment #2 from Oliver Pinter <op@freebsd.org> --- 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 from Marcel Moolenaar <marcel@FreeBSD.org> --- Created attachment 160509 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D160509&action= =3Dedit loader with 'gop' command --- Comment #4 from Marcel Moolenaar <marcel@FreeBSD.org> --- (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 from Douglas King <douglasking215@gmail.com> --- Created attachment 162834 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D162834&action= =3Dedit BIOS information dmidecode output --- Comment #6 from Douglas King <douglasking215@gmail.com> --- Created attachment 162835 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D162835&action= =3Dedit Dmidecode output --- Comment #7 from Douglas King <douglasking215@gmail.com> --- 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 out= put 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.=20 Booting without EFI freezes slightly earlier in the boot. 'gop' only has one mode listed. --- Comment #8 from Oliver Pinter <op@freebsd.org> --- The issue still exists and the same on most recent stable from 2016.01.18. --- Comment #9 from Vaclav Mocek <next.little.owl@gmail.com> --- I have the same issue with an older Lenovo Ideapad S205, where during the b= oot the screen is garbled. I tested the snapshot 10.2-r293802 and 11-r293801, b= oth are failing. I had the same issue with Linux three years back - the video m= ode 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 from Vaclav Mocek <next.little.owl@gmail.com> --- I have the same issue with an older Lenovo Ideapad S205, where during the b= oot the screen is garbled. I tested the snapshot 10.2-r293802 and 11-r293801, b= oth are failing. I had the same issue with Linux three years back - the video m= ode 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 from Alexey Dokuchaev <danfe@FreeBSD.org> --- 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=3D1024 > frame buffer: address=3Dc0000000, size=3D1000000 > color mask: R=3D00ff0000, G=3D0000ff00, B=3D000000ff 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=3D1366 > frame buffer: address=3Dc0000000, size=3D420000 > color mask: R=3D00ff0000, G=3D0000ff00, B=3D000000ff >=20 > OK gop list > mode 0: 1366x768x32, stride=3D1366 > mode 1: 800x600x32, stride=3D800 > mode 2: 1024x768x32, stride=3D1024 > mode 3: 640x480x32, stride=3D640 However, only modes 2 and 3 allow to have normal (non-smashed) console.=20 Booting in other modes looks exactly like on the video clip attached earlie= r. --- Comment #12 from Alexey Dokuchaev <danfe@FreeBSD.org> --- 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 c= ode, but it didn't fix the problem: > efifb->fb_size =3D efifb->fb_height * efifb->fb_stride * 4; Side note: Linux is setting their si->lfb_linelength =3D pixels_per_scan_li= ne * 4; while we use it as is: efifb->fb_stride =3D info->PixelsPerScanLine; I w= onder why... 2. I've tried booting rather old ubuntu-11.04-desktop-amd64.iso in native U= EFI 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-proboo= kelitebook-laptops-with-clover-uefi-bootloader/) also mentions this problem under "Known issues" as item number one: "Distor= ted bootscreen with 7-series laptops using 1366x768 display + UEFI native (with= out 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 (mo= de 2). Any further ideas are certainly welcome. --- Comment #13 from Kubilay Kocak <koobs@FreeBSD.org> --- Test comment --- Comment #14 from bel3atar@aol.com --- I have the same problem with an HP Elitebook 8470p --- Comment #15 from Eitan Adler <eadler@FreeBSD.org> --- For bugs matching the following conditions: - Status =3D=3D In Progress - Assignee =3D=3D "bugs@FreeBSD.org" - Last Modified Year <=3D 2017 Do - Set Status to "Open" --- Comment #16 from Mark Linimon <linimon@FreeBSD.org> --- Is this still a problem as of 12-ALPHA? --- Comment #17 from Alexey Dokuchaev <danfe@FreeBSD.org> --- 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-202309-227-dcPVbHdlMp>