Red Hat Bugzilla – Bug 383481
Xen kernel with i810 Xorg driver causes system reboot on Intel G965 motherboard
Last modified: 2008-12-16 17:00:01 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9 Description of problem: Using the following Intel motherboard: http://www.intel.com/products/motherboard/DG965MQ When RHEL 5.1 is installed with virtualization selected during install time using this motherboard, the installer sets up X to use the i810 driver. Once the installation is complete, a reboot happens as usual where rhgb is shown. As soon as rhgb is complete, X would ordinarily start. Instead, the system immediately jumps to the BIOS screen rebooting all over again. If left unattended, this cycle would repeat indefinitely. To get around this temporarily, I changed the driver from i810 to vesa in xorg.conf. The vesa driver works with both Xen and non-Xen kernels. Booting with the i810 driver using the non-Xen kernel works fine. If I boot in runlevel 3 with the Xen kernel, I can log into a console start X with startx using the i810 driver but the system at worst would hang in the middle or at best wait until I log out where the end of X causes the system to jump to the BIOS screen immediately and causing a reboot. Version-Release number of selected component (if applicable): xorg-x11-drv-i810-1.6.5-9.6.el5 kernel-xen-2.6.18-53.el5 How reproducible: Always Steps to Reproduce: 1. Install RHEL 5.1 on an Intel DG965MQ motherboard. 2. Include virtualization. 3. Complete installation and allow system to reboot. 4. System will boot with Xen kernel and start X with the i810 driver. 5. System will immediately jump to BIOS screen as noted in description. Actual Results: System would hang or jump to the BIOS screen. Expected Results: X would start as expected. Additional info:
Created attachment 258911 [details] xorg.conf file used to demonstrate the problem
Created attachment 258921 [details] Xorg.0.log of system successfully running i810 driver w/non-Xen kernel
Add me to the list of people suffering from this bug. I encounter it on a Q35 "Bearlake" machine (CELSIUS W360) under the following circumstances: - 32-bit XEN kernel (PAE kernel works, x86_64 XEN kernel works too) - 4 GB of RAM in the machine (it works fine with 2 GB) So I think this might be a sort of "boundary" problem. Is there anything I can try out to track the problem a bit more? I put my TAM on CC as well so that he gets notified on that problem too. Regards Rainer
*** Bug 383421 has been marked as a duplicate of this bug. ***
Adding a metoo. X61 here. Switching to vesa only partly resolves the problem, because with vesa I am not able to switch to the virtual console with CTRL-ALT-F1 - empty screen. Jan
Upgraded to RHEL 5.2 and it still has the same problem.
I am experiencing the same issue on an intel 965GM chipset with a i915 graphics card.
I get the same results on 5.3 Beta.
It looks like you are using the "i810" driver for graphics cards other that i810. Have you tried the "intel" driver. This driver was introduced in 5.2. I it is in the xorg-x11-drv-i810 rpm. You can simply change "i810" to "intel" in the xorg.conf file or run system-config-display --reconfig to use the "intel" driver. This driver is recommended for intel graphics over the i810 driver except for actual i810 through i830 hardware.
I booted in runlevel 3, changed xorg.conf to use "intel", ran startx, everything looked great, logged out, instead of going back to the virtual terminal console the system jumped immediately to the BIOS screen and rebooted (exactly as described previously). If I would have set the runlevel to 5, the system would reboot over and over when rhgb would exit and before X for gdm would start.
I installed the 5.3 beta nightly (12/10/08). I can now boot the system with the xen kernel. But in the process of creating a paravirt guest, the laptop rebooted itself once the the guest began creating the filesystem for install. Could this bug be a duplicate of #433528?
*** This bug has been marked as a duplicate of bug 433528 ***