Bug 827895 - Radeon HD 6450: black screen/flashing on startup
Radeon HD 6450: black screen/flashing on startup
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-06-03 10:31 EDT by Allin Cottrell
Modified: 2013-02-03 23:51 EST (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-09-20 20:30:40 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dmesg output (67.96 KB, text/plain)
2012-06-03 10:31 EDT, Allin Cottrell
no flags Details
lspci -v output for video controller (1.21 KB, text/plain)
2012-06-03 10:33 EDT, Allin Cottrell
no flags Details
dmesg output, vesafb disabled (67.43 KB, text/plain)
2012-06-06 22:30 EDT, Allin Cottrell
no flags Details
Xorg log file (196.92 KB, text/plain)
2012-06-19 17:55 EDT, Allin Cottrell
no flags Details

  None (edit)
Description Allin Cottrell 2012-06-03 10:31:11 EDT
Created attachment 588874 [details]
dmesg output

Description of problem:

After grub menu on boot, I get either a black screen with a tiny
band of noise at the top, or a flickering/flashing screen. This
persists through login and thereafter, though it can be fixed by
doing a suspend + resume. Box is a Dell XPS 8300. Video was fine 
in F16. Update to F17 was via install DVD followed by full online

Version-Release number of selected component (if applicable):


How reproducible:

Start the machine from cold, or reboot.

Steps to Reproduce:
1. Start or reboot
2. Wait for grub2 to do its thing
3. Observe the breakage
Actual results:

As described: broken video output.

Expected results:

Correct video output.

Additional info:

Over several start-ups I saw the "flashing" version of the problem.
I then tried rebuilding the initramfs, using

dracut -f /boot/initramfs-3.3.7-1.fc17.x86_64.img

After that, I have the "black screen" version.
Comment 1 Allin Cottrell 2012-06-03 10:33:43 EDT
Created attachment 588879 [details]
lspci -v output for video controller
Comment 2 Thero Layfer 2012-06-06 10:45:23 EDT
just make a new install and have the same on radeon 6670

with nomodeset i can work but it's ugly
Comment 3 Thero Layfer 2012-06-06 11:18:43 EDT
(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.
Comment 4 Dave Airlie 2012-06-06 14:49:05 EDT
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.
Comment 5 Allin Cottrell 2012-06-06 17:43:06 EDT
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.
Comment 6 Allin Cottrell 2012-06-06 22:28:05 EDT
(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.
Comment 7 Allin Cottrell 2012-06-06 22:30:14 EDT
Created attachment 590047 [details]
dmesg output, vesafb disabled
Comment 8 Allin Cottrell 2012-06-07 19:09:56 EDT
The problem is unchanged using the new kernel 3.4.0-1.fc17.x86_64 from
today's updates.
Comment 9 Allin Cottrell 2012-06-15 08:45:14 EDT
The problem is still unchanged after installing kernel-3.4.2-4.fc17.x86_64
from testing (all other packages current with fc17 updates).
Comment 10 Allin Cottrell 2012-06-18 20:39:43 EDT
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).
Comment 11 Thero Layfer 2012-06-18 21:02:31 EDT
i suppose that problem in drm/radeon and the way it managed video outputs.
Comment 12 Jérôme Glisse 2012-06-19 12:27:47 EDT
Delete your xorg.conf files if you have any
Comment 13 Allin Cottrell 2012-06-19 12:53:10 EDT
(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?
Comment 14 Jérôme Glisse 2012-06-19 14:24:04 EDT
What does say the Xorg log ? Because the dmesg says everything is fine
Comment 15 Allin Cottrell 2012-06-19 17:55:32 EDT
Created attachment 593081 [details]
Xorg log file
Comment 16 Allin Cottrell 2012-06-20 20:26:09 EDT
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.
Comment 17 Allin Cottrell 2012-07-26 14:27:30 EDT
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.
Comment 18 Allin Cottrell 2012-07-29 20:21:34 EDT
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.
Comment 19 Allin Cottrell 2012-09-20 20:30:40 EDT
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
Comment 20 Allin Cottrell 2012-12-08 17:15:31 EST
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.
Comment 21 Allin Cottrell 2012-12-08 17:23:24 EST
(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.
Comment 22 Allin Cottrell 2012-12-08 17:25:38 EST
(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 ;-)
Comment 23 Stuart Rogers 2012-12-12 04:18:23 EST
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.
Comment 24 Stuart Rogers 2012-12-12 06:17:47 EST
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.
Comment 25 Allin Cottrell 2012-12-15 23:38:58 EST
This is still broken with kernel 3.6.10-2.fc17.x86_64.
Comment 26 Stuart Rogers 2012-12-16 04:18:59 EST
Agreed and at least for me changing the gfxpayload option in Grub still allows my system to boot OK
Comment 27 dwgoldfarb 2012-12-24 11:33:21 EST
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


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.
Comment 28 Anil Seth 2013-02-03 23:51:05 EST
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.

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