| Summary: | [945GM FBC] FBC causes underruns & flicker | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Adam Jones <adam> | ||||||||||||||||||||
| Component: | Driver/intel | Assignee: | Jesse Barnes <jbarnes> | ||||||||||||||||||||
| Status: | RESOLVED DUPLICATE | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||||||||||||
| Severity: | major | ||||||||||||||||||||||
| Priority: | high | CC: | dave, eich, kent.liu, ling.yue, martin.pitt, mat, quanxian.wang, raghua1111+list, sndirsch, squealernet | ||||||||||||||||||||
| Version: | 7.4 (2008.09) | Keywords: | NEEDINFO | ||||||||||||||||||||
| Hardware: | x86-64 (AMD64) | ||||||||||||||||||||||
| OS: | Linux (All) | ||||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||||||||||
| Bug Depends on: | |||||||||||||||||||||||
| Bug Blocks: | 18858, 20276 | ||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||
|
Description
Adam Jones
2008-11-21 06:03:39 UTC
Created attachment 20589 [details] [review] don't modify dsparb It may be that we're not doing DSPARB right on your system. Does this patch help? (In reply to comment #1) > It may be that we're not doing DSPARB right on your system. Does this patch > help? After running with it for half an hour or so, I've not seen any underruns or glitches yet, and previously they happened at least every few minutes. I'd say it fixes it, yes. (Looking at the patch, I'm guessing it's not really a long-term solution, but hopefully it points in the right direction. Happy to test alternative fixes if need be - thank you.) (In reply to comment #2) > After running with it for half an hour or so, I've not seen any underruns or > glitches yet, and previously they happened at least every few minutes. Sadly, a correction: Whilst I'm no longer getting messages about underruns in the X log, I am still seeing some occasional screen flicker (although perhaps rather less often than before). Can you attach your X log after enabling the modedebug option in your xorg.conf and after seeing the problem? Another thing to try is to disable framebuffer compression, since that will prevent the pipe/plane swap. Created attachment 21334 [details]
Xorg logfile with ModeDebug=1
Here's a new logfile with ModeDebug set to true and driver version 2.5.1.
is there any (binary) solution yet? I have xorg-version which is shipped with opensuse 11.1 on the dell mini 9 (gma950 (?)) and the backlight flickering is so annoyning every 2-20 seconds... the xorg.conf entry does not do the trick for me: Option "FramebufferCompression" "False" (In reply to comment #6) > is there any (binary) solution yet? I have xorg-version which is shipped with > opensuse 11.1 on the dell mini 9 (gma950 (?)) and the backlight flickering is > so annoyning every 2-20 seconds... Just to be clear: on my machine the backlight is not affected (as far as I can tell). The "flicker" generally appears as though the screen image jumps sideways momentarily, or as a blank black screen for a frame or so. Created attachment 21733 [details] [review] update 945 fifo entry count Looks like 945 might have 128 FIFO entries rather than the 96 we had coded. Can you try this patch? *** Bug 19304 has been marked as a duplicate of this bug. *** A few clarifications : - This occurs (more specifically Bug 19304) occurs with Ubuntu 8.10 as well (intel driver 2.4.1). The bug description says it does not occur with 2.4.x. - The bug sets hardware to x86-64. Not sure if it matters. Any pointers on how I can try out the patch with my freshly installed Ubuntu 8.10? "Keywords" says "NEEDINFO".. what other info is needed? thanks. The patch does not fix things for me (no noticeable difference), so either my bug (bug 19304) is different and needs un-dup'ing, or the patch is generally insufficient. Thank you! Jesse, Tha patch also does not work for bug 17988. Is there any idea for that? (In reply to comment #8) > Looks like 945 might have 128 FIFO entries rather than the 96 we had coded. > Can you try this patch? Oddly, after upgrading to kernel 2.6.28, the flicker seems to have gone away, although the buffer underrun messages were still present. (Sadly the 3D performance seems to have collapsed - Stellarium has gone from ~30fps to ~3 - but that's almost certainly a separate issue. I also now get the following errors earlier in the log: (EE) intel(0): Failed to set tiling on front buffer: rejected by kernel (EE) intel(0): Failed to set tiling on back buffer: rejected by kernel (EE) intel(0): Failed to set tiling on third buffer: rejected by kernel (EE) intel(0): Failed to set tiling on depth buffer: rejected by kernel ) With this patch I've not yet (about 15 minutes) had an underrun message. I'll add another comment later if I see one. I have been on kernel 2.6.28 for quite a long time, and it didn't change anything wrt. the flicker and the occasional total breaking (thousands of underruns, and irrecoverable black screen) I think this should be a high priority bug. Pretty much all the netbooks have Intel 9xxGME and the bug affects current Ubuntu. (In reply to comment #13) > (In reply to comment #8) > > Looks like 945 might have 128 FIFO entries rather than the 96 we had coded. > > Can you try this patch? > With this patch I've not yet (about 15 minutes) had an underrun message. I'll > add another comment later if I see one. After a couple of days with this patch applied, still no underrun messages. I'd say that problem's gone on my hardware - thanks. Note that a few underruns are a normal part of mode setting, but flicker and black screens after running for awhile definitely shouldn't happen. Anyway sounds like the patch is helping at least some people so I've posted it for review to include in the next release. I think we should un-dup this from bug 19304. bug 19304 affects existing releases and most likely a different problem. Well, I'll wait until Martin confirms/denies that before un-duping (after all if the same patch fixes both problems there's no need for two bugs to be open). Martin Pitts mentioned above that the patch did not fix his problem (comments on Jan 20th and Jan 22nd, his last two comments). Not sure if he has a later patch not mentioned on this bug. Oh you're right, sorry. I was just looking at his comments on #19304. Will un-dup. I re-confirm that I tested this patch, and it didn't change anything at all. However, I have used the suggestion in https://bugs.launchpad.net/bugs/311895 since yesterday (Option "FramebufferCompression" "off"), and that *seems* to do the trick. I want to test it a little longer before fully confirming, especially since the most recent X.org stopped logging the underruns in Xorg.0.log, and I got too used to the occasional screen flicker, so I might well have ignored them. But my screen went black (or brown, or white) irrecoverably after a day or two without that option. If that doesn't happen any more either, I'll report this finding to bug 19304. Thanks! I got the same problem on my ausus eeeBox (intel 2.6.1). Setting Option "FramebufferCompression" "False" in the drivers section fixed the problem for me - haven't had any hangs since then. I'll attach my lspci output if it helps. Created attachment 23178 [details]
lspci -vvv of asus eeeBox
Created attachment 24060 [details] [review] set watermarks based on mode calculation Can you guys give this patch a try? It uses a more proper watermark calculation and sets the various planes to what seem like reasonable values on my 945 test machine... I'm the reporter of bug 19304, but since these are closely related, I tried this patch. More specifically, I replaced the patch from http://bugs.freedesktop.org/show_bug.cgi?id=19304#c13 (fixed for the s/0x3f/1/ error) with Jesse's recent one (http://bugs.freedesktop.org/attachment.cgi?id=24060), applied to version 2.6.3. This survived a quick test on my internal LVDS (1280x800), but when I dock it (1280x1024 TFT, internal LVDS off) I get major screen flicker on just about every activity (key press, light I/O). It reminded me a lot of the situation of the original patch in bug 19304, with the "0x3f" initial value. Or did I misunderstood this, and both patches need to be merged together somehow? I'll attach registers and xorg.log, for the record. Created attachment 24072 [details]
registers with patch applied
This is on
00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub [8086:27a0] (rev 03)
Subsystem: Dell Device [1028:0201]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 0
Capabilities: <access denied>
Kernel driver in use: agpgart-intel
Kernel modules: intel-agp
Linux 2.6.28.8, -intel 2.6.3, i386.
Created attachment 24073 [details]
x.org log with patch applied
Hm, the plane a fifo entry count seems low, and the watermark seems too high. The hw will do a FIFO fetch when the number of entries programmed are free in the fifo, so in your case it looks like we won't fetch a new set of data until 20 lines are free. In the plane B case this might be ok, since it has a much larger number of fifo entries allocated to it, but for plane A it's probably a bit off... I'll see if I can refine the calculation further. Created attachment 24375 [details] [review] Updated watermark calculations This one uses what I hope is the correct calculation; we figure out the total number of entries needed for a given dotclock & depth, then use that number to determine when to start fetching new lines into the FIFO by subtracting... Looks great for me so far on my i945, see https://bugs.freedesktop.org/show_bug.cgi?id=19304#c41 for testing details. For completeness I attach the register dump, after some heavy load and testing, and a suspend cycle. Created attachment 24393 [details]
registers with version 5 of the patch, working perfectly
Ok since the patch seems to fix this and 19304 I'm marking as a dup *** This bug has been marked as a duplicate of bug 19304 *** |
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.