Regression: monitor fails to sleep/suspend, forced to reboot to correct. 2.6.34-rc6

Regression: monitor fails to sleep/suspend, forced to reboot to correct. 2.6.34-rc6

[Lex Hider]

Hi,

My current setup has worked on previous kernels, I think the problem
has begun with 2.6.32.

If the monitor goes to standby/suspend it shows:

"Out of Range

H.frequency 33 KHz
V.frequency 31 Hz"

I can test this with running: "xset dpms force standby" or "xset dpms
force suspend".

I can no longer switch to console with Ctrl+Alt+F2, etc, and must
reboot to be able to use my system again.

Please advise what additional information/testing I can provide to
make sure this regression gets fixed for 2.6.34.

This bug appears to affect all recent distros as they are 2.6.32 based
(ubuntu lts, debian, rhel6).

I have reported the following bugs with little response. I am unsure
whether I have filed bugs in the correct place or against the correct
component.

http://bugs.freedesktop.org/show_bug.cgi?id=26423
https://bugzilla.redhat.com/show_bug.cgi?id=581898

Please CC me in on any replies.

Thanks,

Lex.

Re: Regression: monitor fails to sleep/suspend, forced to reboot to correct. 2.6.34-rc6

[Justin P. Mattock]

On 05/06/2010 07:30 PM, Lex Hider wrote:
> Hi,
>
> My current setup has worked on previous kernels, I think the problem
> has begun with 2.6.32.
>
> If the monitor goes to standby/suspend it shows:
>
> "Out of Range
>
> H.frequency 33 KHz
> V.frequency 31 Hz"
>
> I can test this with running: "xset dpms force standby" or "xset dpms
> force suspend".
>
> I can no longer switch to console with Ctrl+Alt+F2, etc, and must
> reboot to be able to use my system again.
>
> Please advise what additional information/testing I can provide to
> make sure this regression gets fixed for 2.6.34.
>
> This bug appears to affect all recent distros as they are 2.6.32 based
> (ubuntu lts, debian, rhel6).
>
> I have reported the following bugs with little response. I am unsure
> whether I have filed bugs in the correct place or against the correct
> component.
>
> http://bugs.freedesktop.org/show_bug.cgi?id=26423
> https://bugzilla.redhat.com/show_bug.cgi?id=581898
>
> Please CC me in on any replies.
>
> Thanks,
>
> Lex.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Can you do a bisect?
(2.6.32 - HEAD shouldn't
take too long).

Justin P. Mattock

Re: Regression: monitor fails to sleep/suspend, forced to reboot to correct. 2.6.34-rc6

[Lex Hider]

On 7 May 2010 13:00, Justin P. Mattock <justinmattock@gmail.com> wrote:

    On 05/06/2010 07:30 PM, Lex Hider wrote:

        Hi,

        My current setup has worked on previous kernels, I think the problem
        has begun with 2.6.32.

        If the monitor goes to standby/suspend it shows:

        "Out of Range

        H.frequency 33 KHz
        V.frequency 31 Hz"

        I can test this with running: "xset dpms force standby" or "xset dpms
        force suspend".

        I can no longer switch to console with Ctrl+Alt+F2, etc, and must
        reboot to be able to use my system again.

        Please advise what additional information/testing I can provide to
        make sure this regression gets fixed for 2.6.34.

        This bug appears to affect all recent distros as they are 2.6.32 based
        (ubuntu lts, debian, rhel6).

        I have reported the following bugs with little response. I am unsure
        whether I have filed bugs in the correct place or against the correct
        component.

        http://bugs.freedesktop.org/show_bug.cgi?id=26423
        https://bugzilla.redhat.com/show_bug.cgi?id=581898

        Please CC me in on any replies.

        Thanks,

        Lex.
        --
        To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
        the body of a message to majordomo@vger.kernel.org
        More majordomo info at  http://vger.kernel.org/majordomo-info.html
        Please read the FAQ at  http://www.tux.org/lkml/


    Can you do a bisect?
    (2.6.32 - HEAD shouldn't
    take too long).

    Justin P. Mattock


I'm still a git newbie. What specific command should I run and what
output to post?
You want me to do it against HEAD vs "latest known working version"?

Thanks,

Lex.

Re: Regression: monitor fails to sleep/suspend, forced to reboot to correct. 2.6.34-rc6

[Justin P. Mattock]

>      Can you do a bisect?
>      (2.6.32 - HEAD shouldn't
>      take too long).
>
>      Justin P. Mattock
>
>
> I'm still a git newbie. What specific command should I run and what
> output to post?
> You want me to do it against HEAD vs "latest known working version"?
>
> Thanks,
>
> Lex.
> --
sure.. it's easy(just requires patience).

do a:(in the source tree of kernel)
gist bisect start (enter)
git bisect bad (v2.6.*something, and/or enter for the current)
then
git bisect good v2.6.33
(git bisect will think)
then
make menuconfig
make (compile, reboot etc..)
if it's a good kernel then
(in source tree)
git bisect bad(if the problem is still there git bisect bad).
then
keep going until git gives it's idea of the problem
(then cry and complain to the authors that they fu*ked it up
just messn);

hope this help.

Justin P. Mattock

Re: Regression: monitor fails to sleep/suspend, forced to reboot to correct. 2.6.34-rc6

[Justin P. Mattock]

On 05/07/2010 01:33 AM, Justin P. Mattock wrote:
>
>> Can you do a bisect?
>> (2.6.32 - HEAD shouldn't
>> take too long).
>>
>> Justin P. Mattock
>>
>>
>> I'm still a git newbie. What specific command should I run and what
>> output to post?
>> You want me to do it against HEAD vs "latest known working version"?
>>
>> Thanks,
>>
>> Lex.
>> --
> sure.. it's easy(just requires patience).
>
> do a:(in the source tree of kernel)
> gist bisect start (enter)
> git bisect bad (v2.6.*something, and/or enter for the current)
> then
> git bisect good v2.6.33
> (git bisect will think)
> then
> make menuconfig
> make (compile, reboot etc..)
> if it's a good kernel then
> (in source tree)
> git bisect bad(if the problem is still there git bisect bad).
Oops typo I should of said:
git bisect bad(if the problem is still there, and if it's good
git bisect good (then make(compiling), reboot, then:
> then
> keep going until git gives it's idea of the problem
> (then cry and complain to the authors that they fu*ked it up
> just messn);
>
> hope this help.
>
> Justin P. Mattock

was looking for the wiki for you, but Google
came up with a bunch of crap.
(will look for that in the morning etc..)

Justin P. Mattock