Message-ID: <4D3EB90C.9020901@t-online.de>
Date:	Tue, 25 Jan 2011 12:50:36 +0100
From:	Knut Petersen <Knut_Petersen@...nline.de>
To:	Chris Wilson <chris@...is-wilson.co.uk>
CC:	jesse.barnes@...el.com, linux-kernel@...r.kernel.org
Subject: Re: [BUG/REGRESSION] DRM / i915 / 2.6.37 and 2.6.38-rc*: DVI output
 gets disabled/reenabled under load

Am 24.01.2011 20:13, schrieb Chris Wilson:
> 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?
>
>   

KERNEL 2.6.36.3
==============
Attached to this msg is LOG 2.6.36.3. Everything looks fine, every 10
seconds
an additional message group is added. No distortions.

KERNEL 2.6.38-rc2
================

LOG-2.6.38-rc2 is different. The kernel is a pure kernel 2.6.38-rc2 with one
exception: I changed  DRM_OUTPUT_POLL_PERIOD  to 3*HZ to increase
error probability.

At log time [  678.598641]  you can see the status change of the VGA-2
connector (there is no physical VGA-2 connector on that mobo).

After that a hotplug event is generated. Ok, that could be reasonable,
but as
you see the other connectors are also affected by that event. I cannot
tell the
exact moment, but during processing that hotplug event there is a period
with
no (or maybe a distorted) signal on the DVI-1 connector.

Both logs where taken on a busy system doing a make -j 15 kernel compile,
debuglevel 15, framebuffer console, no X running.

I admit that I had not the time to study the code and hardware
references in detail,
but a few questions / thoughts come to my mind.

1: I suspect that it is not a timing problem because only VGA-2 (no
physical connector)
is affected. The status of VGA-1 and DVI-1 (with physical connectors) 
seems to
be absolutely stable. Guess: Maybe a hardware problem like missing
termination ?
There are  few systems with 2 real VGA connectors ... there could be
more systems with
that problem if my guess is right.

2: We should not care if connector status changes between "unknown" and
"disconnected". We should only care about status changes from/to "connected"
and generate hotplug events only in that case. That should solve my
problem and
would break nothing. Am I right?

3: It's wrong that a status change on one connector generates a hotplug
event
that affects all connectors ...


I think LOG-2.6.38-rc2 shows a sign of an additional bug
===========================================
[  681.527815] [drm:drm_target_preferred], found mode 1280x1024
[  681.531482] [drm:drm_setup_crtcs], picking CRTCs for 4096x4096 config

Is 4096x4096 really reasonable? I don't think so, at least not for my
hardware.

After connecting a monitor to both the DVI and VGA connectors it can use
xrandr
to set different viewing areas for the monitors. But although X also
reports that
maximum 4096x4096 screen size it is not usable. X will crash as soon as
I try to use a combined x-resolution above 2048. I remember that I read
somewhere
that this is a hardware limit of my hardware. Is X taking the maximum
screen resolution
from the kernel? I think so. So the kernel should not use a screen
config that is beyond
hardware limits.
 
lspci:

00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML
Express Processor to DRAM Controller (rev 04)
00:02.0 VGA compatible controller: Intel Corporation Mobile
915GM/GMS/910GML Express Graphics Controller (rev 04)
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML
Express Graphics Controller (rev 04)
00:1b.0 Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) PCI Express Port 1 (rev 04)
00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) PCI Express Port 2 (rev 04)
00:1c.2 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) PCI Express Port 3 (rev 04)
00:1c.3 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) PCI Express Port 4 (rev 04)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #1 (rev 04)
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #2 (rev 04)
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #3 (rev 04)
00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #4 (rev 04)
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB2 EHCI Controller (rev 04)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d4)
00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface
Bridge (rev 04)
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) IDE Controller (rev 04)
00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA
Controller (rev 04)
00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
SMBus Controller (rev 04)
02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E
Gigabit Ethernet Controller (rev 19)
03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E
Gigabit Ethernet Controller (rev 19)
05:03.0 FireWire (IEEE 1394): Agere Systems FW322/323 (rev 61)

Knut

View attachment "LOG-2.6.36.3" of type "text/plain" (3051 bytes)

View attachment "LOG-2.6.38-rc2" of type "text/plain" (20894 bytes)

Powered by blists - more mailing lists