[i945] spontaneous black screen (major pipe-A underrun)

Created an attachment (id=21511)
intel_reg_dump when working

Created an attachment (id=21512)
intel_reg_dump after going black

Created an attachment (id=21513)
Xorg.0.log

X.org log which shows the plethora of pipe-A underruns.

When this happens, I get the following kernel messages:

Dec 28 10:25:07 tick kernel: [ 5559.025081] mtrr: no MTRR for d0000000,10000000 found
Dec 28 10:25:08 tick kernel: [ 5560.478087] apm: BIOS not found.

$ diff -U 0 intel_regs.works.txt intel_regs.black.txt
--- intel_regs.works.txt 2008-12-28 10:33:22.000000000 +0100
+++ intel_regs.black.txt 2008-12-28 10:24:50.000000000 +0100
@@ -57 +57 @@
-(II): PIPEASTAT: 0x00000203 (status: VSYNC_INT_STATUS VBLANK_INT_STATUS OREG_UPDATE_STATUS)
+(II): PIPEASTAT: 0x80000000 (status: FIFO_UNDERRUN)
@@ -132 +132 @@
-(II): FBC_CONTROL: 0x43e847e2
+(II): FBC_CONTROL: 0xc3e847e2
@@ -134 +134 @@
-(II): FBC_STATUS: 0x20000000
+(II): FBC_STATUS: 0x60000000
@@ -138 +138 @@
-(II): MI_MODE: 0x00000200
+(II): MI_MODE: 0x00000000

I think this might be a DUP, can you try the patch in 18651?

*** This bug has been marked as a duplicate of bug 18651 ***

I'm building/installing -intel with this patch applied. I'll report back in a day or two, since the underruns only start to happen after a couple of hours (presumably when I'm doing particular things with my computer, but I'm not able to pinpoint what triggers it).

Thanks!

I found out that starting kvm and doing some other window juggling triggers the quick underrun (i. e. the flickering, not the total blackout) pretty reliably.

With the proposed patch applied, I still get underruns, though. I'll let it run for a couple of days to see whether I get any black screen still.

Looks separate from 18651 unfortunately.

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 back here.

Two days have passed with Option "FramebufferCompression" "off", and I didn't notice a single flickering, nor encounter another black screen. Thus I'm fairly sure that this is at least a very good (if not perfect) workaround for the problem, and might also point to the root cause.

Just reiterating that I never ever observed those problems with the internal LVDS (1280x800), just with the external TFT (1280x1024).

</facts>

<wild and unqualified speculations>
May it be possible that compressing the framebuffer just occasionally takes too long, once it gets bigger than a critical treshold (which lies somewhere in between 1280x800 and 1280x1024 pixels)? Any idea why it would sometimes not recover from this at all any more, perhaps if it takes too long, and it cannot 'catch up' any more?

Thanks!

That mirrors my experience, too.

I'm on a Mac Mini with a GM945 video... using the TV-out at 1024x768 for several months I never had any issues, and when I changed to using DVI->HDMI output on it at 1280x720, I started getting the solid color screen really frequently. Disabling the FramebufferCompression about three weeks ago did make the machine usable again. I've run the thing for 5 or 6 hours per day on a daily basis (I have it hooked up to a TV using MythTV on it), and although I have still gotten that solid color screen since then, it's only happened once in all that time (as opposed to every 5 or 10 minutes before). I was getting that periodic flicker before, too, and that's infrequent enough that I don't notice it anymore if it's still happening at all.

In #18491 there's a patch (https://bugs.freedesktop.org/attachment.cgi?id=22319) to mess with the FIFO watermark values that might help. But more than that, it includes a patch to dump the FIFO watermark regs to the intel_reg_dumper tool. Can someone apply it and capture a reg dump both before and after starting X on their machine with the patch applied?

The spontaneous black screen is almost surely caused by a series of pipe underruns. That generally happens if our memory arbitration settings are off (so a given pipe can't get its pixels due to some other pipe hogging the memory interface) or the FIFO watermark regs being incorrect (we fetch a new chunk of pixels too late and end up missing our window of time to feed them to the pipe).

The framebuffer compression hardware periodically compresses the framebuffer into a private section of memory (the compressed buffer), temporarily increasing memory activity; it could be that we're not accounting for that in the FIFO settings, so the screen goes black after the first compression pass (which is usually after about 15s iirc).

I enabled FB compression again and applied the patch in bug 18491. It had quite a dramatic regressive effect: the screen now flickers at each hard disk access, mouse movement, or key press, and only stands still if absolutely nothing happens.

I captured the registers right after boot, then after X and gdm started, and finally after GNOME was fully running.

Created an attachment (id=22944)
regs with patch from #18491: right after boot

Created an attachment (id=22945)
regs with patch from #18491: after X and gdm start

Created an attachment (id=22946)
regs with patch from #18491: GNOME fully running

That's the watermark change you asked for:

--- boot-nox.regs 2009-02-14 15:49:55.000000000 +0100
+++ boot-gdm.regs 2009-02-14 15:50:15.000000000 +0100
@@ -31,2 +31,2 @@
-(II): FWATER_BLC: 0x03060106
-(II): FWATER_BLC2: 0x00000306
+(II): FWATER_BLC: 0x033f033f
+(II): FWATER_BLC2: 0x0000033f

It doesn't change any further after starting GNOME (which does xrandr stuff, etc.) Other registers do change during GNOME startup, though.

Heh, I think I had the watermark regs backwards... I'll have to spin a new patch, but you could try changing the watermark value in the patch in the meantime:

watermark = (3 << 8) | 0x3f

should instead be something like

watermark = (3 << 8) | 1

I did that change, much better. :-) It doesn't flicker so badly any more, and the watermark reg diff is now

$ diff -U 0 boot-nox.regs boot-gnome.regs |grep WATER
-(II): FWATER_BLC: 0x03060106
-(II): FWATER_BLC2: 0x00000306
+(II): FWATER_BLC: 0x03010301
+(II): FWATER_BLC2: 0x00000301

I have to run now, so I can't do the full test which triggers the original underrun; will report back tomorrow or Monday.

Thank you so far and have a nice weekend!

Created an attachment (id=22956)
regs with fixed patch from #18491: right after boot

Yay, fix pushed!

commit 7662c8bd6545c12ac7b2b39e4554c3ba34789c50
Author: Shaohua Li <email address hidden>
Date: Fri Jun 26 11:23:55 2009 +0800

    drm/i915: add FIFO watermark support

Oops, I am terribly sorry. We currently put i915 into the initramfs, and it gets loaded from there. When I built the module with the patch, I forgot to update the initramfs, so all these successful tests were actually done with the original i915 from 2.6.31rc1.

Later this afternoon some other package updated the initramfs, and now the screen goes entirely and irrecorverably black when booting, both when docked (external DVI) and when undocked (internal LVDS).

So, perhaps you should revert this from your tree until this is investigated further? So far, I don't seem to have this underrun problem at all with 2.6.31rc1, thus I leave the bug as "resolved".

Uh-oh, ok thanks for the heads-up. I'll look at this. Can you modprobe your drm with debug=1 so we can see what the watermark values end up being on your machine? It would help if you could confirm that this particular patch caused the problem too, was that the only change or was there another kernel update as well?

It wasn't the only patch, I also applied the tiny patch from bug 20520 (register restoring ordering fix for resuming). However, I tested that patch in isolation before, and it worked fine. Also, I don't think that code path is active on boot. There was no other kernel update.

I'll send detailled debugging information tomorrow (I hope I can ssh into the machine still, or it gets logged far enough), bed time for today. I just wanted to give you an early warning to perhaps defer propagation of the patch (or just revert it for now, since it just works without it.

Created an attachment (id=27329)
logs for early/late i915 loading with drm debugging

So, first I turned on DRM debugging and dmesg capturing:

$ cat /etc/rcS.d/S80dmesg
#!/bin/sh
dmesg > /var/log/dmesg-`date +%T`
$ cat /etc/modprobe.d/drmdebug.conf
options drm debug=1

In the attached logs I renamed the dmesg files from timestamps to situation descriptions, such as "dmesg-31rc1-vanilla-early-2GB-ok.txt"

Then I tested all possible combinations of 2.6.31rc1 with/without this patch, with 1GB or 2 GB RAM, and with "
early" or "late" loading of i915/drm.

early: modules are contained and loaded by initramfs, i. e. pretty much as one of the first things after the k
ernel starts to boot

late: I booted without an initramfs, thus init starts readahead, sets the hostname and keyboard layout, and th
en starts udev which does an "udev trigger" and causes modules such as drm and i915 to be loaded, which in tur
n does KMS.

In earlier Karmic (2.6.30 release candidates), we didn't put i915/drm into the initramfs, and it worked fine (just looked a bit ugly since mode got switched halfway through boot). Now I noticed that this late loading doe
s not work any more for some reason, not with 2.6.30 final, not with 31rc1, or with 31rc1+your patch. That is
a bug in itself, and sounds pretty unrelated to this pipe underrun issue, so perhaps I should report it separa
tely?

Results from this testing:
 * late loading never works, I always get LVDS and DVI turned off
 * early loading works with .30 final and .31rc1 vanilla
 * with this patch applied, it never works, and worse, I don't even get a dmesg captured; this means that the
boot doesn't even get to rcS/70. Sounds like it wedges display and causes a kernel panic? Anything I can do to
 debug this?
 * 1 GB/2 GB does not make any difference in any test case

(In reply to comment #87)
> Then I tested all possible combinations of 2.6.31rc1 with/without this patch,
> with 1GB or 2 GB RAM, and with "
> early" or "late" loading of i915/drm.
>
> early: modules are contained and loaded by initramfs, i. e. pretty much as one
> of the first things after the k
> ernel starts to boot
>
> late: I booted without an initramfs, thus init starts readahead, sets the
> hostname and keyboard layout, and th
> en starts udev which does an "udev trigger" and causes modules such as drm and
> i915 to be loaded, which in tur
> n does KMS.

Sounds like a good set of combinations, thanks for testing.

> In earlier Karmic (2.6.30 release candidates), we didn't put i915/drm into the
> initramfs, and it worked fine (just looked a bit ugly since mode got switched
> halfway through boot). Now I noticed that this late loading doe
> s not work any more for some reason, not with 2.6.30 final, not with 31rc1, or
> with 31rc1+your patch. That is
> a bug in itself, and sounds pretty unrelated to this pipe underrun issue, so
> perhaps I should report it separately?

One thing jumped out between the early (working) and late (broken) logs: in the broken ones there's no line for the fbcon loading & initializing. Which would leave your display blank if/until X starts. Maybe that's missing from the load in the late case?

> Results from this testing:
> * late loading never works, I always get LVDS and DVI turned off
> * early loading works with .30 final and .31rc1 vanilla
> * with this patch applied, it never works, and worse, I don't even get a dmesg
> captured; this means that the
> boot doesn't even get to rcS/70. Sounds like it wedges display and causes a
> kernel panic? Anything I can do to
> debug this?
> * 1 GB/2 GB does not make any difference in any test case

Ugh, ok so it's probably not a pipe underrun then if it kills the whole machine (at least I hope not); could be a kernel panic. You could try netconsole (modprobe netconsole netconsole=<params> and then use nc on another machine, the kernel Documentation/ directory has some info on that); it might capture a panic if you load the module by hand with the netconsole running.

> One thing jumped out between the early (working) and late (broken) logs: in the
> broken ones there's no line for the fbcon loading & initializing. Which would
> leave your display blank if/until X starts. Maybe that's missing from the load
> in the late case?

Indeed, I discussed that with our initramfs/boot guru. So that's not a concern here.

> Ugh, ok so it's probably not a pipe underrun then if it kills the whole machine
(at least I hope not); could be a kernel panic. You could try netconsole

Thanks for the netconsole hint, that worked beautifully. Indeed it catches a nice trace in the watermark updating:

[ 489.298734] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
[ 489.298908] IP: [<ffffffffa030f1af>] intel_update_watermarks+0xcf/0xd40 [i915]
[ 489.299056] PGD 0
[ 489.299152] Oops: 0000 [#1] SMP
[ 489.299289] last sysfs file: /sys/devices/pci0000:00/0000:00:02.0/drm/card0/dev
[ 489.299384] CPU 0
[ 489.299481] Modules linked in: i915(+) drm netconsole i2c_algo_bit configfs snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss snd_pcm arc4 joydev ecb snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer iwl3945 iwlcore iTCO_wdt iTCO_vendor_support snd_seq_device mac80211 led_class snd psmouse dell_wmi dell_laptop cfg80211 soundcore snd_page_alloc usb_storage usbhid serio_raw dcdbas video output tg3 fbcon tileblit font bitblit softcursor intel_agp [last unloaded: drm]
[ 489.300005] Pid: 2208, comm: work_for_cpu Not tainted 2.6.31-1-generic #14-Ubuntu Latitude D430
[ 489.300005] RIP: 0010:[<ffffffffa030f1af>] [<ffffffffa030f1af>] intel_update_watermarks+0xcf/0xd40 [i915]
[ 489.300005] RSP: 0018:ffff8800229e98b0 EFLAGS: 00010202
[ 489.300005] RAX: 0000000000000000 RBX: ffff880022966800 RCX: ffffffffa03244fb
[ 489.300005] RDX: ffffffffa0321a20 RSI: ffffffffa0324518 RDI: 0000000000000001
[ 489.300005] RBP: ffff8800229e9930 R08: 0000000000000000 R09: 000000000001a400
[ 489.300005] R10: 0000000000000500 R11: 0000000000000000 R12: ffff880022967000
[ 489.300005] R13: 000000000001a400 R14: ffff8800229674a0 R15: 0000000000000001
[ 489.300005] FS: 0000000000000000(0000) GS:ffff8800019b4000(0000) knlGS:0000000000000000
[ 489.300005] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[ 489.300005] CR2: 0000000000000038 CR3: 0000000001001000 CR4: 00000000000006b0
[ 489.300005] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 489.300005] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 489.300005] Process work_for_cpu (pid: 2208, threadinfo ffff8800229e8000, task ffff88003d5416b0)
[ 489.300005] Stack:
[ 489.300005] ffff8800229e9910 ffffffffa0317a5a ffff000100000038 ffff8800229e98f0
[ 489.300005] <0> ffff000100010038 ffff8800229e98e0 0000000000000001 0000000000000002
[ 489.300005] <0> ffff8800229e0009 0000000000000000 ffff8800229e9920 ffff880022f3b000
[ 489.300005] Call Trace:
[ 489.300005] [<ffffffffa0317a5a>] ? intel_sdvo_read_byte+0x6a/0xc0 [i915]
[ 489.300005] [<ffffffffa031161c>] intel_crtc_dpms+0xb0c/0xef0 [i915]
[ 489.300005] [<ffffffffa0317cff>] ? intel_sdvo_set_active...

jbarnes| pitti: just wondering if you can gdb your i915.o and do a "list *intel_update_watermarks+0xcf"

Seems I need to build the module with debugging or so:

(gdb) list *intel_update_watermarks+0xcf
No symbol table is loaded. Use the "file" command.

Sorry, this kernel debugging is all new to me :/

I now built the module with "CONFIG_DEBUG_INFO=1 make -C /usr/src/linux-headers-2.6.31-1-generic/ M=`pwd` modules", so they have debug info now and gdb works. But I guess due to the rebuild the offsets were all scrambled, so I need to get the backtrace again. Stay tuned..

So apparently the offset is even stable across rebuilds. I captured the trace again, and it looks exactly like the previous trace, so I'm not copying that again.

(gdb) list *intel_update_watermarks+0xcf
0x101af is in intel_update_watermarks (/home/martin/ubuntu/kernel/linux-2.6.31/drivers/gpu/drm/i915/intel_display.c:1918).
1913 intel_crtc->pipe, crtc->mode.clock);
1914 planeb_clock = crtc->mode.clock;
1915 }
1916 sr_hdisplay = crtc->mode.hdisplay;
1917 sr_clock = crtc->mode.clock;
1918 pixel_size = crtc->fb->bits_per_pixel / 8;
1919 }
1920 }
1921
1922 /* Single pipe configs can enable self refresh */

So I guess it crashes because crtc->fb is NULL, since fbcon is not loaded yet?

BTW, this happens whether or not 'fbcon' gets loaded before.

Also confirmed when applying the patch to 2.6.31rc2.

On Mon, 6 Jul 2009 23:03:19 -0700 (PDT)
<email address hidden> wrote:
> --- Comment #91 from Martin Pitt <email address hidden> 2009-07-06
> 23:03:18 PST --- So apparently the offset is even stable across
> rebuilds. I captured the trace again, and it looks exactly like the
> previous trace, so I'm not copying that again.
>
> (gdb) list *intel_update_watermarks+0xcf
> 0x101af is in intel_update_watermarks
> (/home/martin/ubuntu/kernel/linux-2.6.31/drivers/gpu/drm/i915/intel_display.c:1918).
> 1913 intel_crtc->pipe,
> crtc->mode.clock);
> 1914 planeb_clock =
> crtc->mode.clock; 1915 }
> 1916 sr_hdisplay = crtc->mode.hdisplay;
> 1917 sr_clock = crtc->mode.clock;
> 1918 pixel_size =
> crtc->fb->bits_per_pixel / 8; 1919 }
> 1920 }
> 1921
> 1922 /* Single pipe configs can enable self refresh */
>
> So I guess it crashes because crtc->fb is NULL, since fbcon is not
> loaded yet?

Ah yes, that helps a lot, thanks. I'll fix that up.

Created an attachment (id=27540)
fix up FIFO programming

The stuff that went upstream falls into the "how did that ever work" category. We were just getting lucky that the calculations always resulted in the most aggressive FIFO programming. This corrects that and should also fix your hang.

Re-opening this as the FIFO master bug.

*** Bug 18702 has been marked as a duplicate of this bug. ***

*** Bug 18491 has been marked as a duplicate of this bug. ***

Does that patch go on top of the "most recent, KMS version of the patch" (https://bugs.freedesktop.org/attachment.cgi?id=26930) or does it replace it? I suppose the latter, since the new one doesn't touch crtc->fb at all, but it looks very different from the older one.

Thanks! Martin

It sits on top of current drm-intel-next bits.

Created an attachment (id=27575)
more fixes for FIFO programming

I tested on my 855 machine and found some bugs in that configuration. So I cleaned up the code a little more and fixed things up. This one applies on top of the drm-intel-next branch.

For the record, I get a warning after applying the patch to drm-intel-next:

/home/martin/ubuntu/kernel/drm-intel-next/i915/intel_display.c: In function ‘intel_find_pll_g4x_dp’:
/home/martin/ubuntu/kernel/drm-intel-next/i915/intel_display.c:834: warning: ‘clock.vco’ is used uninitialized in this function

Will test now.

Applied on top of current intel-drm-next, so far no noticeable difference (in other words, everything still works just fine). I'll use that driver for a few days now, will report back if anything regresses.

Hey Jesse, sorry I haven't been able to try the patch that you sent me yet. I did real quick install the newest version of the video-intel driver, which on Arch is 2.7.99.901-3. This is on the 2.6.30 kernel (i686). It still exhibits the same behavior (flickering after resume from suspend to ram), but the frequency of the flicker is substantially reduced....it's actually usable now, with just the occasional flicker. Better performance than the vesa driver!!

I'll still attempt the patch at some point when I get a chance. Send me a new one if this info changes anything.

Scott

Sorry guys....I have to retract my previous post after using intel-video-newest for a couple of hours. Worked fine with normal browsing, and program open/closing, but as soon as a non-flash video (avi) played, the flicker went back to making it unusable (well, highly unpleasant at least) for the duration of the movie. Flash video doesn't seem to trigger the flicker, except periodically.

Scott

The last patch I attached here is a kernel patch; it should make things better for you if you've got a KMS enabled configuration. Is there any way for you to try that, Scott?

(In reply to comment #105)
> The last patch I attached here is a kernel patch; it should make things better
> for you if you've got a KMS enabled configuration. Is there any way for you to
> try that, Scott?
>

Tried with the kernel source from the Arch repos and got:

patching file drivers/gpu/drm/i915/i915_reg.h
Hunk #1 FAILED at 1618.
1 out of 1 hunk FAILED -- saving rejects to file drivers/gpu/drm/i915/i915_reg.h.rej
patching file drivers/gpu/drm/i915/intel_display.c
Hunk #1 FAILED at 1623.
Hunk #2 FAILED at 1822.
Hunk #3 FAILED at 1869.
Hunk #4 FAILED at 2022.
4 out of 4 hunks FAILED -- saving rejects to file drivers/gpu/drm/i915/intel_display.c.rej

I did make sure this patch was applied before the standard arch patches. Can you send the link for the other kernel source you had me use last time?

Thanks!
Scott

Fix has been pushed to drm-intel-next, that's probably the easiest way to get it now:

author Jesse Barnes <email address hidden>
commit dff33cfcefa31c30b72c57f44586754ea9e8f3e2

drm/i915: FIFO watermark calculation fixes

Ok, got and compiled the kernel from git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git.

uname -a = 2.6.31-rc2-drm-intel-26127-gdff33cf #1 SMP PREEMPT Thu Jul 16 20:23:01 PDT 2009 i686 Intel(R) Pentium(R) 4 CPU 1.80GHz GenuineIntel GNU/Linux

xf86-video-intel-newest 2.7.99.902-1 : X.org Intel i810\/i830\/i915\/945G\/G965+ video drivers (2.8.0 RC2).

Enabled KMS. Same flicker behavior following suspend to RAM, possibly even worse than with the stock kernel and no KMS. Darn it, I was hoping we had this solved!

Well, let me know what other information you need from me. I can't remember where to find the source for the intel_reg_dump program you had me use several months ago, if you need that.

Thanks!
Scott

The bug that keeps on giving. Please check this one out; Eric found the same thing for his high res configs:

http://lists.freedesktop.org/archives/intel-gfx/2009-July/003471.html

Jesse, no change with that patch. Still horrible flickering of the whole screen after resuming from suspend to RAM.

What's next? :)

Scott

Can you attach your kernel log after you've loaded drm with debug=1? (Note, I'm assuming you're using KMS here.)

Boot was at 09:18, I suspended and resumed a few minutes later. Debug sure fills up the log quick! Sorry its so big....it was too big to post here so here's the link. Booted with drm.debug=1 and i915.modeset=1. Definitely have KMS working, because the switching between virtual terminals is so fast. Cool!

http://scottandchrystie.homeip.net/kernel.log.gz

Scott

Ah thanks, that helps a lot. What chipset do you have? I should be able to give you a fix pretty quickly...

Jesse: Graphics device from lspci --

00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface (rev 01)
00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)

Scott

Hm, I was hoping it was something simple like I'd just read the 845 docs incorrectly, but afaict things are actually correct for that case. But the plane A FIFO allocation does look supiciously high; this patch assumes 845G actually measures FIFO entries in DSPARB as 16 byte values rather than 64, so it might help. I'll have to check some more docs before I know for sure though.

--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1844,6 +1844,9 @@ static int intel_get_fifo_size(struct drm_device *dev, int
                        size = ((dsparb >> DSPARB_BEND_SHIFT) & 0x1ff) -
                                (dsparb & 0x1ff);
                size >>= 1; /* Convert to cachelines */
+ } else if (IS_845G(dev)){
+ size = dsparb & 0x7f;
+ size >>= 2; /* Convert to cachelines */
        } else {
                size = dsparb & 0x7f;
                size >>= 1; /* Convert to cachelines */

That didn't work, Jesse. I just get a black screen when it switches to the framebuffer on boot. The machine is still functioning because I can ssh in, but no display.

Let me know if you need the logs for this.

Scott

Ah I was looking at the wrong code path. In the 830/845 case I think I might be clobbering some important bits, this should preserve them and hopefully set the right values.

--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1943,14 +1943,16 @@ static void i830_update_wm(struct drm_device *dev, int planea_clock,
       int pixel_size)
 {
  struct drm_i915_private *dev_priv = dev->dev_private;
- uint32_t fwater_lo = I915_READ(FW_BLC) & MM_FIFO_WATERMARK;
+ uint32_t fwater_lo = I915_READ(FW_BLC) & ~0xfff;
  int planea_wm;

  i830_wm_info.fifo_size = intel_get_fifo_size(dev, 0);

  planea_wm = intel_calculate_wm(planea_clock, &i830_wm_info,
            pixel_size, latency_ns);
- fwater_lo = fwater_lo | planea_wm;
+ fwater_lo |= (3<<8) | planea_wm;
+
+ DRM_DEBUG("Setting FIFO watermarks - A: %d\n", planea_wm);

  I915_WRITE(FW_BLC, fwater_lo);
 }

Jesse, I think this is an improvement. Still get occasional flickers with normal browsing and window movements following suspend. DVD and other movie playback still triggers strong flickering, although it seems somewhat better than the last patch. Flash doesn't seem to trigger the flicker, even running full screen. Here's the link for the kernel log (drm.debug=1).

http://scottandchrystie.homeip.net/kernel.log.gz

Just so you know, the last two patches you posted have been "malformed patches" right around line 4. I've had to manually patch to get it working :) Not sure if its a cut and paste artifact, but the other ones you posted worked fine as a patch file.

Thanks!
Scott

OK, so we're slowly improving. :) What if you apply both patches? I still can't find docs for the 845G FIFO and cache line sizes, so that could still be an issue.

Awesome! That did it!! Not a flicker to be seen so far! Nice work :) Let me know if you need anything else and when the patches actually make it into the kernel.

Thanks very much!

Scott