Created attachment 131178 [details]
dmesg for last good commit
Using openSuse Tumbleweed on Dell Latitude D830 with GM965 graphics. After kernel upgrade, the system freezes at boot, displays DRM error message on screen.
To isolate the error, I switched to vanilla kernel and bisected.
Expected result: system boots and shows graphical plymouth-password prompt
Result with (bad) vanilla kernel: boot process freezes for about 10 seconds, then resumes and displays password prompt on text console.
Comparison of dmesg reveals that the bad kernels have this in the dmesg output:
[ 5.859126] usb 7-1.2: Manufacturer: O2
[ 15.120085] [drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR* [CRTC:26:pipe A] flip_done timed out
[ 15.120095] [drm:drm_atomic_state_default_clear] Clearing atomic state ffff88007891a800
[ 15.120104] [drm:drm_atomic_state_free] Freeing atomic state ffff88007891a800
First bad commit:
Author: Maarten Lankhorst <email@example.com>
Date: Tue Jun 14 14:24:20 2016 +0200
Reapply "drm/i915: Pass atomic states to fbc update, functions."
The patch was reverted as part of the original nonblocking commit
support, but is required for any kind of nonblocking commit.
This is required to let fbc updates run async. It has a lot of
checks whether certain locks are taken, which can be removed when
the relevant states are passed in as pointers.
Signed-off-by: Maarten Lankhorst <firstname.lastname@example.org>
Reviewed-by: Patrik Jakobsson <email@example.com>
Signed-off-by: Daniel Vetter <firstname.lastname@example.org>
Last good commit:
Author: Daniel Vetter <email@example.com>
Date: Mon Jun 13 16:13:46 2016 +0200
drm/i915: Roll out the helper nonblock tracking
Right now still all blocking, no worker anywhere to be seen.
Reviewed-by: Maarten Lankhorst <firstname.lastname@example.org>
Signed-off-by: Daniel Vetter <email@example.com>
attached is dmesg output (with drm.debug=0x1e) for both commits
Created attachment 131179 [details]
dmesg for first bad commit
Created attachment 131180 [details]
Please try v4.11.
Created attachment 131229 [details]
dmesg for v4.11
Yes, v4.11 is still broken, see attached dmesg
(In reply to Markus Schauler from comment #4)
> Created attachment 131229 [details]
> dmesg for v4.11
> Yes, v4.11 is still broken, see attached dmesg
Still valid? Could you please try 4.13 https://www.kernel.org/ or drm-tip https://cgit.freedesktop.org/drm-tip
Created attachment 132848 [details]
(In reply to Elizabeth from comment #5)
> (In reply to Markus Schauler from comment #4)
> > Created attachment 131229 [details]
> > dmesg for v4.11
> > Yes, v4.11 is still broken, see attached dmesg
> Still valid? Could you please try 4.13 https://www.kernel.org/ or drm-tip
Yes, V4.13-rc1 is still broken, see attched dmesg output
Created attachment 132941 [details] [review]
[PATCH] drm/i915: Revert ea0000f0 "Roll out the helper nonblock
Can you try this patch?
Created attachment 132997 [details]
dmesg for patched version
(In reply to Jim Rees from comment #8)
> Created attachment 132941 [details] [review] [review]
> [PATCH] drm/i915: Revert ea0000f0 "Roll out the helper nonblock
> Can you try this patch?
patch did not apply cleanly against v4.13-rc1, so I manually deleted the 10 lines.
Result: boot no longer hangs, but desktop (here: KDE) does not properly start: takes long time to start, desktop background not properly displayed, window manager not working. Dmesg output is attached
Can you try the patch on 4.12? It would be interesting to know if it's the same bug. I have not tested 4.13, but this patch fixes the flip_done timeout on 4.12 for me.
(In reply to Jim Rees from comment #11)
> Can you try the patch on 4.12? It would be interesting to know if it's the
> same bug. I have not tested 4.13, but this patch fixes the flip_done timeout
> on 4.12 for me.
Yes, this patch fixes the flip_done timeout on v4.12 on by Dell. It also renders the system unusable.
Symptoms: It seems that the X11/KDE is starting fine, but on virtual terminal vt7, there is only the boot-graphics shown. Mouse pointer is displayed and follows mouse movements. Sometimes, by switching between vt1,vt2, vt3,vt4,vt5,vt6 and vt7 I get access to my proper desktop (which has been running somewhere in the background). Could it be that X11 draws into one buffer, but the patched display driver displays anouther buffer?
Can you boot with enable.fbc=0?
Yes, still listening. I will have access to my laptop after 19.12.2017 only.
Created attachment 136351 [details]
dmesg patched 4.12 kernel, booting with enable.fbc=0
Booting with enable.fbc=0 fixes part of the problem: the systems boots into the correct console, BUT the system is unusable: KDE/X does not start properly.
Sometimes, the window manger is not working (windows are restored from previous session, but window title bar is missing, windows cannot be resized/moved), sometimes, the transition from the boot/startup animation (here: the opensuse lightbulb) to the real desktop background does not happen.
Can you also try with i915.fbc=0 and the workaround from:
Said workaround solves some of the problems.
booting with video=SVIDEO-1:d i915.fbc=0 does not display any errors when booting, X11 / KDE plasma 5 seems to start normally, but the KDE taskbar is not present.
I use KDE with the "restore session" option, this gives me at least a terminal window to work with. When booting with an old 4.4 kernel, everything is back to normal, so the problem seems not to be linked to the saved KDE session information.
So, the workaround helps, but the result is still a system that is unusable.
dmesg output is attached.
Created attachment 136718 [details]
dmesg patched 4.12 kernel, booting with enable.fbc=0, video=...
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.
bug is still valid
Marteen, any idea on how to proceed?
Do you have any udpates?
The TV vblank timeouts are bug #93782, but I can't quite figure out what other problems have been reported here so not sure if we want to mark this as a duplicate.
Lots of talk about fbc in earlier comments which doesn't make sense considering we don't enable fbc on these platforms by default.
No updates in a while. I'll just mark this as a dupe of 93782
*** This bug has been marked as a duplicate of bug 93782 ***