Framebuffer : Vblank timeout #9
Comments
|
Start working on compilation of 4.16-rc4... |
|
Prompting kernel config questions this time... Restart script after |
|
PASSED! No vblank timeout dmesg_4.16-rc4-RockMyy-16Bits-Edition.log |
|
Alright... My guess is that it could be either this change : Both were introduced with the kernel 4.16-rc7. One way to test one of the patches, without the other, would be to :
If that still fails... It will be time for some "printk" debugging. |
|
Ok, start compile 4.16-rc7 |
|
With both changes: git apply -R ./GetFB.patch git apply -R .／DRMAST.patch Oh, should have backup linux/ before git apply... |
|
You can do I'm surprised you don't have this file, since it's still present in the latest 4.18-rc. Anyway, we're sure that it's between the rc4 and rc7. So if you're good for a last compilation, try the -rc6. If the problem doesn't occur with the -rc6, that it's clearly in between. |
|
Oops, stupid me! I actually execute the Anyway, saved linux/ of rc7 git apply -R .／DRMAST.patch So not rc7. Go for -rc6 now... |
|
rc6 PASSED! I have both linux/ ready: |
|
Here's the patch that should apply to both. This will pollute the logs so get the logs quickly. From aef02775f33ba10090388316648e1206f45e74fc Mon Sep 17 00:00:00 2001
From: "Miouyouyou (Myy)" <myy@miouyouyou.fr>
Date: Tue, 24 Jul 2018 21:18:17 +0200
Subject: [PATCH] Let's pollute the logs
To get some informations about CRTC.
Not really working at the moment.
Most informations are bogus.
Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr>
---
drivers/gpu/drm/drm_atomic_helper.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index ae3cbfe9e..37f1fc62a 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1345,6 +1345,23 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
drm_crtc_vblank_count(crtc),
msecs_to_jiffies(50));
+ dev_warn(dev->dev, "(Myy)\n"
+ "\tCRTC[%i] (%d : %s)\n"
+ "\tOld state last vblank Count : %llu\n"
+ "\tCRTC Vblank_count : %llu\n"
+ "\tWait Event Timeout Ret : %d\n"
+ "\tCRTC Interrupt enabled ? %d\n"
+ "\tCRTC Interrupt number : %d\n"
+ "\tCRTC Device : %p\n"
+ "\tArgument Device : %p\n",
+ i, crtc->base.id, crtc->name,
+ old_state->crtcs[i].last_vblank_count,
+ drm_crtc_vblank_count(crtc),
+ ret,
+ (crtc->dev ? crtc->dev->irq_enabled : 0),
+ (crtc->dev ? crtc->dev->irq : 0),
+ crtc->dev, dev);
+
WARN(!ret, "[CRTC:%d:%s] vblank wait timed out\n",
crtc->base.id, crtc->name);
--
2.16.4Once you're done with the patch, try to the following : And see how it goes. |
|
Note that this patch should be applied to both kernels and tested on both, in order to see if there's any difference between them. The last commands only target the rc7. |
|
What's wrong? linux/ is a clone of linux_4.16-rc6 |
|
Resolved: |
|
this is linux_4.16-rc7 after "Applying: Let's pollute the logs" patch: |
|
Which version does /usr/src/linux links to ? |
|
It is 4.16-rc7, I even deleted linux/ and restarted the script again from scratch:
|
|
Well, let's try it like that than : I'm just wondering if some Clock patches generated issues with the HDMI detection. |
|
Hmm, I guess I messed up the vblank count display. I'll try to modify my script so that you can pull the kernel sources at one specific commit... It seems like a very subtle bug. If you remove the timestamps of both dmesg logs and you cut them before the first "Myy" log and do a diff, both logs are almost identical. That some tricky bug... Could you test a compilation by doing like this : mv linux{,.bak}
wget https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapshot/linux-3215b9d57a2c75c4305a3956ca303d7004485200.tar.gz -O linux.tgz
tar zxvf linux.tgz
mv linux-3215* linux
cd linux
git init .
git add .
git commit -m "My wonderful kernel"
cd ..And then run the usual script. |
|
FYI, Nodepad++ for Windows can compare the logs without cutting time stamp. I will try that out tomorrow... |
|
Done |
|
Was the screen plugged-in during the boot sequence ? I'm reading this, in your last log : |
|
Oops. switched off |
|
If you still have these issues, feel free to reopen this ticket. Meanwhile, I'm closing it due to no activity. |
On some configurations, the framebuffer fails to initialize the screen correctly.
It seems that the problem started to occur since some 4.16-rcX version.
In such events, the system boots fine and X11 starts without issues.
So it's highly probable that this is a framebuffer related issue.
The text was updated successfully, but these errors were encountered: