Originally reported at: https://bugs.launchpad.net/bugs/493707 (by me) Binary package hint: xserver-xorg-video-intel On two computers of the model Dell Optiplex 760, Ultrasmall Form Factor the monitor shows some flickering kind of corruption when Xorg is started. Present when: - KMS is used, Monitor (Dell 20" 2007FP) connected via DVI-I cable to the DVI-I output of the computer and DVI-D input of the monitor Not present when: - A Dell 2001FP monitor is used instead of a 2007FP (but I have tested two 2007FPs) - Monitor is connected using VGA (DVI-I to VGA adapter on computer, VGA input on monitor) - When booting a Lucid (Ubuntu 10.04) LiveUSB image (which has 2.6.32 kernel) Untested (so far): - Karmic LiveUSB image (with 2.6.31 kernel) I have observed it only once with UMS. Unfortunately I later accidentally deleted the log files for that run, and I haven't been able to reproduce it since. Since the problem seems to be related to KMS I have tried the standard Karmic kernel, the mainline build [1] of 2.6.32 and the current Lucid kernel (2.6.32-7.10-generic) and they all show the problem. Problem description: Most times (i.e. not always) when the computer is booted, some colors will have flickering blue dots at various places. It seems that some of the dots are always present while others flicker on and off. It seems that some colors are more susceptible than others, and that shows up as bands of corruption in gradients (see photo [2] and video [3] of Ubuntu login screen). The exact pattern is a little bit different from boot to boot, sometimes it is worse and sometimes better. On a normal single-color brown desktop there are flickering blue horizontal lines every now and then spanning the whole desktop. Sometimes also the VTs and the usplash screen shows flickering blue dots on the black background. In order to get as much debug information as possible, I'm reporting this bug with `ubuntu-bug` running the Lucid kernel and the DRM KMS debug option drm.debug=0x04. [4] The corruption is only present in the native mode (0x40 1600x1200). If I select any of the other modes available from xrandr, there is no corruption. At least once the corruption has disappeared after switching to another mode and back again. (`xrandr --output HDMI2 --mode 0x41` and then `xandr --output HDMI2 --mode 0x40`). I can't reproduce this now (on 2.6.32-7), so it may be kernel dependent. Also, the corruption does not show up on screenshots (when viewed on another computer or another resolution). As a side note, the DVI connection is reported as HDMI2 even though it is a DVI, but that is probably a separate issue. I was considering not reporting this, since I will only have access to this hardware for about one more week. Selfishly increasing priority for that reason (will lower again when I don't have access to hardware anymore if someone else hasn't done it by then). [1]: http://kernel.ubuntu.com/~kernel-ppa/mainline/ [2]: http://launchpadlibrarian.net/36550308/IMG_2894.JPG [3]: http://launchpadlibrarian.net/36550355/MVI_2895.AVI [4]: http://lists.freedesktop.org/archives/intel-gfx/2009-July/003310.html ProblemType: Bug Architecture: i386 Date: Mon Dec 7 13:14:07 2009 DistroRelease: Ubuntu 9.10 InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5) MachineType: Dell Inc. OptiPlex 760 Package: xserver-xorg-video-intel 2:2.9.0-1ubuntu2 ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-7-generic root=UUID=6ca55718-1b9f-4ebb-b4b1-8175de7a008c ro quiet splash reboot=bios drm.debug=0x04 ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.32-7.10-generic RelatedPackageVersions: xserver-xorg 1:7.4+3ubuntu10 libgl1-mesa-glx 7.6.0-1ubuntu4 libdrm2 2.4.14-1ubuntu1 xserver-xorg-video-intel 2:2.9.0-1ubuntu2 xserver-xorg-video-ati 1:6.12.99+git20090929.7968e1fb-0ubuntu1 SourcePackage: xserver-xorg-video-intel Uname: Linux 2.6.32-7-generic i686 XorgConf: Error: [Errno 2] No such file or directory: '/etc/X11/xorg.conf' XsessionErrors: (gnome-settings-daemon:1777): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed (gnome-settings-daemon:1777): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed (polkit-gnome-authentication-agent-1:1816): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed (nautilus:1808): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed dmi.bios.date: 08/17/2009 dmi.bios.vendor: Dell Inc. dmi.bios.version: A05 dmi.board.name: 0G919G dmi.board.vendor: Dell Inc. dmi.board.version: A01 dmi.chassis.type: 16 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA05:bd08/17/2009:svnDellInc.:pnOptiPlex760:pvr:rvnDellInc.:rn0G919G:rvrA01:cvnDellInc.:ct16:cvr: dmi.product.name: OptiPlex 760 dmi.sys.vendor: Dell Inc. fglrx: Not loaded system: distro: Ubuntu architecture: i686kernel: 2.6.32-7-generic
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.
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.