Created attachment 17482 [details] xorg log for failed boot attempt With a clean, updated install of Fedora 9, I am unable to boot directly into X. Instead, X fails silently and the monitor reports "out of sync range." If I boot into text mode and startx, X works as expected. Fedora 8 worked as expected. Updating to xorg-x11-drv-i810-2.3.2-2.fc9.x86_64 results in changed behavior when I attempt to boot directly into graphical mode. Instead of a dark monitor, the display is smeared and garbled. Xorg then restarts itself, resulting in another garbled display. Booting into text mode and running 'startx' works as expected. If I quit X and try to 'startx' a second time, the display locks. Xorg.log attached. I opened a bug report on the Redhat Bugzilla, but thought this may be an upstream issue.
Created attachment 17483 [details] lspci output
Redhat Bugzilla link: https://bugzilla.redhat.com/show_bug.cgi?id=453366
I don't know what's rhgb doing. But since it disappears without rhgb, this indicates it might be redhat specific issue.
this isn't really rhgb related. rhgb just seems to create a precondition where x just crashes instead of running seemingly ok, but with uncached video memory. it can be worked around by different mtrr settings before starting x (see https://bugzilla.redhat.com/show_bug.cgi?id=446620 for more info). the asus mobos have a somewhat uncommon mtrr mapping which i nevertheless consider correct and legal. i am not really sure if the kernel, the x server, or the intel driver should be responsible for either fixing this up or correctly dealing with it. on my mobo (asus p5e-v) with 4 gb and memory remapping enabled, /proc/mtrr ends up like this: reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1 reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 reg04: base=0x120000000 (4608MB), size= 256MB: write-back, count=1 reg05: base=0xcf800000 (3320MB), size= 8MB: uncachable, count=1 if i do the fix i described in the above fedora bugzilla link, it becomes reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 reg02: base=0x80000000 (2048MB), size=1024MB: write-back, count=1 reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 reg04: base=0x120000000 (4608MB), size= 256MB: write-back, count=1 reg05: base=0xcf800000 (3320MB), size= 8MB: uncachable, count=1 reg06: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1 reg07: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=2 and X works. with or without rhgb.
then it seems bug#15360
*** This bug has been marked as a duplicate of bug 15360 ***
not really. i think in this case there is a legal and correct mapping which x (or maybe the kernel) doesn't deal with correctly.
I have written an experimental userland program to reconfigure MTRRs. See comment #18 in https://bugzilla.redhat.com/show_bug.cgi?id=446620
we won't fix this in our driver. It should be handled by kernel or FW upgrade..
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.