Linux 2.6.35-rc2
in [Kernel]
|
From: Alex Deucher on 7 Jun 2010 02:00 On Sun, Jun 6, 2010 at 11:04 AM, Torsten Kaiser <just.for.lkml(a)googlemail.com> wrote: > [CC:Jeff+Tejun not removed, because you might want to look at the > attached dmesgs] > > On Sun, Jun 6, 2010 at 4:19 PM, Linus Torvalds > <torvalds(a)linux-foundation.org> wrote: >> On Sun, 6 Jun 2010, Torsten Kaiser wrote: >>> >>> The first problem that shows up is, that after the KMS switches to the >>> correct video mode (1280x1024 for an DVI attached LCD), the display >>> begins to flicker. Every 1..2 seconds (guesstimated) the display turns >>> off and on again. Something in the new powersaving? >> >> Or maybe a borderline display timing that the display has trouble syncing >> up with? > > With 2.6.34 and any previous KMS kernels the output was always stable. > (I think, I switch to the radeon KMS on 2.6.32) > The onscreen menu of the monitor showed 1280x1024(a)60.2Hz for > 2.6.35-rc2, if I recall correctly. > Now back on 2.6.34 its 1280x1024(a)59.9Hz. The pm code shouldn't have any affect as your system only has one power state, so it never kicks in. It sounds like a display pll problem, but there haven't been any changes to that code since 2.6.34. Any chance you could bisect it? > > Comparing the DRM output from 2.6.34 and 2.6.35-rc2 I see the > following differences: > On 2.6.35-rc2 this block is missing: > [ � �1.907716] [drm] GPU reset succeed (RBBM_STATUS=0x00000140) > [ � �1.913403] [drm] 1 Power State(s) > [ � �1.916810] [drm] State 0 Default (default) > [ � �1.921017] [drm] � �16 PCIE Lanes > [ � �1.924255] [drm] � �1 Clock Mode(s) > [ � �1.927662] [drm] � � � � � �0 engine/memory: 325000/200000 > [ � �1.932496] [drm] radeon: power management initialized > New on 2.6.35: [ � �1.951340] [TTM] Initializing pool allocator. > Only on 2.6.34: [ � �2.011963] [drm] radeon: cp idle (0x10000C03) > Only on 2.6.34: [ � �2.020478] platform radeon_cp.0: firmware: using > built-in firmware radeon/R300_cp.bin > > On 2.6.34 the output for connector 1 is: > [ � �2.090935] [drm] Connector 1: > [ � �2.094002] [drm] � DVI-I > [ � �2.096629] [drm] � HPD1 > [ � �2.099174] [drm] � DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64 > [ � �2.105210] [drm] � Encoders: > [ � �2.108189] [drm] � � CRT2: INTERNAL_DAC2 > [ � �2.112222] [drm] � � DFP1: INTERNAL_TMDS1 > With 2.6.35-rc2 the line 'HPD1' switches to 'NONE' > Whoops. that's a typo in the print out. I'll send Dave a patch to fix that. Alex > Everything else is identical. I have attached complete dmesg from both > kernels to this mail. > > Torsten > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Torsten Kaiser on 7 Jun 2010 02:20 On Mon, Jun 7, 2010 at 7:58 AM, Alex Deucher <alexdeucher(a)gmail.com> wrote: > On Sun, Jun 6, 2010 at 11:04 AM, Torsten Kaiser > <just.for.lkml(a)googlemail.com> wrote: >> [CC:Jeff+Tejun not removed, because you might want to look at the >> attached dmesgs] >> >> On Sun, Jun 6, 2010 at 4:19 PM, Linus Torvalds >> <torvalds(a)linux-foundation.org> wrote: >>> On Sun, 6 Jun 2010, Torsten Kaiser wrote: >>>> >>>> The first problem that shows up is, that after the KMS switches to the >>>> correct video mode (1280x1024 for an DVI attached LCD), the display >>>> begins to flicker. Every 1..2 seconds (guesstimated) the display turns >>>> off and on again. Something in the new powersaving? >>> >>> Or maybe a borderline display timing that the display has trouble syncing >>> up with? >> >> With 2.6.34 and any previous KMS kernels the output was always stable. >> (I think, I switch to the radeon KMS on 2.6.32) >> The onscreen menu of the monitor showed 1280x1024(a)60.2Hz for >> 2.6.35-rc2, if I recall correctly. >> Now back on 2.6.34 its 1280x1024(a)59.9Hz. > > The pm code shouldn't have any affect as your system only has one > power state, so it never kicks in. �It sounds like a display pll > problem, but there haven't been any changes to that code since 2.6.34. > �Any chance you could bisect it? Not really. -rc1 did not boot for me (although if I disable v4l that might work), and there is this memory corruption error. Regarding the PLLs, did you see this mail? It contains the drm.debug=15 output from 2.6.34 and 2.6.35-rc2. http://lkml.org/lkml/2010/6/6/126 The debug output from radeon_set_pll looks identical. But in 2.6.35 a call to [drm:radeon_legacy_tmds_int_dpms], seems new. 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? Torsten -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dave Airlie on 7 Jun 2010 02:30 On Mon, Jun 7, 2010 at 4:09 PM, Torsten Kaiser <just.for.lkml(a)googlemail.com> wrote: > On Mon, Jun 7, 2010 at 7:58 AM, Alex Deucher <alexdeucher(a)gmail.com> wrote: >> On Sun, Jun 6, 2010 at 11:04 AM, Torsten Kaiser >> <just.for.lkml(a)googlemail.com> wrote: >>> [CC:Jeff+Tejun not removed, because you might want to look at the >>> attached dmesgs] >>> >>> On Sun, Jun 6, 2010 at 4:19 PM, Linus Torvalds >>> <torvalds(a)linux-foundation.org> wrote: >>>> On Sun, 6 Jun 2010, Torsten Kaiser wrote: >>>>> >>>>> The first problem that shows up is, that after the KMS switches to the >>>>> correct video mode (1280x1024 for an DVI attached LCD), the display >>>>> begins to flicker. Every 1..2 seconds (guesstimated) the display turns >>>>> off and on again. Something in the new powersaving? >>>> >>>> Or maybe a borderline display timing that the display has trouble syncing >>>> up with? >>> >>> With 2.6.34 and any previous KMS kernels the output was always stable. >>> (I think, I switch to the radeon KMS on 2.6.32) >>> The onscreen menu of the monitor showed 1280x1024(a)60.2Hz for >>> 2.6.35-rc2, if I recall correctly. >>> Now back on 2.6.34 its 1280x1024(a)59.9Hz. >> >> The pm code shouldn't have any affect as your system only has one >> power state, so it never kicks in. �It sounds like a display pll >> problem, but there haven't been any changes to that code since 2.6.34. >> �Any chance you could bisect it? > > Not really. -rc1 did not boot for me (although if I disable v4l that > might work), and there is this memory corruption error. > > Regarding the PLLs, did you see this mail? It contains the > drm.debug=15 output from 2.6.34 and 2.6.35-rc2. > http://lkml.org/lkml/2010/6/6/126 > > The debug output from radeon_set_pll looks identical. But in 2.6.35 a > call to [drm:radeon_legacy_tmds_int_dpms], seems new. > > 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. , can you file a bug at kernel.org? full dmesg (need all the radeon bits where it finds the card). Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alex Deucher on 7 Jun 2010 02:30 On Mon, Jun 7, 2010 at 2:09 AM, Torsten Kaiser <just.for.lkml(a)googlemail.com> wrote: > On Mon, Jun 7, 2010 at 7:58 AM, Alex Deucher <alexdeucher(a)gmail.com> wrote: >> On Sun, Jun 6, 2010 at 11:04 AM, Torsten Kaiser >> <just.for.lkml(a)googlemail.com> wrote: >>> [CC:Jeff+Tejun not removed, because you might want to look at the >>> attached dmesgs] >>> >>> On Sun, Jun 6, 2010 at 4:19 PM, Linus Torvalds >>> <torvalds(a)linux-foundation.org> wrote: >>>> On Sun, 6 Jun 2010, Torsten Kaiser wrote: >>>>> >>>>> The first problem that shows up is, that after the KMS switches to the >>>>> correct video mode (1280x1024 for an DVI attached LCD), the display >>>>> begins to flicker. Every 1..2 seconds (guesstimated) the display turns >>>>> off and on again. Something in the new powersaving? >>>> >>>> Or maybe a borderline display timing that the display has trouble syncing >>>> up with? >>> >>> With 2.6.34 and any previous KMS kernels the output was always stable. >>> (I think, I switch to the radeon KMS on 2.6.32) >>> The onscreen menu of the monitor showed 1280x1024(a)60.2Hz for >>> 2.6.35-rc2, if I recall correctly. >>> Now back on 2.6.34 its 1280x1024(a)59.9Hz. >> >> The pm code shouldn't have any affect as your system only has one >> power state, so it never kicks in. �It sounds like a display pll >> problem, but there haven't been any changes to that code since 2.6.34. >> �Any chance you could bisect it? > > Not really. -rc1 did not boot for me (although if I disable v4l that > might work), and there is this memory corruption error. > > Regarding the PLLs, did you see this mail? It contains the > drm.debug=15 output from 2.6.34 and 2.6.35-rc2. > http://lkml.org/lkml/2010/6/6/126 > > The debug output from radeon_set_pll looks identical. But in 2.6.35 a > call to [drm:radeon_legacy_tmds_int_dpms], seems new. > > 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? > Sounds like the output polling that gets done when no displays are detected, but that shouldn't kick in if there is something connected. Alex > Torsten > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alex Deucher on 7 Jun 2010 02:40
On Mon, Jun 7, 2010 at 2:22 AM, Dave Airlie <airlied(a)gmail.com> wrote: > On Mon, Jun 7, 2010 at 4:09 PM, Torsten Kaiser > <just.for.lkml(a)googlemail.com> wrote: >> On Mon, Jun 7, 2010 at 7:58 AM, Alex Deucher <alexdeucher(a)gmail.com> wrote: >>> On Sun, Jun 6, 2010 at 11:04 AM, Torsten Kaiser >>> <just.for.lkml(a)googlemail.com> wrote: >>>> [CC:Jeff+Tejun not removed, because you might want to look at the >>>> attached dmesgs] >>>> >>>> On Sun, Jun 6, 2010 at 4:19 PM, Linus Torvalds >>>> <torvalds(a)linux-foundation.org> wrote: >>>>> On Sun, 6 Jun 2010, Torsten Kaiser wrote: >>>>>> >>>>>> The first problem that shows up is, that after the KMS switches to the >>>>>> correct video mode (1280x1024 for an DVI attached LCD), the display >>>>>> begins to flicker. Every 1..2 seconds (guesstimated) the display turns >>>>>> off and on again. Something in the new powersaving? >>>>> >>>>> Or maybe a borderline display timing that the display has trouble syncing >>>>> up with? >>>> >>>> With 2.6.34 and any previous KMS kernels the output was always stable. >>>> (I think, I switch to the radeon KMS on 2.6.32) >>>> The onscreen menu of the monitor showed 1280x1024(a)60.2Hz for >>>> 2.6.35-rc2, if I recall correctly. >>>> Now back on 2.6.34 its 1280x1024(a)59.9Hz. >>> >>> The pm code shouldn't have any affect as your system only has one >>> power state, so it never kicks in. �It sounds like a display pll >>> problem, but there haven't been any changes to that code since 2.6.34. >>> �Any chance you could bisect it? >> >> Not really. -rc1 did not boot for me (although if I disable v4l that >> might work), and there is this memory corruption error. >> >> Regarding the PLLs, did you see this mail? It contains the >> drm.debug=15 output from 2.6.34 and 2.6.35-rc2. >> http://lkml.org/lkml/2010/6/6/126 >> >> The debug output from radeon_set_pll looks identical. But in 2.6.35 a >> call to [drm:radeon_legacy_tmds_int_dpms], seems new. >> >> 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. Alex > can you file a bug at kernel.org? full dmesg (need all the radeon bits > where it finds the card). > > Dave. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |