linux-kernel - Re: radeon blink during probe regression (was Re: Linux 2.6.35-rc2)

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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <AANLkTin0xcY9qZ4OdINKdUzo3zPfG9tNxQ3UZtLSDpzi@mail.gmail.com>
Date:	Tue, 8 Jun 2010 06:22:30 +0200
From:	Torsten Kaiser <just.for.lkml@...glemail.com>
To:	Dave Airlie <airlied@...il.com>
Cc:	Alex Deucher <alexdeucher@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: radeon blink during probe regression (was Re: Linux 2.6.35-rc2)

On Tue, Jun 8, 2010 at 5:09 AM, Dave Airlie <airlied@...il.com> wrote:
> On Tue, Jun 8, 2010 at 11:50 AM, Alex Deucher <alexdeucher@...il.com> wrote:
>> On Mon, Jun 7, 2010 at 8:49 PM, Dave Airlie <airlied@...il.com> wrote:
>>> (changing subject
>>>
>>> On Tue, Jun 8, 2010 at 3:28 AM, Torsten Kaiser
>>> <just.for.lkml@...glemail.com> wrote:
>>>> On Mon, Jun 7, 2010 at 8:52 AM, Dave Airlie <airlied@...il.com> wrote:
>>>>> On Mon, Jun 7, 2010 at 4:32 PM, Alex Deucher <alexdeucher@...il.com> wrote:
>>>>>> On Mon, Jun 7, 2010 at 2:22 AM, Dave Airlie <airlied@...il.com> wrote:
>>>>>>> On Mon, Jun 7, 2010 at 4:09 PM, Torsten Kaiser
>>>>>>> <just.for.lkml@...glemail.com> wrote:
>>>>>>>> The switchoff intervall is ~10 seconds, not 1..2 as I guessed in the first mail.
>>>>>>>> Any idea if there is something in the KMS code that triggers at this intervall?
>>>>>>>
>>>>>>> The new mode probing code happens every 10 seconds, though we
>>>>>>> shouldn't be turning anything on or off with it.
>>>>>>>
>>>>>>> So I suspect the DAC detection table might be doing bad things on your
>>>>>>> hardware, we have had a problem where the dac detect table on one DAC
>>>>>>> would turn the other one off which clearly wasn't what we wanted to
>>>>>>> see.
>>>>>>> ,
>>>>>>
>>>>>> The x300 is a non-atom card, so it uses the legacy load detection
>>>>>> routines which do mess with some of the crtc regs.
>>>>>>
>>>>>
>>>>> Okay I see it now, I'm amazed that I was seeing this issue last week
>>>>> and blaming it on something complete different and only seeing it on
>>>>> one card.
>>>>>
>>>>> I expect its the same problem I'll try and track down a proper fix for
>>>>> it tomorrow.
>>>>
>>>> It really seems to be this polling code.
>>>> After the fix to drivers/char/vt.c the 2.6.35-rc2 kernel now works for
>>>> me without crashing.
>>>>
>>>> I also changed #define DRM_OUTPUT_POLL_PERIOD (10*HZ) to
>>>> #define DRM_OUTPUT_POLL_PERIOD (3*HZ) and now the flickering before X
>>>> starts is at a three second interval. That should prove, that the
>>>> polling from drm_crtc_helper.c is the cause.
>>>>
>>>> After X starts the LCD is stable, but the secondary CRT still flickers
>>>> every 3 seconds.
>>>>
>>>> My hardware is an X300-PCIe card with a VGA-, a DVI-I- and a video output.
>>>> I have a 1280x1024 LCD attached to the DVI-I and an old CRT to the
>>>> VGA. The video output is unused.
>>>> The CRT is normally switched off, but its still detected correctly.
>>>>
>>>> The kernel output from 2.6.34 and 2.6.35-rc2 is here:
>>>> http://lkml.org/lkml/2010/6/6/126
>>>>
>>>> xrandr says:
>>>> Screen 0: minimum 320 x 200, current 2080 x 1024, maximum 4096 x 4096
>>>> DVI-0 connected 1280x1024+0+0 (normal left inverted right x axis y
>>>> axis) 338mm x 270mm
>>>>   1280x1024      60.0*+   75.0
>>>>   1280x960       60.0
>>>>   1152x864       75.0
>>>>   1024x768       75.1     70.1     60.0
>>>>   832x624        74.6
>>>>   800x600        72.2     75.0     60.3     56.2
>>>>   640x480        72.8     75.0     66.7     60.0
>>>>   720x400        70.1
>>>>   640x400        70.0
>>>> VGA-0 connected 800x600+1280+150 (normal left inverted right x axis y
>>>> axis) 280mm x 210mm
>>>>   800x600        72.2*+   75.0     60.3     56.2
>>>>   1280x1024      60.0
>>>>   1024x768       75.1     70.1     60.0
>>>>   640x480        72.8     75.0     60.0
>>>>   720x400        87.8     70.1
>>>> S-video disconnected (normal left inverted right x axis y axis)
>>>>
>>>> If you have something for me to try, just send it. :-)
>>>>
>>>> Torsten
>>>>
>>>
>>> Okay here is a patch that seems to work on my test system, but I want
>>> to give it a bit more playing around with before I sent it onwards.
>>>
>>> Alex, seem sane to you?
>>
>> Seems sane.
>>
>
> While discussing this with Alex we realised this code should never
> have been reached so it showed a bug higher up.
>
> Looks like we were defining i2c lines for tv-out which doesn't have
> any, the attached patch makes sure the tv-out on legacy radeon hw
> doesn't get an i2c line attach so doesn't trigger the polling on it.
>
> Torsten can you test this patch instead of the previous one, though I
> think I'll send both to Linus for safety sakes.

I just applied it and the card now works fine. No more flickering.

Thanks!

Do you want me to test the other patch
(0001-drm-radeon-don-t-poll-tv-dac-if-crtc2-is-in-use.patch) too?

Torsten
--
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/