Red Hat Bugzilla – Bug 475090
screen width beyond 2048 hangs system
Last modified: 2009-01-09 18:43:18 EST
Description of problem: Setting a virtual screen of more than 2048 hangs the system. Tried also without "rhgb" boot parameter in order to use intel driver instead of fb. Version-Release number of selected component (if applicable): xorg-x11-drv-i810-2.5.0-3.fc10.i386 How reproducible: Every Time Steps to Reproduce: 1. Create xorg.conf and set Virtual larger than 2048 Actual results: Graphics output corrupted, console unusable.
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, if available) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. Could you please also try to run without any /etc/X11/xorg.conf (if you have one) 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 326053 [details] xorg.conf with virt width >2048
Created attachment 326054 [details] First Xorg.log Both logs look different. This one has been created: No "rhgb" switch: Runlevel 3: "startx" command by root. Complete system hang during X startup. Gnome panel visible, No background (b/w X11 background). Obviously not all errors could be written to the log file.
Created attachment 326055 [details] Xorg.log from "X" command Issued "X" command from root at runlevel 3. System here does not freeze completely, but terminating X leaves console unusable. Immediate reboot necessary. This file shows more meaningful error messages than the one that tries to start Gnome completely and thus freezes the system.
Dupe of bug 474327?
Yes, looks like.
BTW: "NoAccel" "True" works here as well. Beside the fact that it is no satisfying workaround
*** This bug has been marked as a duplicate of bug 474327 ***