Linux 2.6.35-rc2
in [Kernel]
|
From: Dave Airlie on 7 Jun 2010 03:00 On Mon, Jun 7, 2010 at 4:32 PM, Alex Deucher <alexdeucher(a)gmail.com> wrote: > 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. > 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. 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: Konrad Rzeszutek Wilk on 7 Jun 2010 12:40 On Sat, Jun 05, 2010 at 09:15:36PM -0700, Linus Torvalds wrote: > > So -rc2 is out there, and hopefully fixes way more problems than it > introduces. > > I'm slightly unhappy with its size - admittedly it's not nearly as big as > rc2 was the last release cycle, but that was an unusually big -rc2. And I > really hoped for a calmer release cycle this time. > > In fact, for once I'm going to enforce -rc3 being sane, because the > upcoming week is the last week of school for my kids. And when the kids > get out of school, I'm going be offline for a while. And as a result, I > _really_ don't want to pull anything even half-way scary in the next week > for -rc3. > > So any pull requests had better be obvious fixes only, and this time I'm > not going to let things slide. Hey Linus, I am wondering what about git pull request that were sent before this email but haven't been addressed yet? Specifically I am concerned about: http://lkml.org/lkml/2010/6/2/301 It has been in the linux-next for months, and has gone through reviews. Is there an outstanding issue that blocks the merge? -- 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: Linus Torvalds on 7 Jun 2010 12:50 On Mon, 7 Jun 2010, Konrad Rzeszutek Wilk wrote: > > I am wondering what about git pull request that were sent before this > email but haven't been addressed yet? Specifically I am concerned > about: http://lkml.org/lkml/2010/6/2/301 It was sent to me after the merge window already closed, and seemed to be about just new features. As a result, I entirely ignored it. Linus -- 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 13:30 On Mon, Jun 7, 2010 at 8:52 AM, Dave Airlie <airlied(a)gmail.com> wrote: > On Mon, Jun 7, 2010 at 4:32 PM, Alex Deucher <alexdeucher(a)gmail.com> wrote: >> 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: >>>> 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 -- 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: Konrad Rzeszutek Wilk on 7 Jun 2010 14:20
On Mon, Jun 07, 2010 at 09:40:33AM -0700, Linus Torvalds wrote: > > > On Mon, 7 Jun 2010, Konrad Rzeszutek Wilk wrote: > > > > I am wondering what about git pull request that were sent before this > > email but haven't been addressed yet? Specifically I am concerned > > about: http://lkml.org/lkml/2010/6/2/301 > > It was sent to me after the merge window already closed, and seemed to > be about just new features. As a result, I entirely ignored it. Ah, <sigh> I seem to have a knack for continously missing the merge windows. Is it fair to state that: 1). Once you send an email saying that Linux 2.6.35 is released, the merge window has opened. 2). Then the the maintainers have two weeks to send you git pull request for new features. 3). After the two weeks, it is rc1, and only bug-fixes are accepted? -- 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/ |