| Summary: | [g4x] Screen jitters every so often, especially when laptop under load | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Bryce Harrington <bryce> | ||||||||||||||||
| Component: | Driver/intel | Assignee: | Chris Wilson <chris> | ||||||||||||||||
| Status: | RESOLVED INVALID | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||||||||
| Severity: | normal | ||||||||||||||||||
| Priority: | high | CC: | jml | ||||||||||||||||
| Version: | 7.6 (2010.12) | Keywords: | regression | ||||||||||||||||
| Hardware: | x86-64 (AMD64) | ||||||||||||||||||
| OS: | Linux (All) | ||||||||||||||||||
| Whiteboard: | |||||||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||||||
| Attachments: |
|
||||||||||||||||||
|
Description
Bryce Harrington
2011-10-12 14:35:08 UTC
Jonathan has also tested with KMS debugging turned on, but nothing is printed to dmesg when the glitch occurs. I'm having him re-test natty again (to rule out hardware), as well as a clean oneiric image (to rule out possible local config), but suspect those won't turn up anything. A video to demonstrate the problem is at this link (file too large for bugzilla): https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/849782/+attachment/2401527/+files/VID_20110908_181612.3gp The quality of the video is unfortunately poor, but the glitch occurs around the 9-10 sec mark. Created attachment 52276 [details]
BootDmesg.txt
Created attachment 52277 [details]
CurrentDmesg.txt
Created attachment 52278 [details]
XorgLog.txt
Afaict from that video, the glitch was limited to a vertical shift of the chat pane within xchat. Is the glitch typically limited to a single window? It's a whole screen thing. That said, I do tend to run windows maximized, and it *is* a momentary effect, so I could be wrong. I doubt it though. Sorry for the delay in answering. I had typed out an answer before and hit "Commit", but no dice. A whole screen jitter is much more likely to be a FIFO underrun, which sadly are only reported with drm.debug=0x1 (along with every ioctl, so too noisy to be useful). Can you attach your boot dmesg with drm.debug=0xe, I want to confirm if this hardware also fixed FIFO watermarks due to a silicon bug, in which case there is very little we can do (if it does turn out to be a FIFO issue). Created attachment 52289 [details]
dmesg with drm.debug=0xe
Attached is the dmesg with drm.debug=0xe included. I've triggered the glitch on this boot.
Also, I've tested with clean natty and oneiric live USB sticks. I can confirm that the issue does occur with clean oneiric and does *not* occur with clean natty.
Ok, the important line is [drm:g4x_update_wm], Setting FIFO watermarks - A: plane=2, cursor=2, B: plane=26, cursor=6, SR: plane=59, cursor=6 which means that your hardware did not inherit the broken Crestline silicon, and an actual FIFO underrun is much less likely. Might still be worth running with drm.debug=0x1 and keeping an eye out for FIFO underrun warnings. And as is the nature of such issues, a change in rendering patterns is also likely to provoke running into different memory constraints (so a FIFO underrun is susceptible to userspace changes). Just to be clear, if I run with 0x1, what exactly am I grepping for in dmesg? if (pipe_stats[pipe] & PIPE_FIFO_UNDERRUN_STATUS)
DRM_DEBUG_DRIVER("pipe %c underrun\n", pipe_name(pipe));
So that would be "pipe [AB] underrun"
Created attachment 52329 [details]
dmesg w/ drm.debug=0x1
Here's w/ drm.debug=0x1. No 'pipe [AB] underrun' regex matches.
(In reply to comment #13) > Created an attachment (id=52329) [details] > dmesg w/ drm.debug=0x1 > > Here's w/ drm.debug=0x1. No 'pipe [AB] underrun' regex matches. To check the obvious as it is quite a short dmesg (compared to what I was expecting, very few ioctls i.e. very few drawing commands), did you observe flicker within that time? (In reply to comment #14) > (In reply to comment #13) > > Created an attachment (id=52329) [details] [details] > > dmesg w/ drm.debug=0x1 > > > > Here's w/ drm.debug=0x1. No 'pipe [AB] underrun' regex matches. > > To check the obvious as it is quite a short dmesg (compared to what I was > expecting, very few ioctls i.e. very few drawing commands), did you observe > flicker within that time? Yes, I did. Three separate incidents. Perhaps I mistyped the drm.debug kernel boot option? Also, to be clear, I'm uploading /var/log/dmesg. Do let me know if I should be doing something else. Btw, I'm very grateful for how responsive you've been. Thanks. Ah, iirc /var/log/dmesg is the dmesg from boot and not the latest message. To get the current dmesg, just type 'dmesg' (so dmesg > dmesg.txt and attach). Created attachment 52918 [details]
dmesg w/ drm.debug=0xe for real
This is a dmesg snapshot taken shortly after reproducing the bug with drm.debug=0xe.
Created attachment 52919 [details]
dmesg snapshot taken w/ drm.debug=0x1 after reproducing
This time with drm.debug=0x1.
FWIW, this issue still occurs regularly for me. Demonstrably a hardware issue. Same jitters have occurred on console and before OS boot. |
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.