Bug 21542

The mode fetching is part of the core drm.  So it's likely some change there that caused the problem.  Can you bisect?  Also please attach your dmesg output and xorg log.

Sure, I'll do the bisect!

But I won't probably have time to start the bisecting until next weekend, so if someone is reading and is interested in bisecting, go ahead if you have time before I do ;-).

I'll attach the logs, however (the ones for 2.6.35 are good; I noticed that while running 2.6.36 there's no EDID information in Xorg.0.log).

Sorry if the following doesn't belong here, but I'm a bit new to git and bisecting (done so for wine once or twice...) Is there a better way for doing this than:
# git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
# git bisect start
# git bisect bad
# git bisect good v2.6.35

... and then compiling and installing, and rebooting every commit? For example, is it possible to just fetch the DRM part of the tree (or perhaps just the radeon module if I can pinpoint the cause), install the modules from it to the currently running kernel (after testing I can reproduce the but that way)? That would reduce compiling time and reduce reboots.

Also, the last good one I used in gentoo was 2.6.35-r10 which should compare to kernel-2.6.35-11 AFAICT, but I found no easy way to mark that one good in git-bisect to test.

Cheers!
 - Ville

Created attachment 35612 [details]
Kernel 2.6.35-r10 dmesg, the last known good

Created attachment 35622 [details]
Kernel 2.6.36 dmesg, where the 50Hz are not available...

Created attachment 35632 [details]
Xorg log while running 2.6.35, and 50Hz modes are working

Created attachment 35642 [details]
Xorg log while running 2.6.36, no 50Hz modes not available

Hmm., 

I noticed that also in dmesg there's some error about EDID, that is not there in 2.6.35-r10.

Also, I forgot to mention that I'm running installing the kernel via gentoo-sources ebuild, which has a Gentoo patchset... hope it is not the cause and I was not too fast in judging this an upstream issue. If that seems the case (I should be able to install a vanilla kernel quite easily once I find the time) I'll report here (so we can close this bug as invalid, but let's not do that yet since it is fairly easy to find out).

Might be a duplicate of this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=31154

Hi,

I tried the patch from freedesktop bug #31154, but it has no apparent effect here.

Also about the EDID information missing in 2.6.36 Xorg.log I mentioned above - I was wrong it is there (see the logs, they are correct, my comment is not).

Hi!

I finally did the bisect and got this as a result after a lot of rebooting:

"
139315796778a6d5f67c644e2ff470ddc69efb7b is the first bad commit
commit 139315796778a6d5f67c644e2ff470ddc69efb7b
Author: Adam Jackson <ajax@redhat.com>
Date:   Tue Aug 3 14:38:19 2010 -0400

    drm/edid: Rewrite mode parse to use the generic detailed block walk
    
    This brings us in line with the EDID spec recommendation for mode
    priority sorting.  We still don't extract all the modes we could from
    VTB, but VTB is so rare in the wild that I'm not really concerned.
    
    Signed-off-by: Adam Jackson <ajax@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

:040000 040000 45961f1c7578731e21b979ca5aee07f4a365e2a7 64e2fb592862d8a69505c6d65ea57119a7202fcc M      drivers
"

Maybe this should be changed to Video(Other) as this probably applies to all graphic cards?

Do you need the bisect log?

Cheers!
- Ville

> I finally did the bisect and got this as a result after a lot of rebooting:
>
> "
> 139315796778a6d5f67c644e2ff470ddc69efb7b is the first bad commit
> commit 139315796778a6d5f67c644e2ff470ddc69efb7b
> Author: Adam Jackson <ajax@redhat.com>
> Date:   Tue Aug 3 14:38:19 2010 -0400

<...>

> Maybe this should be changed to Video(Other) as this probably applies to all
> graphic cards?
>
> Do you need the bisect log?
>

thanx. some time ago i've also noticed i can't set up 50hz modes
on various hw. while previously i could, so i can confirm it affects
other hw.

50hz modes are esp. usefull on analog LCD screens (slows down pixel
clock, so improves sharpness)  , slow hw (bit less stress on VRAM),
  and when using programs like vice , fuse, or other sw. emulating PAL 
computer with exact refresh rate (i do not know why, but they work much 
slower and stutter - probably because vblank signal is firing too often,
trigering update which could be deferred a bit more).