Bug 827895

Created attachment 588879 [details]
lspci -v output for video controller

just make a new install and have the same on radeon 6670

with nomodeset i can work but it's ugly

(In reply to comment #2)
well in my case it happen cos dual graphic on my gigabyte ga-a75-ud4h now work and automaticaly on(on that board when dual graphic on video output goes only to built-in vga output not that on discrete board)

that cool.

not sure why but vesafb is loading, so I suspect its screwing up the hardware before radeon loads.

normally vesafb only loads if you have vga= lines and I can't see one in the dmesg, so maybe its something to do with grub2.

OK, I'm trying to find a way to disable vesafb on boot. But since this appears to be built-in (not a module) on fedora 17 it's not easy.

Experiment 1: remove "rhgb quiet" from /etc/default/grub: doesn't help; vesafb still activated and flickering occurs.

Experiment 2: try something suggested at
https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen , namely adding a spurious parameter, "vesafb.nonsense=1". Doesn't do anything. (Maybe works if vesafb is a module?)

Experiment 3: add "nomodeset" to /etc/default/grub. This looked promising at first: the video was just fine through the fedora logo sequence and into X,
but... gnome-shell then went nuts, using 100% CPU. (dmesg shows vesafb still activated).

So right now I'm back to suspend/resume as the only way to get a usable system.

(In reply to comment #4)
> not sure why but vesafb is loading, so I suspect its screwing up the
> hardware before radeon loads.
> 
> normally vesafb only loads if you have vga= lines and I can't see one in the
> dmesg, so maybe its something to do with grub2.

This sounds very plausible, but I've now tried the experiment of building a 
custom version of the fc17 3.3.7 kernel without vesafb and sadly it does not fix the problem. I'll attach the current dmesg output.

Created attachment 590047 [details]
dmesg output, vesafb disabled

The problem is unchanged using the new kernel 3.4.0-1.fc17.x86_64 from
today's updates.

The problem is still unchanged after installing kernel-3.4.2-4.fc17.x86_64
from testing (all other packages current with fc17 updates).

Problem still present with self-compiled kernel 3.4.3. I'm switching the
"Component" for this bug to plymouth because on reflection it seems to have
nothing to do with Xorg: the flashing problem starts (at least, as I 
understand it) before X starts. The last thing that looks OK is the message
"Loading initial ramdisk..." (after the grub2 menu). Right after that the 
video flash/flicker starts (and it continues until a suspend/resume).

i suppose that problem in drm/radeon and the way it managed video outputs.

Delete your xorg.conf files if you have any

(In reply to comment #12)
> Delete your xorg.conf files if you have any

I just have these fedora-installed files: in /etc/X11/xorg.conf.d,
00-system-setup-keyboard.conf; and in /usr/share/X11/xorg.conf.d,
10-evdev.conf, 10-quirks.conf, 50-synaptics.conf, 50-vmmouse.conf
and 50-wacom.conf. They don't seem to be video-related. Should I
delete them anyway?

What does say the Xorg log ? Because the dmesg says everything is fine

Created attachment 593081 [details]
Xorg log file

Latest experiment: self-compiled kernel 3.4.3, without vesafb. I now try 
adding "nomodeset" to the kernel "command line" using the "e" option of 
grub2. Result: the initial (boot sequence) video is fine, but as soon as 
I've logged into X, gnome-shell starts ramping up its CPU usage, until it's 
close to 100% on all 4 cores (this is an i7 box). At that point I bail out 
and reboot. Having to suspend/resume to get working video is better than
having no CPU to work with.

Just returned to my FC 17 machine after a month abroad. I'm sad to report that none of the 215 FC updates that awaited me fixed this problem. Suspend/resume is still required to get working video on Radeon HD 6450.

Well, I finally decided I'd had enough of suspend/resume and I switched to the proprietary AMD Catalyst drivers. Problem solved. Except for a curious side-effect, namely that with the AMD video drivers in place, gnome-shell runs
at a background usage of 10-12% CPU, even when the system is idle and I'm just sitting in front of the computer watching gkrellm and top. That in turn is fixed by switching to Xfce.

I just revisited this, and I'm glad to say it's now fixed. I still don't know
which component was responsible but with fedora 17 fully updated as of today, I
was able to remove the Catalyst drivers and get flicker-free video.

kernel-3.5.3-1.fc17.x86_64, modules drm and radeon loaded
xorg radeon module 6.14.99

Oops, this has regressed with the kernel update to
3.6.9-2.fc17.x86_64. So it seems the bug is in fact in
the kernel intel video driver module, not Xorg. 
All was fine with kernel System.map-3.6.8-2.fc17.x86_64.

Just to be explicit: the video is again flashing from
the point where plymouth kicks in on boot, and it
continues flashing once the desktop appears. As before
the flashing can be stopped by doing suspend/resume.

(In reply to comment #20)
> All was fine with kernel System.map-3.6.8-2.fc17.x86_64.

Sorry, paste-o there. I mean it was fine with kernel 3.6.8.

(In reply to comment #20)
> Oops, this has regressed with the kernel update to
> 3.6.9-2.fc17.x86_64. So it seems the bug is in fact in
> the kernel intel video driver module, not Xorg. 

Oh crap, and I meant radeon not intel (my other computer
has intel video ;-)

I am also having problems with an HD6450 where the screen displays starting half way across the display and wraps round, it will only work at all at 1920x1080 resolution and any change to any other resolution results in weird effects like lines or black screen. My HD6450 is fairly new and works perfectly with kernel 3.6.8. I am not using the Catalyst drivers. I have another PC with an HD4350 and this works OK on 3.6.9-2 kernel so I think it may be related to later gfx cards and the driver. Also if I set nomodeset the system boots 3.6.9-2 with a workable display. I suspect that as has been suggested there is a regression somewhere at 3.6.9-2 kernel.

Just tested making set gfxpayload=text instead of the default keep option on grub boot and it comes up fine on 3.6.9-2 kernel.

This is still broken with kernel 3.6.10-2.fc17.x86_64.

Agreed and at least for me changing the gfxpayload option in Grub still allows my system to boot OK

I just installed F17 on a box with a dual headed Radeon HD3600 series board.  System was previously running F12 without problem.  I did a clean install to reformatted disk partitions.

During the boot it also seemed to put the graphics card in a strange state (weird display and lack of boot progress), but eventually Xwin started and appeared to be working correctly.

Then I noticed that both VLC and Flash were very sluggish when playing videos.

I resolved by changing gfxpayload=text and removing "rhgb quiet" from the /boot/grub2/grub.cfg via an update done in /etc/default/grub by adding the line

GRUB_GFXPAYLOAD_LINUX=text

and removing the "rhgb quiet" from GRUB_CMDLINE_LINUX. Removing "rhgb quiet" probably isn't needed, but I like to see the errors.

This looks to me like a grub problem where it hits the graphics card with something it doesn't like, and the card isn't reset by Xorg.

I had the same problem with Fedora 18 and kernel 3.7.4-204.fc18.x86_64 and ati driver xorg-x11-drv-ati-7.0.0-0.8.20121015gitbd9e2c064.fc18.x86_64. 

The solution suggested in comment 27 worked on F18 also.