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): How reproducible: Every time. I reinstalled System on new disk, (Oct 24th version) and problem is gone. 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. Section "Device" Identifier "Videocard0" # Driver "i810" Driver "vesa" EndSection 2006/11/22, Leslie Satenstein : > Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: 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] X11 log
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 link below. 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
25march2007 With new mouse driver (from update) xorg-x11-drv-mouse-1.2.1-1.fc6.i386.rpm It takes more than 2 minutes or a movement of the mouse to initiate completion of boot. The following update dies. xorg-x11-drv-i810-1.6.5-10.fc6.i386.rpm
Created attachment 150988 [details] xorg.0.log after crash and a second, just in case
Created attachment 150989 [details] xorg.log
Created attachment 150990 [details] Boot log
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 interrupt occurs. 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.