linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Knut Petersen <Knut_Petersen@t-online.de>, linux-kernel@vger.kernel.org
Cc: jesse.barnes@intel.com
Subject: Re: [BUG/REGRESSION] DRM / i915 / 2.6.37 and 2.6.38-rc*: DVI output gets disabled/reenabled under load
Date: Mon, 24 Jan 2011 19:13:25 +0000	[thread overview]
Message-ID: <0d30dc$krk6f6@orsmga001.jf.intel.com> (raw)
In-Reply-To: <4D3DC997.5040605@t-online.de>

On Mon, 24 Jan 2011 19:48:55 +0100, Knut Petersen <Knut_Petersen@t-online.de> wrote:
> On an AOpen i915GMm-HFS I see the following problem:
> The LCD panel connected to DVI-1 gets disabled and then reenabled
> under high system load (e.g. -j 15 kernel compile) if I am working on the
> framebuffer console (no problems in X).

DVI detection is essentially retrieving the EDID by bitbanging on the DDC.
This is timing sensitive and I suspect that is being interrupted by the
system activity causing the EDID data to be returned corrupted. Is that
supported by any warnings in dmesg? Does increasing the drm.debug level to
0x6 reveal any more significant information?

Not sure how using the unaccelerated fbcon ties in just yet. It's an extra
source of latency vs X, but I would expect to impact upon DVI detection.

You can simply disable the polling with
'echo n > /sys/module/drm_kms_helper/parameter/poll'
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

  reply	other threads:[~2011-01-24 19:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-24 18:48 [BUG/REGRESSION] DRM / i915 / 2.6.37 and 2.6.38-rc*: DVI output gets disabled/reenabled under load Knut Petersen
2011-01-24 19:13 ` Chris Wilson [this message]
2011-01-25 11:50   ` Knut Petersen
2011-01-25 12:11     ` Chris Wilson
2011-01-25 12:35       ` Knut Petersen
2011-01-25 13:50         ` Chris Wilson
2011-01-25 14:14       ` Knut Petersen
2011-01-25 14:44         ` Chris Wilson
2011-01-25 15:06     ` [PATCH] drm/i915/sdvo: If at first we don't succeed in reading the response, wait Chris Wilson
2011-01-25 22:01       ` Knut Petersen
2011-01-25 22:11         ` [PATCH] drm/i915/sdvo: If at first we dont " Chris Wilson
2011-01-25 22:32           ` Knut Petersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='0d30dc$krk6f6@orsmga001.jf.intel.com' \
    --to=chris@chris-wilson.co.uk \
    --cc=Knut_Petersen@t-online.de \
    --cc=jesse.barnes@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).