Red Hat Bugzilla – Bug 169637
X fails to start with recent kernels on bootup
Last modified: 2007-11-30 17:11:14 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7
Description of problem:
For all new kernels released for FC4 after kernel-2.6.12-1.1398_FC4 X freezes on bootup after the main boot sequence just as X starts. At this point the keyboard and mouse are locked, and it is impossible to regain control without re-booting the machine.
Once the system is frozen it is impossible to switch to alternative consoles using ctrl-alt-Fn.
My graphics card is PCI:
00:08.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA])
Subsystem: PC Partner Limited: Unknown device 0020
Flags: bus master, stepping, medium devsel, latency 32, IRQ 10
Memory at d0000000 (32-bit, prefetchable) [size=128M]
I/O ports at e800 [size=256]
Memory at e0020000 (32-bit, non-prefetchable) [size=64K]
[virtual] Expansion ROM at 0f900000 [disabled] [size=128K]
However there is also an onboard graphics which I do not use (and which cannot be removed):
01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i1 (prog-if 00 [VGA])
Subsystem: Trident Microsystems CyberBlade/i1
Flags: 66Mhz, medium devsel, IRQ 10
Memory at dd800000 (32-bit, non-prefetchable) [disabled] [size=8M]
Memory at de000000 (32-bit, non-prefetchable) [disabled] [size=128K]
Memory at dd000000 (32-bit, non-prefetchable) [disabled] [size=8M]
[virtual] Expansion ROM at 0f800000 [disabled] [size=64K]
All of the following kernels are affected:
My system is running an Athlon processor i386 with FC4 running and fully up to date as of 30th September 2005.
At this point I was using the "radeon" driver in xorg.conf
However if I switch to the "vesa" driver in xorg.conf the system successfully boots up with all the affected kernels, though with some odd graphics appearing on the way to the login screen (I am using KDE as the desktop with the KDM login screen)
This would point to an xorg problem rather than a kernel problem.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
2. The sysem begins booting
3. X fails to start and the system hangs
Actual Results: The screen is black and the mouse and keyboard frozen out.
Expected Results: The system should boot and X should start and give the normal login screen.
Please attach (via link below) /var/log/Xorg.0.log, which contains the details
of the failure. You may need remote login to get this. Also, attach working
Xorg.0.log with the old kernel for comparison purposes. Also, your xorg.conf
Created attachment 119500 [details]
This is the current xorg.conf file using the vesa driver (was radeon)
The version which casued the problem with the newer kernels only has "radeon"
replacing "vesa" as the only change
Created attachment 119501 [details]
xorg log with the radeon driver for the kernel which DOES work (1398)
This log corresponds to the last kernel which does give a successful boot with
X running correctly using the radeon driver.
I will have to wait until Monday to revert the computer to the radeon driver
and do a failed boot with on of the more recent kernels. I will send that
attachment on Monday 3rd October.
Created attachment 119507 [details]
xorg log from boot with radeon driver which hangs X with new kernel
This xorg log was obtained when booting using the latest FC4 kernel and the
system freezes just as X starts after the main boot sequence. The log was
obtained by logging in remotely whilst the screen was black, and the mouse and
keyboard locked up.
Run "yum update" to install all of the latest FC4 updates. After it's done,
run "system-config-display --reconfig" then do not edit the xorg.conf at all.
Reboot the system to ensure full hardware reset, and let it come back up into
X after reboot.
Attach the X server config file and log file from after this. Also include
the output of "lsmod".
OK I have done what you suggested - the system was in fact already fully up to
date (nightly) but I have run yum update again today and no further updates came in.
In order to start with a fully up to date system I booted with the "vesa" driver
and with the latest kernel (2.6.13-1.1526_FC4).
Then ran system-config-display --reconfig as you suggested. I then selected "ATI
radeon VE" as the graphics. Then shutdown to power off, and started up from
scratch booting kernel 2.6.13-1.1526_FC4.
The system has now booted normally and X loaded without problems (although with
USA rather than UK keyboard, which I have reset from K->System Settings->
Keyboard) before attaching the requested files which follow.
Created attachment 119538 [details]
xorg.conf after executing your suggestions above
xorg.conf after doing your suggestions today (and after resetting the keyboard
from K->System Settings-> Keyboard
Created attachment 119539 [details]
This is for the system now booted successfully with kernel 2.6.13-1.1526_FC4
and ATI radeon VE driver
Created attachment 119540 [details]
Ouput from lsmod command
lsmod output after the booting as suggested.
Thank you for sorting this out. Others who are running the same graphics card
will certainly want to see this ahead of any fix upstream, and I hope that these
files will provide sufficient diagnostics for a fix to be possible via normal
I am now golden again...
I spoke too soon !
After the above and without any further changes I decided to check that all was
well by re-booting.
I am now back to square 1 - i.e. it fails to load X with the latest kernel but
reverting back to 2.6.12-1.1398 boots and loads X without problems.
There is clearly a residual problem.
It appears that DRI is still being enabled even though it should disable
itself on this card. It's possible the dri-disable patch might not
be working properly. Please manually disable DRI, by commenting out
the following line in your config file:
Then reboot and restart the X server, and attach the new config and
log file. ALso attach /var/log/messages from both with and without
DRI, and indicate which is which.
I had a problem yesterday trying to recover from one of the failed re-boots
which resulted in a file system journal error, and this then excalated into a
problem being unable to boot at all. To cut a long story short it was necessary
to do a complete re-install of FC4 ! However this has lost me a day of work,
but I am now back in action with a fresh install, and fully up to date.
After all the yum updates were in, I changed xorg.conf to comment out the
loading of DRI, and switched the graphics driver to radeon, then booted to the
The boot process was fine and X started just fine. The system seems to be
running flawlessly now. So this certainly looks like the DRI loading was the
cause of the problem, but I am not going to try to reboot with "load "DRI" " in
xorg.conf since I now have to catch up on my lost time from yesterday. I will
attach the xorg.conf, messages and xorg log files shortly.
Created attachment 119584 [details]
Current xorg.conf that leads to successful boot with latest kernel
Successful boot for radeon driver, NO dri, kernel 2.6.13-1.1526 with this
Created attachment 119585 [details]
Xorg.0.log for successful boot with radeon driver latest kernel, NO dri
xorg log file for successful boot with kernel 2.6.13-1.1526, radeon graphics
driver, NO dri after complete fresh install of the operating system yesterday.
Created attachment 119586 [details]
/var/log/messages after successful boot
/var/log/messages file after successful boot following complete re-install of
the operating system and fully up to date. Using kernel 2.6.13-1.1526, radeon
graphics driver and NO "dri" loaded via xorg.conf
In case it matters at this point, I had an identical problem to this. Like the
submitter of this bug, I found that my ATI (same card) configuration caused the
machine to pull a black-screen when starting X. The original FC4 Xorg build
worked fine, but the upgrade clearly broke something. I also had filesystem
corruption and had to reinstall FC4.
The above DRI-less configuration fixed the problem for me completely as well.
Had same probles with Radeon 7000 and 9200Pro. Sometimes lockup on start of
gdm, sometimes no switch to text mode, sometimes text mode corrupt. Disable DRI
worked mostly, but graphics performance in the toilet. Workaround:
edit /etc/X11/prefdm and a) ping rhgb and if true chvt 1 and echo any text to
vt1 b) then kill rhgb
else echo any old text.
This gets text into a free vt before starting the gdm or graphics switchover.
Created attachment 123842 [details]
My modded /etc/X11/prefdm
This problem seems to have recurred for FC5. I today installed FC5 (clean
install) on the same system. The initial install refused to allow me to get a
graphical install, and I opted to try a text install - this worked apparently
fine. However once the install was complete the system refused to go into first
boot, with the machine hanging as soon as it tried to start X.
This is much more severe than the reports above, in that I cannot get the system
to boot at all, even into level 3 my any apparent adjustment of the grub boot lines.
I can however boot into linux rescue from the CD1 - but changing the xorg.conf
to have the vesa driver instead of the trident which was detected by default,
also fails to start X and the same if I try the radeon driver.
I cannot get to the machine again until next week so cannot run tests this
weekend - but at present it is impossible to make any headway.
I have tried running yum update to get the new kernel in rescue mode, which
works but makes no difference. I have also tried updating xorg-X11-server which
also makes no difference.
I have to admit I have not done a full yum update at this stage and will try
that next week - however today I did try system-config-display --reconfig under
rescue mode but that failed to complete.
If there are any suggestions between now and early next week I would very much
This report targets the FC3 or FC4 products, which have now been EOL'd.
Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?
I no longer have access to the hardware to test this so I will close this bz.