Red Hat Bugzilla – Bug 217237
System locks up sometime after boot. After Yum updates from Nov 10 to Nov 23rd
Last modified: 2007-11-30 17:11:50 EST
Description of problem:
Can boot, sometimes before logon prompt (gnome) system reboots itself, or after
logon and random time 10 minutes use to 1 hour, system freeze, except for
keyboard numlock. Cannot get to text mode.
Version-Release number of selected component (if applicable):
Every time. I reinstalled System on new disk, (Oct 24th version) and problem is
Here is what was pulled from searching
(WW) I810(0): Bad V_BIOS checksum
(==) I810(0): Display Info: enabled.
(II) I810(0): Broken BIOSes cause the system to hang here.
If you encounter this problem please add
Option "DisplayInfo" "FALSE"
to the Device section of your XF86Config file.
(WW) I810(0): Extended BIOS function 0x5f64 not supported.
I went to intel web site and installed latest bios update. Problem still persists.
I have substituted VESA as the driver type and system appears ok for now.
# Driver "i810"
2006/11/22, Leslie Satenstein :
Steps to Reproduce:
It appears stable with vesa driver. I will add the "display info false to the
section, reestablish i810 as driver and reboot.
My system is an Intel d95gnt motherboard, with intel d930 processor, 1 gig ddr2
memory, 1 Sata hd 200 gig, 1 pata /IDE 80 gig drive, each drive configured for
fedora. The /hda is one week behind the /sata drive. Right now, both are
demonstrating the same problem.
Created attachment 142114 [details]
Same problem with using KDE
Correction. From updates dated November 11th, go backwards to Nov 7th. Here is
where I think the problem lies, from PUP updates based on one or all of...
xorg-x11-drv-i810 ver 1-6.5-10.fc6
xorg-x11-server.org ver 1.1.1-47.1.fc6
xorg-x11-init ver 1.0.2-15.fc6
Without this upgrade my system works just fine. No crashes after hours of use.
With this upgrade, my system sometimes wont boot without a power-off recycle, or
the system reboots itself at the prompt for logon screen.
System will lockup sometime after logon. Could be within minutes or two hours.
And again, with either KDE or Gnome.
I am not a linux guru. If there is a way to extract the binaries, let me replace
the existing ones and I can test, I will be able to tell you, which of the
aforementioned items is the one causing the problem.
Thanks for the bug report. We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.
Please attach your X server config file (/etc/X11/xorg.conf) to the bug report
as individual uncompressed file attachment using the bugzilla file attachment
Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
Created attachment 144676 [details]
The xorg logfile
Created attachment 144677 [details]
Following instructions, no /etc/X11/xorg.conf was created. Previous version shown
I was asked to remove xorg.conf amd did xorg.conf ===> xorg.bak
Rebooted system and it came up ok, detected difference between gnome keyboard
layout and x11 layout. I selected gnome layout. (Canadian(fr))
Noted that no xorg.conf was created... Therefore I did the obvious
xorg.bak ===> xorg.conf (restore)
(In reply to comment #6)
> Noted that no xorg.conf was created... Therefore I did the obvious
> xorg.bak ===> xorg.conf (restore)
It is created on shutting down of Xorg, and if you have no special personal
settings in /etc/X11/xorg.conf it is really not needed anyway.
-rws--x--x 1 root root 1815124 Feb 28 16:34 Xorg Failing version
-rws--x--x 1 root root 1820676 Oct 5 00:05 /usr/bin/Xorg Good version
Failing version was the November update. Restoring it to the one distributed on
the Oct 24th DVD for FC6 fixed the problem. (
Note, I posted this solution on linux questions dot org and the feedback I have
from other postings is that it solves the problems for Dell laptops and for
other systems where the video chip is the i810.
This correction would also close bug 186321
With new mouse driver (from update)
It takes more than 2 minutes or a movement of the mouse to initiate completion
The following update dies.
Created attachment 150988 [details]
xorg.0.log after crash and a second, just in case
Created attachment 150989 [details]
Created attachment 150990 [details]
Created attachment 150991 [details]
Messages. Perhaps it will be helpful
Messages file. Perhaps it will be useful
Do you need me to keep my Fc6 system in the state as it was on March 25th? I
have two drives, and am following the progress on the second drive (Fc7), where
X does not work with XEN.
If you do not require me to keep fc6, I will put fc7 Xen on one drive and FC7
regular on the other.
I would like very much to get this issue resolved. You may call my help "free
labor and material"
Any progress with this bug. Please concentrate on FC7, as a solution there could
resolve the issues in FC6.
Yes, FC7 non-Xen testing would be good. The Xen kernel is, well, buggy.
FYI, FC7 non-Xen does not lock up. One problem noted is the following:
System-->preferences-->desktop effects on, works fine,
Turning desktop effects off with my i810 stuff on this Friday 13 April, (black
cat day) results in the loss of the bottom panel. Only way to restore bottom
panel is to logout and return.
I was able to get to XEN Fc7 by playing with the bios settings on the mother
board. There are several settings, and with one of them, I was able to work XEN
for a while, then poof, a lockup. Please keep me in the loop. My fc7 system can
serve for testing.
kernel-xen-2.6.20-1.2944.fc6 no lockup until logon screen presented. Question.
is the x-windows display of logging done in Xen mode? Why can the system boot
until the prompt is about to be displayed. Is the problem actually in the last
module in the boot series?
One additional comment: during the boot process for XEN, X shows, line by line,
with OK messages, the programs that are started. Since lockup occurs on or just
before logon screen is presented, it could be that the bug is elsewhere. Where
the last thing to appear to run successfully may be the program before xend, or
xend itself. As I stated, at that point the keyboard/mouse/power switch lockup
So if the problem is in xend, then xend needs fixing, otherwise it is in the
first executable following xend.
=Solved with FC7 May 31 release.
Thank you gentlemen.