Created attachment 46117 [details]
dmesg_2.6.39-rc4-dirty

Hi,

I've found what I guess is a radeon (or drm/kms) regression post 2.6.35.
I've got my TV conneced to my RS690G over HDMI, and the display has
always been jittery after POST and at the GRUB screen. Pre-KMS, the X
server (or driver) got it sorted, and when KMS started the display
stabilized right after the kernel driver was initiated. However, post
2.6.35, I see the jitter is back.

I've spent the last month trying to bisect it, but pretty much failed.
It appears that versions closer to 2.6.38/39 are more prone to display
jitter, while 2.6.36 or so can have many successful runs. It also
appears to be related to device power-on order, or so I've come to
believe; A stable display can turn jittery, just by power cycling the TV. I'm also fairly successful in stabilizing a jittery display by power cycling the TV.

I've uploaded a video of a 38-rc8 boot:
http://www.easy-share.com/1914220540/2.6.38-rc8_bad_x.mp4
which is mirrored here:
http://www.psw.ro/tmp/radeon/2.6.38-rc8_bad_x.mp4

You'll see jitter at the POST screen and in GRUB. When KMS kicks in it
stabilizes, and when Freevo starts X, it's back to jitter. It's not freevo related at all as a plain 'xinit' to a WM-less xterm causes the same effect.

The jitter is always of the same kind. It looks like an old tv set which
loses sync. The contents on the display is, for a split second, placed
at the wrong part of the screen (vertically and to some extent
horizontally), and every 5-15 seconds or so, there is a big reset when
the TV tries to restart things (I guess). At the resets, thee is a loud
'ping' in the nearby stereo too...

During the bisect  (and at 39-rc4) I've seen this both at the console
(post KMS) and in X, so I'm not sure where the error is. I hope some of
you can get a better idea of where to hunt for the bug by looking at the
video.

Another observation is that, if left jittering for a while (say a few to ten minutes), it usually, but not always, stop occurring.