Bug 37526 - [i915gm] screen repeatedly (hotplug polling) goes black for a fraction of a second
Summary: [i915gm] screen repeatedly (hotplug polling) goes black for a fraction of a s...
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Daniel Vetter
QA Contact:
Keywords: regression
Depends on:
Reported: 2011-05-23 19:50 UTC by Bryce Harrington
Modified: 2016-11-03 12:24 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:

BootDmesg.txt (41.80 KB, text/plain)
2011-05-23 19:52 UTC, Bryce Harrington
no flags Details
CurrentDmesg.txt (701 bytes, text/plain)
2011-05-23 19:52 UTC, Bryce Harrington
no flags Details
XorgLog.txt (41.06 KB, text/plain)
2011-05-23 19:55 UTC, Bryce Harrington
no flags Details
dmesg.txt (123.41 KB, text/plain)
2012-02-03 17:17 UTC, Bryce Harrington
no flags Details

Description Bryce Harrington 2011-05-23 19:50:54 UTC
Forwarding this bug from Ubuntu reporter Cobalt:

Very brief periodic screen blanking every couple seconds.  Regression began in 10.10 and continues in 11.04.  Reporter has been testing upstream git snapshots and finds problem still persists.

[Original Description]
Since I upgraded from Ubuntu 10.04 to 10.10, the monitor displays correctly for a couple of seconds, then turns black for a fraction of a second and then repeats the on and off sequence, making the computer nearly unusable.

The whole sequence is periodic, not random.

Another bug reported earlier (#606987) persists in this release as well, perhaps with the exception that restarting the computer (as opposed to turning it on after a shutdown) gives a normal logon screen. (I only used Restart a couple of times since the upgrade.)

With a live CD for natty, the display is fine up to the screen where I am shown the menu that includes using Ubuntu without installing. Once I choose this option the display changes and the name ubuntu appears, underscored by five dots whose color changes from white to red and back to show that the computer is doing work. It is there that the screen starts to blink.

I have only one monitor, although at some level - at least for maverick and older versions - the computer seems to think that I have two. This is probably at least part of the cause of the other bug (#606987) I mentioned in the original description of this problem.

Thanks and regards

DistUpgraded: Fresh install
 Subsystem: ASUSTeK Computer Inc. Device [1043:82d9]
   Subsystem: ASUSTeK Computer Inc. Device [1043:82d9]
MachineType: ASUSTeK Computer INC. NOVALITE PX20
version.compiz: compiz 1:
version.libdrm2: libdrm2 2.4.23-1ubuntu3
version.libgl1-mesa-glx: libgl1-mesa-glx 7.10-1ubuntu1
version.xserver-xorg: xserver-xorg 1:7.6~3ubuntu4
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.13.2+git20110124.fadee040-0ubuntu4
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.14.0-1ubuntu7
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20110107+b795ca6e-0ubuntu4
Architecture: i386
DistroRelease: Ubuntu 11.04
LiveMediaBuild: Ubuntu 11.04 "Natty Narwhal" - Beta i386 (20110405)
Package: xserver-xorg-video-intel 2:2.14.0-4ubuntu6
PackageArchitecture: i386
Uname: Linux 2.6.38-7-generic i686

Nux: lspci: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2592] (r
Comment 1 Bryce Harrington 2011-05-23 19:52:25 UTC
Created attachment 47083 [details]
Comment 2 Bryce Harrington 2011-05-23 19:52:54 UTC
Created attachment 47084 [details]
Comment 3 Bryce Harrington 2011-05-23 19:55:29 UTC
Created attachment 47085 [details]
Comment 4 Chris Wilson 2011-05-25 08:20:11 UTC
There are too many possible factors; from output polling to fbc and fifos. Can we identify when the regression was introduced?
Comment 5 Chris Wilson 2011-06-16 03:35:39 UTC
The workaround will be echo 0 > /sys/module/drm_kms_helper/parameters/poll. But that won't tell us why the periodic polling is causing the output to blank... Load detection on the VGA should be possible with the current mode settings, and the VGA crtc should not be stolen for any other load detections (TV).
Comment 6 Chris Wilson 2011-07-18 08:06:07 UTC
The workaround would be to disable polling (drm_kms_helper.poll=0). Improving the locking around modesetting is a longer term issue, but I think the fundamental issue is more likely to a FIFO starvation when doing load-detection on the second pipe. Which falls into the DSPARB terroritory. A full drm.debug=0xe dmesg  for boot-up + blanking period would help.

(Reducing priority, not going to be fixed in the immediate term.)
Comment 7 Bryce Harrington 2012-02-03 17:17:05 UTC
Created attachment 56587 [details]
Comment 8 Bryce Harrington 2012-02-22 15:04:22 UTC
drm_kms_helper.poll=0 did indeed prove to help the user.
We're still waiting on the dmesg data from him.
Comment 9 Jesse Barnes 2012-04-16 14:43:07 UTC
Some of the recent i2c improvements may have helped too, worth verifying.
Comment 10 Daniel Vetter 2012-04-16 14:44:42 UTC
To be slightly more precise, please test the drm-intel-next-queued branch from my git repository at http://cgit.freedesktop.org/~danvet/drm/
Comment 11 Daniel Vetter 2012-06-27 03:52:19 UTC
Upstream reporter seems to have gone awol, closing because if missing data. Please reopen only when the request dmesg is available (and preferably the bisect result).
Comment 12 Jari Tahvanainen 2016-11-03 12:24:33 UTC
Closing resolved+invalid. No activity on >4 years.

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.