Bug 37526

Summary:

[i915gm] screen repeatedly (hotplug polling) goes black for a fraction of a second

Product:

DRI

Reporter:

Bryce Harrington <bryce>

Component:

DRM/Intel

Assignee:

Daniel Vetter <daniel>

Status:

CLOSED INVALID

QA Contact:

Severity:

normal

Priority:

medium

CC:

ben, chris, daniel, jbarnes

Version:

unspecified

Keywords:

regression

Hardware:

x86 (IA32)

OS:

Linux (All)

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
BootDmesg.txt	none
CurrentDmesg.txt	none
XorgLog.txt	none
dmesg.txt	none

Description Bryce Harrington 2011-05-23 19:50:54 UTC

Forwarding this bug from Ubuntu reporter Cobalt:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/681054

[Problem]
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
GraphicsCard:
Subsystem: ASUSTeK Computer Inc. Device [1043:82d9]
Subsystem: ASUSTeK Computer Inc. Device [1043:82d9]
MachineType: ASUSTeK Computer INC. NOVALITE PX20
version.compiz: compiz 1:0.9.2.1+glibmainloop4-0ubuntu11
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

[lspci]
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]
BootDmesg.txt

Comment 2 Bryce Harrington 2011-05-23 19:52:54 UTC

Created attachment 47084 [details]
CurrentDmesg.txt

Comment 3 Bryce Harrington 2011-05-23 19:55:29 UTC

Created attachment 47085 [details]
XorgLog.txt

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]
dmesg.txt

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.