Regression 2.6.27 -> 2.6.28

[Alex Deucher]

On Fri, Jan 30, 2009 at 8:19 AM, Michel Dänzer <michel at daenzer.net> wrote:
> On Thu, 2009-01-29 at 20:04 +0100, Jörg-Volker Peetz wrote:
>> Michel Dänzer wrote:
>> > On Tue, 2009-01-27 at 21:38 +0100, Jörg-Volker Peetz wrote:
>> >> Michel Dänzer wrote:
>> >>> On Sun, 2009-01-25 at 20:03 +0100, Jörg-Volker Peetz wrote:
>> >>>> with kernel 2.6.28 and 2.6.28.1 while in X with active DPMS screen off ("xset
>> >>>> dpms force off") the CPU does not go into C3 state when idle.
>> >>>> With 2.6.27.10 and 2.6.27.12 the CPU does fall into C3 state when idle as
>> >>>> observed with powertop 1.11.
>> >>> Was the DRI already enabled with the 2.6.27 kernels? If yes, you may
>> >>> need to use git bisect to find the change that introduced the problem.
>> >>>
>> >> DRI was enabled both on 2.6.27 and 2.6.28.
>> >>
>> >> Today I also checked another hardware, a laptop with Pentium M CPU, Intel
>> >> chipset ICH6, and ATI M22 [Mobility Radeon X300]. Similar behavior: while in X
>> >> with active DPMS screen off ("xset dpms force off") there are nearly 60
>> >> wakeups/s instead of 3 wakeups/s with DPMS disabled.
>> >>
>> >> I've not done a git bisect before. It will take me a while.
>> >
>> > FWIW, I think it's most likely related to commit
>> > 0a3e67a4caac273a3bfc4ced3da364830b1ab241 ('drm: Rework vblank-wait
>> > handling to allow interrupt reduction.') and friends. Can you try
>> > reverting that and seeing if the problem still happens?
>> >
>>
>> You were right. I did the "git bisect good 2.6.27 bad 2.6.28" and the outcome is
>>
>>
>> 0a3e67a4caac273a3bfc4ced3da364830b1ab241 is first bad commit
>
> Thanks for taking the time to confirm this!
>
>
> I think this may actually be an X driver issue though; apparently it's
> telling the kernel that the CRTC is disabled, but the CRTC is obviously
> still generating vertical blank interrupts.
>
>> xserver-xorg-video-radeon    1:6.9.0-1+lenny4
>
> Can you try if the problem persists with current xf86-video-ati Git or
> at least the 6.10.0 release? If so, does disabling the
> radeon_crtc_modeset_ioctl() calls in legacy_crtc_dpms() in
> xf86-video-ati/src/legacy_crtc.c avoid the problem?
>
> (Alex, do you know or can you find out under what circumstances exactly
> the CRTC frame counter registers reset to 0?)

Not sure off hand, but I'll find out.

Alex