Bug 105549 - Black/blank screen at boot (last message line: fb: switching to inteldrmfb from EFI VGA) unless i915.modeset=0 is set
Summary: Black/blank screen at boot (last message line: fb: switching to inteldrmfb fr...
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium critical
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
: 105961 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-03-16 11:19 UTC by Seweryn Kokot
Modified: 2018-09-17 06:47 UTC (History)
4 users (show)

See Also:
i915 platform: KBL
i915 features: display/Other


Attachments
lspci -v, dmesg, lsmod, mkinitcpio -M (79.95 KB, text/plain)
2018-03-16 11:19 UTC, Seweryn Kokot
no flags Details
dmesg, lsmod, lspci -v (109.89 KB, text/plain)
2018-03-17 10:48 UTC, Seweryn Kokot
no flags Details
dmesg linux kernel 4.4 with drm.debug=0xe (57.74 KB, text/plain)
2018-03-28 21:12 UTC, Seweryn Kokot
no flags Details
dmesg with drm-tip (75.83 KB, text/plain)
2018-04-09 16:22 UTC, Laszlo Valko
no flags Details
i915_vbt (6.00 KB, application/octet-stream)
2018-04-09 21:04 UTC, Laszlo Valko
no flags Details
dmesg, kernel 4.15.15, with patch, drm.debug=14 (108.99 KB, text/plain)
2018-04-11 07:49 UTC, Seweryn Kokot
no flags Details
i915_vbt, patch applied, kernel 4.15.15, without nomodeset, BIOS 1.1.9 (6.00 KB, application/octet-stream)
2018-04-11 07:56 UTC, Seweryn Kokot
no flags Details
dmesg, drm-tip with fix applied (111.86 KB, text/plain)
2018-04-11 09:47 UTC, Laszlo Valko
no flags Details
journal -b -x; updated patch (149.27 KB, text/plain)
2018-04-11 10:57 UTC, Seweryn Kokot
no flags Details
dmesg, kernel 4.15.15, no patch, drm.debug=14, new BIOS 1.2.3 (102.44 KB, text/plain)
2018-04-17 19:22 UTC, Seweryn Kokot
no flags Details
i915_vbt when BIOS 1.2.3 is run (6.00 KB, application/octet-stream)
2018-04-18 06:46 UTC, Seweryn Kokot
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Seweryn Kokot 2018-03-16 11:19:17 UTC
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.
Comment 1 Elizabeth 2018-03-16 16:11:53 UTC
Hi, Do you have a "good" kernel version identified where it boots properly?
Comment 2 Jim Turner 2018-03-16 16:28:12 UTC
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.
Comment 3 Seweryn Kokot 2018-03-16 16:37:27 UTC
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
Comment 4 Seweryn Kokot 2018-03-16 17:08:32 UTC
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?
Comment 5 Elizabeth 2018-03-16 17:41:51 UTC
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.
Comment 6 Seweryn Kokot 2018-03-16 19:15:38 UTC
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.
Comment 7 Seweryn Kokot 2018-03-17 10:48:58 UTC
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.
Comment 8 Elizabeth 2018-03-20 22:27:41 UTC
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?
Comment 9 Seweryn Kokot 2018-03-21 07:45:16 UTC
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?
Comment 10 Elizabeth 2018-03-21 17:21:07 UTC
(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.
Comment 11 Jean-François Dumont 2018-03-28 19:25:44 UTC
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
Comment 12 Seweryn Kokot 2018-03-28 21:12:36 UTC
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.
Comment 13 Jani Saarinen 2018-03-29 07:10:12 UTC
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.
Comment 14 Laszlo Valko 2018-04-09 14:09:33 UTC
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).
Comment 15 Laszlo Valko 2018-04-09 14:18:22 UTC
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."
Comment 16 Jani Saarinen 2018-04-09 14:25:36 UTC
Hi, have you tried latest drm-tip: https://cgit.freedesktop.org/drm-tip?
Comment 17 Seweryn Kokot 2018-04-09 15:54:07 UTC
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.
Comment 18 Laszlo Valko 2018-04-09 16:22:33 UTC
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...
Comment 19 Ville Syrjala 2018-04-09 16:51:26 UTC
[   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...
Comment 20 Laszlo Valko 2018-04-09 17:15:32 UTC
/sys/kernel/debug/dri does not exist at all here. What should I do to have it?
Comment 21 Laszlo Valko 2018-04-09 21:04:44 UTC
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.
Comment 22 Seweryn Kokot 2018-04-10 20:38:38 UTC
In bug report:
https://bugs.freedesktop.org/show_bug.cgi?id=105961

there is a suggested patch
https://patchwork.kernel.org/patch/10003565/
Comment 23 Jani Saarinen 2018-04-11 05:34:47 UTC
+ Jani N
Comment 24 Jani Nikula 2018-04-11 06:46:52 UTC
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.
Comment 25 Jani Nikula 2018-04-11 07:05:23 UTC
(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.
Comment 26 Jani Nikula 2018-04-11 07:06:33 UTC
(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.
Comment 27 Jani Nikula 2018-04-11 07:21:08 UTC
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?
Comment 28 Pavel Nakonechnyi 2018-04-11 07:28:50 UTC
(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".
Comment 29 Laszlo Valko 2018-04-11 07:43:20 UTC
(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...
Comment 30 Seweryn Kokot 2018-04-11 07:49:42 UTC
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.
Comment 31 Seweryn Kokot 2018-04-11 07:51:29 UTC
(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.
Comment 32 Seweryn Kokot 2018-04-11 07:56:43 UTC
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.
Comment 33 Jani Nikula 2018-04-11 08:26:50 UTC
*** Bug 105961 has been marked as a duplicate of this bug. ***
Comment 34 Jani Nikula 2018-04-11 09:02:21 UTC
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.
Comment 35 Jani Nikula 2018-04-11 09:04:34 UTC
(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.
Comment 36 Laszlo Valko 2018-04-11 09:47:54 UTC
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.
Comment 37 Seweryn Kokot 2018-04-11 10:57:58 UTC
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.
Comment 38 Jani Nikula 2018-04-12 09:30:30 UTC
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.
Comment 39 Jani Nikula 2018-04-12 09:31:37 UTC
(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.
Comment 40 Seweryn Kokot 2018-04-12 09:37:58 UTC
Thank you for your help and the patch. I hope to see this patch in the linux distributions soon :)
Comment 41 Seweryn Kokot 2018-04-17 19:22:03 UTC
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.
Comment 42 Jani Nikula 2018-04-18 05:09:40 UTC
(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.
Comment 43 Seweryn Kokot 2018-04-18 06:46:41 UTC
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.
Comment 44 Laszlo Valko 2018-04-18 07:25:07 UTC
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
$
Comment 45 Olaf Wucknitz 2018-04-18 07:31:43 UTC
(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.
Comment 46 Jani Nikula 2018-04-18 07:40:16 UTC
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.
Comment 47 Jean-François Dumont 2018-04-19 18:19:52 UTC
(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
Comment 48 bz-fdo 2018-09-14 16:39:44 UTC
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?
Comment 49 Jani Nikula 2018-09-17 06:46:59 UTC
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.