Bug 21542 - [BISECTED]Radeon: No 50Hz (PAL) modes available after upgrading to 2.6.36
Summary: [BISECTED]Radeon: No 50Hz (PAL) modes available after upgrading to 2.6.36
Status: RESOLVED OBSOLETE
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-31 15:04 UTC by Ville Aakko
Modified: 2013-12-10 22:27 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.36
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
Kernel 2.6.35-r10 dmesg, the last known good (38.90 KB, text/plain)
2010-10-31 20:37 UTC, Ville Aakko
Details
Kernel 2.6.36 dmesg, where the 50Hz are not available... (38.62 KB, text/plain)
2010-10-31 20:38 UTC, Ville Aakko
Details
Xorg log while running 2.6.35, and 50Hz modes are working (33.90 KB, text/plain)
2010-10-31 20:39 UTC, Ville Aakko
Details
Xorg log while running 2.6.36, no 50Hz modes not available (34.54 KB, text/plain)
2010-10-31 20:39 UTC, Ville Aakko
Details

Description Ville Aakko 2010-10-31 15:04:12 UTC
Hi!

I live in Europe/Finland and have an HTPC setup using Radeon IGP (Gigabyte GA-MA78GM-S2H; i.e. R600 based or actually RS780 or somesuch... the Radeon naming scheme is confusing to me). With Kernel 2.6.35 everything is fine. But after upgrading to 2.6.36, all the 50Hz modes are NTSC-entrically gone! I can't set to 50Hz via 'xrandr -r 50' anymore, and also xrandr only lists 60Hz modes. Does anyone know how can those modes be brought back? Or perhaps fix it at some point =)

I'm on Gentoo and will happily provide more information if needed.
Comment 1 Alex Deucher 2010-10-31 17:27:30 UTC
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.
Comment 2 Ville Aakko 2010-10-31 20:35:24 UTC
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
Comment 3 Ville Aakko 2010-10-31 20:37:12 UTC
Created attachment 35612 [details]
Kernel 2.6.35-r10 dmesg, the last known good
Comment 4 Ville Aakko 2010-10-31 20:38:03 UTC
Created attachment 35622 [details]
Kernel 2.6.36 dmesg, where the 50Hz are not available...
Comment 5 Ville Aakko 2010-10-31 20:39:03 UTC
Created attachment 35632 [details]
Xorg log while running 2.6.35, and 50Hz modes are working
Comment 6 Ville Aakko 2010-10-31 20:39:38 UTC
Created attachment 35642 [details]
Xorg log while running 2.6.36, no 50Hz modes not available
Comment 7 Ville Aakko 2010-10-31 20:44:17 UTC
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).
Comment 8 Alex Deucher 2010-10-31 21:20:28 UTC
Might be a duplicate of this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=31154
Comment 9 Ville Aakko 2010-11-01 17:26:06 UTC
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).
Comment 10 Ville Aakko 2011-02-06 14:08:14 UTC
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
Comment 11 curious@bwv190.internetdsl.tpnet.pl 2011-02-07 00:21:45 UTC
> 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).

Note You need to log in before you can comment on or make changes to this bug.