| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 24 Jan 2011 19:13:25 +0000 From: Chris Wilson <chris@...is-wilson.co.uk> To: Knut Petersen <Knut_Petersen@...nline.de>, linux-kernel@...r.kernel.org Cc: jesse.barnes@...el.com Subject: Re: [BUG/REGRESSION] DRM / i915 / 2.6.37 and 2.6.38-rc*: DVI output gets disabled/reenabled under load On Mon, 24 Jan 2011 19:48:55 +0100, Knut Petersen <Knut_Petersen@...nline.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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists