Bug 178897

Very odd.  Sounds like an off by one error somewhere in the driver.

Please attach your X server log file and config file from the problematic
scenario, as individual uncompressed file attachments, using the link
below.

TIA

Created attachment 123906 [details]
Xorg log file

Created attachment 123907 [details]
Xorg config file

Would it be possible to get you to try a test-install the i386 release to
see if it can be reproduced there as well?  I'm curious if it affects only
x86_64, or if it is also seen on i386, etc.

Definitely sounds like a driver bug though.  

Well, I guess I can try and do that... I'll try ASAP and let you know.
Would it be interesting to try the VGA out too, in order to see if it affects
only the DVI output?

Yeah, if that's not too much trouble, that would be useful info.

Thanks.

So :
- Simply switching to the VGA out instead of the DVI with the computer powered
  off, then turning it on, gets me all the way into GNOME properly and the
  glitch isn't present.
- When using DVI, the glitch is also present on the rhgb screen. This was
  probably unclear in my first comment ("looks fine"), and isn't seen easily
  since the background is mostly solid color, but it can definitely be seen.

I haven't been able to try an i386 reinstall yet, but will do. For now it seems
that it's at least DVI specific, and can easily go away by going to any tty and
re-entering X.

I tried upgrading to today's Rawhide, and now when switching to a tty and back
into X, the entire display freezes, and keyboard input too sometimes. When the
keyboard still works, Ctrl+Atl+Suppr works, and in all cases the power button of
the computer still performs a clean shutdown.

This is definitely a different bug, and unfortunately the vertical bar is still
present.

Glad to hear you're not the only one having the X freezes when switching back to
X from a console problem. I have it too, also with a radeon 92xx on x86_64, see
bug 176759.

Does this problem still occur with FC5test3?

The freeze when going from the console back to X is gone now, but the vertical
bar glitch is still there after a complete Rawhide update yesterday. Still
haven't been able to test an i386 install on that machine, though :-(

Hans : Are you using DVI on your Radeon 92xx?

Can someone attach a screen shot or digital picture of the problem?  Unable
to reproduce locally.

Here's my most overkill bug report attachment so far :
http://ftp.es6.freshrpms.net/tmp/bug178897.avi (12M XviD movie)

The problem is also present during rhgb (although it's too hard to see it on
the video), and you can see in the video that Crtl+Alt+F1 immediately followed
by Alt+F7 gets back to X with the problem gone).

Now I also need to dig to find out why I couldn't make a Theora file with
mencoder nor with transcode ;-)

I've got a new piece of (relevant) information. And I'm getting each time more
confused...

When I boot up the computer with the TV turned off, or with the TV's input set
to something else than DVI, the vertical bar isn't there! (when I later switch
to DVI to check once booting is finished)

When I boot up the computer with the display on the TV, the vertical bar is
always there (rhgb + X) like seen on the video linked above.

I've diff'ed the two X logs, and the only difference is (IIRC) on the PLL
line where a huge value is slightly different. I'll attach that diff as soon
as I can.

(In reply to comment #14)
> I've diff'ed the two X logs, and the only difference is (IIRC) on the PLL
> line where a huge value is slightly different. I'll attach that diff as soon
> as I can.

How soon might that be...  ;)  No pressure, just curious...  ;o)

Oh, sorry, I completely forgot. But there were no significant differences
between both log files at all. Only the line that cocntains the current "Time",
and the max= value of the "PLL parameters", but that also changed between two
consecutive startups with the same connections.

This still happens with FC5 + updates. I suppose you'd now be interested in
knowing if it still does with Rawhide?

FYI, this still happens after updating the system to today's Rawhide. One
interesting thing though is that I now have "hibernate" in the GNOME power
applet and that after resuming from swsusp, even with the TV on, the display is
fine, unlike when doing a full boot.

Current rawhide still exhibits the problem. Note that trying the "vesa" driver
instead of the "radeon" one fixes it, so it seems specific to the "radeon".

I'm still seeing this problem with the current development tree. I've filed the
bug upstream against XOrg here :
https://bugs.freedesktop.org/show_bug.cgi?id=9891

FWIW, I also see this exact same problem during Fedora 7t2's graphical
installation, as well as during RHEL5's. Also once the system is installed. So
on my hardware it's 100% reproducible without any special settings.

Is there anything I could try to provide more useful feedback?

Tracking this upstream.