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: 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/
Powered by blists - more mailing lists