Created attachment 143169 [details]
log files and computer information
Booting gives black screen with flickering. No recovery possible.
I am using the 5.0.0-rc2 kernel from:
> git clone git://anongit.freedesktop.org/drm-tip
I have incuded a WiFi driver and btrfs to the .config made with "make
I have used the "splash=silent quiet showopts drm.debug=0xe log_buf_len=4M"
kernel parameter to boot. The kernel boots into a flashing screen and the
computer can not be used. No image is visable. Text terminals (ctrl-alt-F1)
are also not visable. The flickering is mostly at the bottem of the screen,
once every two seconds (or something like that time).
The exact proces is the following:
- grub loads
- the kernel boots
- screen goes black, start flashing. White flashes about every second.
- the Opensuse tumblewheet logo appears which shows motion
- screen goes black with small flashes of white at the bottem of the screen.
This behavior is not present when running the opensuse leap 15.0 kernel :
I also made a commend about this bug at
Since i have tested it on the drm-tip kernel, i have reported the (same?) bug
Note that the hardware i am using is a chromebook (Dell). The firmware is
having bugs, which i can not solve. This can also interfere here.
In the logs is a file i made after the next (normal) boot:
# sudo journalctl --boot=-1 > journalctl_boot.txt
I could not make contact with the machine remotely, since wifi did not came
up. I therefore could only make a log afterwards. Additional log files are
therefore not included.
In the 'journalctl_boot.txt' i see the following line repeatetly:
[drm:intel_dp_start_link_train] [CONNECTOR:67:eDP-1] Link Training failed at link rate = 162000, lane count = 2
This with a whole lot of other lines. There is no clear error or warning in
Included is also a file "dmesg_before.txt". This is from a boot when additionaly
the "i915.fastboot=1" kernel parameter is set. Then the computer boots
correct. This file is the same as the file included in an other
bug-report. There the command "xset dpms force off" triggers the same
state. The file "dmesg_before.txt" is from before that command is given, thus
is from a normal running state.
Also includes are the machine info and lspci info, made when the machine is
running with the "i915.fastboot=1" kernel parameter set.
> inxi -bxx
System: Host: linux-6axq Kernel: 5.0.0-rc2test-g1fb7b31e074e x86_64 bits: 64 compiler: gcc v: 8.2.1 Console: N/A
dm: LightDM Distro: openSUSE Tumbleweed 20190115
Machine: Type: Desktop System: GOOGLE product: Lulu v: Pilot serial: 123456789 Chassis: type: 3 serial: N/A
Mobo: N/A model: N/A serial: N/A BIOS: coreboot v: N/A date: 03/28/2016
Battery: ID-1: BAT0 charge: 41.2 Wh condition: 70.1/67.0 Wh (105%) volts: 11.6/11.4 model: SMP-LIS DELL MJ serial: 0340
CPU: Dual Core: Intel Core i3-5005U type: MT MCP arch: Broadwell speed: 1743 MHz min/max: 500/2000 MHz
Graphics: Device-1: Intel HD Graphics 5500 driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:1616
Display: server: X.org 1.20.3 driver: intel tty: 180x31
Message: Advanced graphics data unavailable in console for root.
Network: Device-1: Intel Wireless 7260 driver: iwlwifi v: kernel port: 1840 bus ID: 01:00.0 chip ID: 8086:08b1
Drives: Local Storage: total: 111.79 GiB used: 71.60 GiB (64.0%)
Info: Processes: 189 Uptime: N/A Memory: 3.78 GiB used: 410.2 MiB (10.6%) Init: systemd v: 239 runlevel: 5
target: graphical.target Compilers: gcc: 8.2.1 alt: 8 Shell: dump-info-befor inxi: 3.0.29
I have made a new bug report of a bug triggered by the command:
> xset dpms force off
The behavior and logs of the bug are similar. I think this is related.
This is https://bugs.freedesktop.org/show_bug.cgi?id=109399
I think this is a duplicate of:
solution (on the mainline kernel):
git revert 49218c83e25b6f0708f246b07d570b2c43a98223
The problem is caused by the commit 49218c83e25b6f0708f246b07d570b2c43a98223
"drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode".
I have not dig into this code, but only tried is reverting helps. It does. The problem is gone without this commit.
*** Bug 109399 has been marked as a duplicate of this bug. ***
Manasi, patch is yours. Jani, this seems regression.
(In reply to Seppe from comment #0)
> Created attachment 143169 [details]
> log files and computer information
Please attach plain text files, one attachment per file.
Regression of a fix to another regression, makes your head explode.
When we started to handle clock recovery failures on link training, we knew there were eDP panels out there that failed the initial clock recovery but passed it in the channel equalization phase. We no longer have that failure path within channel equalization.
We failed to root cause the original problem, and added two layers of duct tape on top. So here we are.
Please try reverting *both*
1e712535c51a ("drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode")
c0cfb10d9e1d ("drm/i915/edp: Do not do link training fallback or prune modes on EDP")
How does that work?
Please do *not* use the i915.fastboot parameter for any further testing.
And please add drm.debug=14 module parameter, attach dmesg all the way from boot to the problem.
Created attachment 143244 [details]
journal booting the kernel minus two commits
On the stable-kernel i did:
> git checkout -b branch.4.20.4.test v4.20.4
> git revert 1e712535c51ab025ebc776d4405683d81521996d
Revert "drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode"
> git revert c0cfb10d9e1de490e36d3b9d4228c0ea0ca30677
Revert "drm/i915/edp: Do not do link training fallback or prune modes on EDP" revert
I build this kernel with the default .config options for the graphics.
Booted with the kernel parameters: splash=silent quiet showopts drm.debug=14 log_buf_len=4M
Two white flashes, then a black screen.
No logo, no nothing.
I could not login remotely. I therefore attached the full log from the journal.
The log.txt file shows:
Jan 28 21:01:22 linux-6axq kernel: [drm:intel_power_well_enable [i915]] enabling always-on
Jan 28 21:01:25 linux-6axq kernel: [drm:intel_power_well_disable [i915]] disabling always-on
Jan 28 21:02:00 linux-6axq kernel: [drm:intel_power_well_enable [i915]] enabling always-on
Jan 28 21:02:03 linux-6axq kernel: [drm:intel_power_well_disable [i915]] disabling always-on
Jan 28 21:03:00 linux-6axq kernel: [drm:intel_power_well_enable [i915]] enabling always-on
Jan 28 21:03:03 linux-6axq kernel: [drm:intel_power_well_disable [i915]] disabling always-on
Jan 28 21:04:00 linux-6axq kernel: [drm:intel_power_well_enable [i915]] enabling always-on
Jan 28 21:04:03 linux-6axq kernel: [drm:intel_power_well_disable [i915]] disabling always-on
Jan 28 21:04:30 linux-6axq kernel: [drm:intel_power_well_enable [i915]] enabling always-on
Jan 28 21:04:33 linux-6axq kernel: [drm:intel_power_well_disable [i915]] disabling always-on
When closing the lid of the laptop, the computer enters state S3. Still the battery consumption is higher than expected. The log then shows the same disable / enable sequence. I assume this is causing the higher than expected battery drain. I thought i would look into this later, but it might be related.
(In reply to Jani Nikula from comment #6)
> (In reply to Seppe from comment #0)
> > Created attachment 143169 [details]
> > log files and computer information
> Please attach plain text files, one attachment per file.
I have now included a text file.
Do you want the previous attachment (the tar.zip files) attached as separate files? Or did you mean just the new ones?
You cannot absolutely revert the "drm/i915/edp: Do not do link training fallback or prune modes on EDP" this patch since now with reverting this, it is falling back to lower value and pruning out the only native mode on the panel.
I think clearly this is a panel where we need to follow a sequence of retrying the CR after 5 failures on Channel EQ. To test this we will need to revert all the patches that fix the CR and Channel EQ sequencing for compliance.
Let me also meanwhile try to create a patch that retries CR after Channel EQ failure.
For me this can be marked as solved
I have changed/updated the BIOS to an UEFI one (and also updated the system). This because the kernel sometimes failed to load a hibernate image. Errors in dmesg then pointing at BIOS errors. These were the following two errors:
: Hibernate inconsistent memory map detected!
: PM: Image mismatch: architecture specific data
I was using the BIOS from the "Install/Update RW_LEGACY Firmware" option from Mr Chromebox ChromeOS Firmware Utility Script (https://mrchromebox.tech/#fwscript). I replaced this BIOS with "Full ROM firmware" option from the same script. This essentially replaced the whole BIOS with a new UEFI based one. This required me to remove the write-protect screw from my Dell Chromebook.
After reinstalling the system (required because of the UEFI system) i found that the new BIOS solved my hibernate problem, but also the black screen problem described on the page here. This was surprising for me, since the RW_LEGACY option is a normal option to use and i could not find bad side effects of it on the internet. I did not thought that changing the BIOS would also solve the "Black screen" problem described here. Else i would have tried this earlier.
I can now conclude that also changing something in the BIOS, solves this problem, apart from the "git revert 49218c83e25b6f0708f246b07d570b2c43a98223" solution.
I will no longer be able to reproduce the error. Only by flashing back the original BIOS and reinstall the system, this could be done. This is to much work for me.
I can not change the status to "solved", i therefore leave it as it is.
If additional information is required i can provide it.
Thanks for your feedback Seppe.
To proceed further we need a reproducer. Until then I can close this issue.
Please reopen the issue if it occurs with latest drmtip. (https://cgit.freedesktop.org/drm-tip)
Remember to attach the full dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M.