Bug 25529

Created attachment 31858 [details]
dmesg with drm.debug=0x0c

Created attachment 31859 [details]
Output of intel_reg_dumper

Created attachment 31860 [details]
Xorg.0.log

Created attachment 31861 [details]
xrandr --verbose

Created attachment 31862 [details]
lspci -vvnn

There are some more attachments on the downstream bug report, but I have uploaded the ones that I thought were most relevant. 
- Dmesg with only drm.debug=0x04
- Logs for when the 2001FP is connected
- Various other logs which are probably not relevant for this bug

Created attachment 31984 [details]
dmesg with drm.debug=0x0c for a session without the problem

Created attachment 31985 [details]
intel_reg_dumper for session without the problem

Created attachment 31986 [details]
Xorg.0.log for session without the problem

Created attachment 31987 [details]
xrandr --verbose for a session without the problem

Created attachment 31993 [details]
xrandr --verbose on Optiplex 755 with Ubuntu 8.04

I should add that while the affected computers are new, we have been using the monitors for a couple of years without problems. They have been connected to Optiplex 755 and 745 (with Q35 and Q965 chipsets) running Ubuntu 8.04 and earlier versions. I attach xrandr output from one of the 755s. It seems that the exact same mode is used here as on the problematic systems.

Created attachment 31994 [details]
Xorg.0.log (with ModeDebug) for Optiplex 755 with Ubuntu 8.04

To further indicate that this is a problem with the modesetting, I have received the OSD message: 

Out of Range signal, Cannnot display this video mode, change computer display input to 1600X1200 @60Hz

a couple of times. This last time a logged in via ssh and grabbed some logs. After a little while of inactivity the screen went into power save mode. When I moved the mouse again the picture appeared fine.

Created attachment 31995 [details]
xrandr --verbose when the screen in showing Out of Range

Created attachment 31996 [details]
dmesg with drm.debug=0x0c when the screen is showing Out of Range

Created attachment 31997 [details]
intel_reg_dumper when screen is showing Out of Range

Created attachment 31998 [details]
Xorg.0.log when the screen is showing Out of Range

I am also experiencing this bug with Fedora 12 & 13 x86_64 using an ATi Mobility Radeon HD 3450. The Fedora 13 install uses xorg-x11-drv-ati v.6.13.0. More details here:

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=583110">https://bugzilla.redhat.com/show_bug.cgi?id=583110</a>

Disabling KMS by adding 'nomodeset' at boot makes the flickering go away, at the cost of a huge performance hit.

This bug is really annoying - I'd be happy to help try any fixes.

Thanks
Nathan

The difference between the two sessions is that whilst the OSD complains about invalid mode, the pipe, the output and the PLL are all turned off which is normal behaviour for dpms off. (As is the screen coming back to life on moving the mouse.) Could it just be the monitor losing sync on screen blanking? Does this happen with xset dpms off?

The question then becomes why? Possibly we are not waiting quite long enough for the clocks to stablise before powering down.

(In reply to comment #19)
> The difference between the two sessions is that whilst the OSD complains about
> invalid mode, the pipe, the output and the PLL are all turned off which is
> normal behaviour for dpms off. 

Yes, when diffing the two intel_reg_dumper output for out-of-range with problem-free case I see that. This means that either the out-of-range problem is a separate issue, or I was too late when I captured the output via ssh. I don't remember for sure since this was 7 months ago. Anyway, when the "real" bug (flickering dots) happened, there is no relevant difference from the good case:

$ diff intel_reg_dumper-noproblem.txt intel_reg_dumper-problem.txt 
65c65
< (II):    CURSOR_A_POSITION: 0x01b80165
---
> (II):    CURSOR_A_POSITION: 0x01770178

>  Could it just be the monitor losing sync on screen blanking? Does
> this happen with xset dpms off?

The flickering happens already at boot, so it shouldn't be related to dpms? Since I now live on the other side of the Atlantic (and the computers stayed put), I can't easily test. I realize that this fact makes this a bug report of very limited value. I was hoping that someone would recognise this problem from the video and be able to test a proposed fix.

By boot, do you mean the mode set by BIOS? Or the mode set once the i915 module loads?

Ah, okay the out-of-sync issue is separate then. And the flickering happens with normal use but is intermittent. That is then likely to be connected with FBC or SR and a FIFO underrun. That is also likely to have been fixed with the right watermark values being applied:

commit 0e442c60dd39ac6924b11a20497734bd2303744c
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Mon Oct 19 10:09:33 2009 +0900

    drm/i915: add FIFO watermark support for G4x
    
    Turns out G4x needs to have sensible watermarks set, especially for
    self-refresh enabled modes.  Add support for it.
    
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Tested-by: Dirk Hohndel <hohndel@infradead.org>
    Signed-off-by: Eric Anholt <eric@anholt.net>

(In reply to comment #21)
> By boot, do you mean the mode set by BIOS? Or the mode set once the i915 module
> loads?

I meant to say that it was present on the gdm login screen right after boot, before any timeouts would power down stuff. But yes, I also sometimes saw it earlier, on the splash image during boot and it would also sometimes show up on the VTs. And no, it would not be present on the mode set by BIOS (I would select the kernel through a GRUB menu and I didn't see it there either).

> Ah, okay the out-of-sync issue is separate then. And the flickering happens
> with normal use but is intermittent. That is then likely to be connected with
> FBC or SR and a FIFO underrun. That is also likely to have been fixed with the
> right watermark values being applied:
> 
> commit 0e442c60dd39ac6924b11a20497734bd2303744c
> Author: Jesse Barnes <jbarnes@virtuousgeek.org>
> Date:   Mon Oct 19 10:09:33 2009 +0900
> 
>     drm/i915: add FIFO watermark support for G4x

That particular commit was included in the 2.6.32 kernels, and were therefore included in two of the kernels I used to reproduce the bug (mainline build and ubuntu build 2.6.32-7.10-generic). It may of course have been fixed after that, but we won't be able to verify one way or the other unless I get access to similar hardware again or someone else with that hardware shows up.

I suggest closing this bug (at least for now) since it is probably impossible to get any further without more testing.

I can never tell what has been pulled into distribution kernels -- it's hard enough just tracking the various upstream branches.

I do think this bug has been resolved, as around the same time I was complaining to Jesse about underruns on my gm45 which sound very much like this bug. Sorry that I can't pinpoint the exact fix to confirm.