| Summary: | Black/blank screen at boot (last message line: fb: switching to inteldrmfb from EFI VGA) unless i915.modeset=0 is set | ||
|---|---|---|---|
| Product: | DRI | Reporter: | Seweryn Kokot <sewkokot> |
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Severity: | critical | ||
| Priority: | medium | CC: | intel-gfx-bugs, jani.nikula, valko, zorg1331 |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | KBL | i915 features: | display/Other |
| Attachments: | |||
Hi, Do you have a "good" kernel version identified where it boots properly? I had a similar pbm. on my HP laptop w/kernel v4.15+ where if the lid was up (the laptop panel was on, ie. when booting "undocked"/no ext. monitor, the screen goes black (but backlight still on) just after the machine starts to boot. Through trial & error, I SOLVED by turning OFF "fastboot" (was on) for i915 (I have Intel integrated graphics (ironlake)) in /etc/initramfs-tools/modules and /etc/default/grub, updated the initramfs & grub. It seems that fastboot is unable to detect the laptop panel's mode. Hope this helps. Just before checking your comments I took a picture of console messages just before the screen becomes black and the system is non-responsive https://ibb.co/iqpcAH Elisabeth, I checked and I'm sure the kernels are properly identified. Before I used grub, now rEFInd to run kernels with initramfs.img and the result is the same. Then if I edit kernel parameters and add i915.modeset=0 to the same entry in grub or rEFInd there is no black screen and the system reaches the login prompt. Jim Turner, I checked both debian and archlinux configuration and could not find anything on fastboot. In particular debian's /etc/initramfs-tools/modules is empty. On the other hand archlinux does not have initramfs-tools. Should I look for 'fastboot' string exactly? Hi again, sorry if my question gave you the wrong idea. What I meant was if it booted properly with kernel 4.14 or 4.13 or etc. For the fastboot, I believe you can use this parameter in grub i915.fastboot=0 to disable it. Unfortunately adding i915.fastboot=0 does not help, same blackscreen. I checked that with kernel 4.14, adding 'i915.modeset=0' is not enought, I also need 'nomodeset' to see the login prompt. Created attachment 138168 [details]
dmesg, lsmod, lspci -v
I checked that kernel 4.9 hangs at fb: switching to inteldrmfb from EFI VGA, but in this case the screen does not get black, I see all the messages. I need to press power button to reset.
Then I compiled kernel 4.4 and in this case without any nomodeset or i915.modeset=0 I get login prompt. I attach dmesg when kernel 4.4 is running. Note that in dmesg there is no line about switching to inteldrmfb from EFI VGA after which the hang (kernel 4.9) or black screen (kernel 4.14, 4.15) happens.
Thanks for your time, are you able to change tty when your stuck on the black screen? could you please attach 4.15 and 4.4 dmesg with the parameter drm.debug=0xe on grub? Elisabeth, Thank you also for your time! 1. I cannot change tty, Ctr-Alt-F2 or Alt-F2 does nothing. And there is no response only power button helps to turn off the laptop. At the same time there are no logs from those boot processes. 2. I added drm.debug=0xe to kernel 4.15, however still the same black screen and the laptop is frozen. Since I removed kernel 4.4, as soon as I compile it again I will send the results. I have a question: since the last message I see for a short period of time before the screen gets black is related to inteldrmfb, is it possible to force my laptop to use nouveaufb or nvidiafb without setting i915.modeset=0, because then xorg does not work? (In reply to Seweryn Kokot from comment #9) > ...I have a question: since the last message I see for a short period of time > before the screen gets black is related to inteldrmfb, is it possible to > force my laptop to use nouveaufb or nvidiafb without setting i915.modeset=0, > because then xorg does not work? Hi again, I'm not sure but I believe that some BIOS have a related option to use only the graphic card. Also there is the Bumblebee Project, but I don't know how it works or if it's safe to use it. Hi On similaire computer Dell Latitude 5490, CPU Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz 00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07) (prog-if 00 [VGA controller]) Kernel modules: i915 fedora 27 , kernel-4.15.10-300.fc27 when in bought it comes with BIOS version 1.0.8 the display works correctly (multi-screens, etc.). Wayland is working properly. And I decide to upgrade BIOS to last Version 1.1.9 Release notes extract : Update to the latest CPU microcode to address CVE-2017-5715 and associated Intel Reboot issue. -Updated Intel ME Firmware to address security advisories INTEL-SA-00086 (CVE-2017-5705, CVE-2017-5708, CVE-2017-5711 & CVE-2017-5712) & INTEL-SA-00101(CVE-2017-13077, CVE-2017-13078 & CVE-2017-13080). After upgrade same problem as here. can't start without nomodeset Created attachment 138401 [details]
dmesg linux kernel 4.4 with drm.debug=0xe
Elisabeth, I attach dmesg when running kernel 4.4 with drm.debug=0xe.
Jean, I can confirm that when I bought the BIOS was also 1.0.8, however before installing Debian and Archlinux I upgraded BIOS to 1.0.9 then to 1.1.8 and recently to 1.1.9. So the problem probably began on BIOS 1.0.9.
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug. We have encountered the same issue (Latitude 5490/5590s with Intel GPU no longer booting Linux kernel without nomodeset after upgrading BIOS to version 1.1.9). I managed to get a kernel log showing the problem, but it's 75K. So I tried to add it as an attachment, but the "Access to the file was denied The file at https://bugs.freedesktop.org/attachment.cgi is not readable." Hi, have you tried latest drm-tip: https://cgit.freedesktop.org/drm-tip? Hi, Laszlo, I also had problems attaching a file so I used the second option 'paste text as attachment'. Jani, I tried drm-tip three weeks ago, then one week ago with the same result :( I can try tomorrow with the latest drm-tip. The other thing is that so far there is no response from dell if the regression changes in BIOS vers. 1.1.9 can be reverted to BIOS 1.0.8. Created attachment 138705 [details]
dmesg with drm-tip
Okay, so here's the kernel crash log with drm-tip as of today booted.
To me, it looks like the updated BIOS changed the display EDID data, and the i915 was not prepared for this...
[ 35.442022] [drm:intel_dp_init_connector [i915]] using AUX C for port C (VBT) [ 35.442038] [drm:intel_hdmi_init_connector [i915]] Adding HDMI connector on port C [ 35.442052] [drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x2 for port C (VBT) ... [ 35.461411] WARN_ON(!intel_gmbus_is_valid_pin(dev_priv, pin)) ... [ 35.461609] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 [ 35.461613] IP: i2c_transfer+0x4/0x86 So the VBT has a bogus gmbus pin specified for some reason. 2==VGADDC and indeed that doesn't appear in the skl valid pins list. And the spec agrees with our list. Please attach a copy of /sys/kernel/debug/dri/0/i915_vbt. I wonder if we should perhaps reject the entire HDMI port when the gmbus pin is bogus? We'd lose one the HDMI ports though. Also these machines seem to have eDP + HDMI + DP via type-C + VGA on them. I wonder how it's all hooked up when we have just three ports declared in the VBT... /sys/kernel/debug/dri does not exist at all here. What should I do to have it? Created attachment 138711 [details]
i915_vbt
So I found an older kernel (4.4.0 from Ubuntu LTS) which works without nomodeset, and I could get the i915_vbt from there. From the description of this I'd suppose its contents are not kernel-dependent.
In bug report: https://bugs.freedesktop.org/show_bug.cgi?id=105961 there is a suggested patch https://patchwork.kernel.org/patch/10003565/ + Jani N The question is, are you all booting in UEFI or legacy boot mode? If legacy, please try UEFI. This has been known to affect the Video BIOS Tables (VBT) provided to the kernel. (In reply to Jim Turner from comment #2) > I had a similar pbm. on my HP laptop w/kernel v4.15+ where if the lid was up > (the laptop panel was on, ie. when booting "undocked"/no ext. monitor, the > screen goes black (but backlight still on) just after the machine starts to > boot. > > Through trial & error, I SOLVED by turning OFF "fastboot" (was on) for i915 > (I have Intel integrated graphics (ironlake)) in > /etc/initramfs-tools/modules and > /etc/default/grub, updated the initramfs & grub. > > It seems that fastboot is unable to detect the laptop panel's mode. > > Hope this helps. This is an unrelated problem. (In reply to Seweryn Kokot from comment #12) > Created attachment 138401 [details] > dmesg linux kernel 4.4 with drm.debug=0xe > > Elisabeth, I attach dmesg when running kernel 4.4 with drm.debug=0xe. What v4.4 does is irrelevant here, because v4.4 does not support your hardware and thus the nomodeset is implicit. Okay, I have a hunch. I assume you all 1) have a Dell Latitude 5490 or thereabouts, 2) you all have a Kabylake (KBL) system with either Sunrisepoint PCH (SPT) or Kabylake PCH (KBP), and 3) the problems started after updating the BIOS. Please check your dmesg with drm.debug=14 set, and look for lines similar to these: [ 35.431169] [drm:intel_pch_type [i915]] Found SunrisePoint LP PCH [ 35.456889] i915 device info: pciid=0x5917 rev=0x07 platform=KABYLAKE gen=9 There are KBL systems with SPT and KBP, but there are *also* newer KBL systems with Cannonlake PCH (CPT). The way the VBT is specified, we need to do some mapping on the DDC pin on CPT. The mapping would be right for CPT, but wrong for SPT and KBP. Now, I presume Dell has inadvertently based their BIOS update on the newer model's BIOS, without taking this into account. It would really be useful to get the VBT dumps before and after BIOS update. Can you downgrade the BIOS? (In reply to Jani Nikula from comment #27) > It would really be useful to get the VBT dumps before and after BIOS update. > Can you downgrade the BIOS? I have tried to downgrade (Latitude 5590), firmware explicitly "said" that "downgrade is not supported to this version". (In reply to Jani Nikula from comment #27) > Now, I presume Dell has inadvertently based their BIOS update on the newer > model's BIOS, without taking this into account. Wouldn't that cause similar problems with Windows? Or is the Windows graphics driver more resilient to such problems? I personally haven't tried Windows, but I saved the image so I could give it a try. > It would really be useful to get the VBT dumps before and after BIOS update. > Can you downgrade the BIOS? Unfortunately, Dell does not allow downgrading the BIOS. So we'd need a new machine that is not yet updated. Which is difficult, since people do not come here before they start having problems... Created attachment 138749 [details] dmesg, kernel 4.15.15, with patch, drm.debug=14 I attach dmesg from kernel 4.15.15 after applying this patch https://patchwork.kernel.org/patch/10003565/ I confirm that the two lines are present in dmesg: [ 7.087856] [drm:i915_driver_load [i915]] Found SunrisePoint LP PCH [ 7.088526] [drm:intel_device_info_dump [i915]] i915 device info: platform=KABYLAKE gen=9 pciid=0x5917 rev=0x07 I also confirm that applying this patch and without nomodeset or i915.modeset=0 I can now see the login prompt (so no black/blank screen at boot anymore) However I cannot downgrade BIOS from 1.1.9 to 1.0.8. (In reply to Laszlo Valko from comment #29) > > Wouldn't that cause similar problems with Windows? Or is the Windows > graphics driver more resilient to such problems? I personally haven't tried > Windows, but I saved the image so I could give it a try. > I have Windows 10 on the same Dell Latitude 5490 and there is no problem with Windows booting and running. Created attachment 138750 [details]
i915_vbt, patch applied, kernel 4.15.15, without nomodeset, BIOS 1.1.9
I attach i915_vbt for kernel 4.15.15 when the patch is applied and without nomodeset. BIOS 1.1.9.
*** Bug 105961 has been marked as a duplicate of this bug. *** Rebased and polished version of the patch in comment #30. http://patchwork.freedesktop.org/patch/msgid/20180411090146.12689-1-jani.nikula@intel.com Please test. (In reply to Jani Nikula from comment #27) > There are KBL systems with SPT and KBP, but there are *also* newer KBL > systems with Cannonlake PCH (CPT). The way the VBT is specified, we need to > do some mapping on the DDC pin on CPT. The mapping would be right for CPT, > but wrong for SPT and KBP. > > Now, I presume Dell has inadvertently based their BIOS update on the newer > model's BIOS, without taking this into account. Nope, the VBT is just plain wrong also for CNP. Created attachment 138753 [details]
dmesg, drm-tip with fix applied
I can confirm that drm-tip fixed with this patch boots properly on my Latitude 5590. The attached kernel log shows a boot with the internal display panel and an external monitor connected through both VGA and HDMI connectors. I have no USB C devices so I cannot test that one.
Created attachment 138754 [details]
journal -b -x; updated patch
I also confirm that the updated patch works. I attach 'journal -b -x' log (dmesg does not show messages from the beginning)
I connected an external monitor through hdmi but it is seen as 'DP-1' in arandr. While 'HDMI-1' is inactive.
Thanks for the reports and testing, fixed by commit f212bf9abe5de9f938fecea7df07046e74052dde Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Apr 11 16:15:18 2018 +0300 drm/i915/bios: filter out invalid DDC pins from VBT child devices and Cc: stable to backport to stable kernels. (In reply to Seweryn Kokot from comment #37) > I connected an external monitor through hdmi but it is seen as 'DP-1' in > arandr. That's because your machine has an internal DP->HDMI2.0 converter called LSPCON. It looks like DP to the driver, even though it's HDMI on the chassis. Thank you for your help and the patch. I hope to see this patch in the linux distributions soon :) Created attachment 138885 [details]
dmesg, kernel 4.15.15, no patch, drm.debug=14, new BIOS 1.2.3
Today (April 17th) Dell updated BIOS to ver. 1.2.3. I have upgraded the BIOS and now nomodeset is not needed anymore, nor the patch. It seems they fixed BIOS. For information I attach dmesg. Note that i915_vbt is not changed in the new BIOS.
(In reply to Seweryn Kokot from comment #41) > Created attachment 138885 [details] > dmesg, kernel 4.15.15, no patch, drm.debug=14, new BIOS 1.2.3 > > Today (April 17th) Dell updated BIOS to ver. 1.2.3. I have upgraded the BIOS > and now nomodeset is not needed anymore, nor the patch. It seems they fixed > BIOS. For information I attach dmesg. Note that i915_vbt is not changed in > the new BIOS. On BIOS side, only a VBT change could fix the issue. So the above statement seems a bit odd. Created attachment 138895 [details]
i915_vbt when BIOS 1.2.3 is run
I attach i915_vbt when BIOS 1.2.3 is upgraded. Opening it in a text editor (emacs) and comparing sizes it seems the same as on BIOS 1.1.9. Since it is a binary file I cannot see the difference.
They claim they've updated the video BIOS... Enhancement: - Updated Embedded Controller Engine Firmware. - Updated Intel Reference Code. - Updated Intel Video BIOS. - Supported selectable MAC Address Pass-Through feature in BIOS Setup. $ cmp i915_vbt i915_vbt_1.2.3 i915_vbt i915_vbt_1.2.3 differ: char 27, line 1 $ od -t x1 -A x i915_vbt | head -2 000000 24 56 42 54 20 53 4b 59 4c 41 4b 45 20 20 20 20 000010 20 20 20 20 64 00 30 00 59 11 9a 00 30 00 00 00 $ od -t x1 -A x i915_vbt_1.2.3 | head -2 000000 24 56 42 54 20 53 4b 59 4c 41 4b 45 20 20 20 20 000010 20 20 20 20 64 00 30 00 59 11 99 00 30 00 00 00 $ (In reply to Jani Nikula from comment #42) > (In reply to Seweryn Kokot from comment #41) > > Created attachment 138885 [details] > > dmesg, kernel 4.15.15, no patch, drm.debug=14, new BIOS 1.2.3 > > > > Today (April 17th) Dell updated BIOS to ver. 1.2.3. I have upgraded the BIOS > > and now nomodeset is not needed anymore, nor the patch. It seems they fixed > > BIOS. For information I attach dmesg. Note that i915_vbt is not changed in > > the new BIOS. > > On BIOS side, only a VBT change could fix the issue. So the above statement > seems a bit odd. I had the same problem with my Latitude 5490, which I got already with BIOS 1.1.9. The kernel patch did solve the problem then, thanks a lot for that! Now I upgraded to BIOS 1.2.3 and find that it indeed works fine without the patch. Thanks for the follow-up everyone. Using the intel_vbt_decode tool on the VBT dumps here, I get the diff: --- i915_vbt.1.1.9.txt 2018-04-18 10:36:39.221391894 +0300 +++ i915_vbt.1.2.3.txt 2018-04-18 10:36:48.840968824 +0300 @@ -3,7 +3,7 @@ VBT version: 0x0064 (1.0) VBT header size: 0x0030 (48) VBT size: 0x1159 (4441) - VBT checksum: 0x9a + VBT checksum: 0x99 BDB offset: 0x00000030 (48) BDB header: @@ -126,7 +126,7 @@ Port: 0x07 (DP-B) AIM I2C pin: 0x00 AIM Slave address: 0x00 - DDC pin: 0x01 + DDC pin: 0x05 EDID buffer ptr: 0x00 DVO config: 0x00 HPD sense invert: no @@ -179,7 +179,7 @@ Port: 0x08 (DP-C) AIM I2C pin: 0x00 AIM Slave address: 0x00 - DDC pin: 0x02 + DDC pin: 0x04 EDID buffer ptr: 0x00 DVO config: 0x00 HPD sense invert: no We'll still carry the patch upstream of course; we better not oops on bogus VBT data. (In reply to Olaf Wucknitz from comment #45) > (In reply to Jani Nikula from comment #42) > > (In reply to Seweryn Kokot from comment #41) > > > Created attachment 138885 [details] > > > dmesg, kernel 4.15.15, no patch, drm.debug=14, new BIOS 1.2.3 > > > > > > Today (April 17th) Dell updated BIOS to ver. 1.2.3. I have upgraded the BIOS > > > and now nomodeset is not needed anymore, nor the patch. It seems they fixed > > > BIOS. For information I attach dmesg. Note that i915_vbt is not changed in > > > the new BIOS. > > > > On BIOS side, only a VBT change could fix the issue. So the above statement > > seems a bit odd. > > I had the same problem with my Latitude 5490, which I got already with BIOS > 1.1.9. The kernel patch did solve the problem then, thanks a lot for that! > Now I upgraded to BIOS 1.2.3 and find that it indeed works fine without the > patch. Hello, Same on Fedora 27 i patch works with BIOS 1.1.9 and BIOS 1.2.3 works without patch Thanks we 've the same problem, but linked patches doesn't solve the issue. we've filed a bug first at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1792144 with link to this one, because we thought, that the patches here are not part of currently used kernel, but they are. so, the problem still exists with certain hardware. local hardware is a Intel(R) Celeron(R) J4105 CPU lspci say: 00:02.0 VGA compatible controller: Intel Corporation Device 3185 (rev 03) (prog-if 00 [VGA controller]) after many tries we've found a workaround. calling xrandr first with "--output $port --off" and then with "--output $port --auto" makes the screen viewable again. unfortunately not before X has been started, so no login is shown and if the system hangs, no info is available at all. so, is it possible to create an option for the i915-driver to put all connected devices frist off, then on direct after switching from EFI-VGA? Please don't reopen old bugs with zero evidence you actually have the same bug. Please file a new bug with full dmesg with drm.debug=14 set, and attach /sys/kernel/debug/dri/0/i915_vbt Thank you. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 138152 [details] lspci -v, dmesg, lsmod, mkinitcpio -M Dell Latitude 5490 8th gen i7-8650U intel iGPU HD 620 (i915) dGPU geforce MX130 (former 940MX) Maxwell architecture The problem is on both Debian Sid and Arch Linux (kernels 4.15) To summarize the problem: 1. Without modesetting disabled the system does not reach a console login. The result is that for a quater of second I see the screen with some messages. Then the screen becomes black, I mean the there is a black light on the screen but I can do nothing (Ctrl-Alt-F2 does not work). I cannot login even blindly to power off. Neither I have any records in the journal (dmesg) - simply as if the booting process is non-existing in logs. The final line before the screen goes black is "fb: switching to inteldrmfb from EFI VGA" 2. While with modesetting the journal log is shown below. I can login. From the journal I can see that EFI VGA frame buffer is used: "[ 5.722465] fb0: EFI VGA frame buffer device" instead of inteldrmfb. Below I include additional information from the system when i915.modeset=0 is passed to kernel parameters. I could provide more information if needed.