Created attachment 139041 [details]
Log file from crash.  Note signal 11 near bottom of log

I have a Dell gx270 which the X server does not crash but xscreensavers for glx
give me the error which does not allow the screensavers to display, I have an
Intel 865G integrated graphics card and am running with A04 BIOS version.
This problem is coming from FC5 which did not give the signal 11 or at least
allowed the screensavers to function mostly.

The screensavers sometimes work and mostly do not work now.

I'll file the logs later for my system along with the configuration which
s-c-display generated for the computer.

I also tried running with no xorg.conf file which worked for me with an MGA. It
did not work for the i810.

Also, I tried an X -configure version that did not work either.

Adding to the CC for this bug.

I haven't switched to a VT and then back to the GUI yet. I'll try that Monday. I
bet it will crash.

good thing that I did not put heavy money on the bet. :-)
After runnig s-c-display --reconfig and running the tests the following day,
there were no more signal 11 errors with xscreensaver. Also I did not have X
kicked from underneath me and getting the dreadee login when trying ctl-alt-F1
back to ctl-alt-F7.

  Please see my bug #213703.  It appears to be similar if not identical.  I'm
also using Intel 865G integrated video.  I tried system-config-display
--reconfig but the problem persists.  I tried looking in Xorg.0.log but don't
have any signal 11.  I can attach versions of the file under various situations
- please advise exactly under what circumstances I should copy this file, since
it appears to change rapidly.  (BTW, if this bug is associated with 865G video,
should it be marked i686?  Couldn't a 586 box use it also?)  I'm using FC6 final.

Created attachment 140279 [details]
Working file on 865G - Dell computer

Attached is my xorg.conf version that works for my system. It appears that I
did have to downgrade back to the original file. This file was last edited on
July 16th 2006.
Also, I'll attach the messed up file that messes up the system with signal 11
for comparison.

Created attachment 140285 [details]
Problematic version created by s-c-display - Error 11 on xscreensavers

S-c-display from xorg causing lockup errors.

Created attachment 140286 [details]
Problematic version created by s-c-display - Error 11 on xscreensavers

S-c-display from xorg causing lockup errors.

I think that the component should be xorg-x11-drv-i810. The reason being that I
personally had this server crash with problems with the i810 driver in the past.
These bugs were fixed, so the driver is fragile enough to be effected by less
information available for the server to prevent guessing for settings to use.
The server is to general and probably is not causing the actual failure.
For information regarding how to collect the xorg.0.log copy it to somewhere you
can reference before attempting to start X again. Runlevel 5 is not a good
runlevel due to the constant respawning. Use runlevel 3 and startx to prevent
respawning.

Comment on attachment 140286 [details]
Problematic version created by s-c-display - Error 11 on xscreensavers

Bugzilla refresh error of previous comment. disregard

*** Bug 213703 has been marked as a duplicate of this bug. ***

Some more user info is on already closed bug 211712.

  Are you thinking of bug #213703?

Created attachment 140466 [details]
This is the log with the 2004 config file

Do a scan to find the VT references where the server suspends when changing
from VT to GUI. i performed the switch several times without a bailing out of
the server.
Since I do not get the crash with this configuration, it should show you what
it was trying to do with the next step. The next step is where the server
bailed out.
After submitting this log, I'll see if using the minimul s-c-display
configuration from FC6 bails out as the two open bug reports are experiencing.

Created attachment 140470 [details]
brand new xorg.conf

I am getting indirect rendering due to slow direct rendering but not the
ctl-alt-F1 to alt-f7 crash with this file generated by S-c-display

Created attachment 140471 [details]
log file using newly generated FC6 xorg.conf

Tests were performed using runlevel 3 and starting X as user in VT2. I do not
get crashes when switching to terminals. I do have momentary error messages
being displayed when previewing X screensavers.

Created attachment 140475 [details]
original xorg.conf from install

  I don't understand what you're asking for.  The above attachment is my
original xorg.conf.  The version from running system-config-display --reconfig
is the same as yours except that for some reason each mode is listed twice (the
set of modes is the same, however).  Either version of xorg.conf gives me a
crash going from VT1 to X.

The config file from comment #5 above shows the xorg.conf file that I have the
best luck with. I however do not get the same crash as you and the other bug
report are referring to ,even using the s-c-display --reconfig version of the
file that was posted. I do get direct rendering limitations that the 2004
version does not exhibit.
I noted that there was information that referenced the server being suspended
when switching to a VT. My switching was successful and it appears that the
exiting the server is happening right after the last successful operation is
completed. Usually the error condition is not logged in some circumstances. The
next step which does not happen on your system compared to the successful
operation on my similar video card with the same action being performed
(Switching to the VT and then back to the GUI) should show the action that is
causing your exiting of the server.

The only things that I can think of that I have performed were a BIOS upgrade
back in 2004 and to set one video setting to 8MB and the other video setting to
128MB. I have not changed anything since then.

Since I noticed a problem with the screensavers causing signal 11 but not
crashing the server, /i found the other bug report referencing signal 11. Noting
that it was an 865G video also, I figured I was equally effected by the bug.

What I can do is to look at the logs submitted from both systems that look
around the VT switching, the items before the dump that you both experienced and
leave it to the developers to figure this one out and the solution.

You did a great job providing information which will help the developers figure
out this problem.
I am a user which is somewhat familiar with i810 failures from no VT in
terminals, refresh problems, the server being totally killed leaving whatever
image was displayed on the GUI until I rebooted. I hope some information is 
valuable to your understanding of the problem. If my comment #5 config file does
not help resolve your problem, we're stuchk until one of the developers cue into
the cause and find a solution to the problem.

Created attachment 140545 [details]
output of "glxinfo &> glxinfo.txt"

  I haven't tried the comment #5 config file since there is a lot of
hardware-specific info in there that would have to be modified for my setup, and
I'm not confident about being able to do it correctly.  You said you have direct
rendering limitations - that's another area I'm not familiar with, but if I run
"glxinfo" it says that direct rendering is enabled.  I'm currently using the
original xorg.conf from attachment #140475 [details].  Attached above is the glxinfo
output (including the first line which was sent to stderr instead of stdout).

glxinfo gives me about the same settings that you have listed. I did however 
notice that the settings in the comment #5 xorg.conf file was set to 16 default 
depth. I changed it to 24 and tried to ctl-alt-F1 then F7 without a server 
crash.
All I can figure is that something is failing where two of you at least get the 
dump before the server crashes. When the server tries to resume, it fails when 
it gets to the item which causes the dump to the log.
regarding the config file above in comment #5, I doubt that it would solve the 
problem that both are seeing. It does not have damaging information since the 
vertical and horizontal settings are in a fairly safe range. I am using a 
different monitor than I had in 2004 without any problem with the file calling 
for another monitor type.
Until the developers get a hold of a clue, I guess novice troubleshooting is 
all that is possible.

Where the backtrace on your file is:

(II) I810(0): xf86BindGARTMemory: bind key 7 at 0x04440000 (pgoffset 17472)
(WW) I810(0): PGTBL_ER is 0x00000029

Backtrace:
0: X(xf86SigHandler+0x81) [0x80e53b1]
1: [0x277420]
2: /usr/lib/xorg/modules/drivers/i810_drv.so [0xd506b6]
3: /usr/lib/xorg/modules/drivers/i810_drv.so [0xd5ba54]
4: /usr/lib/xorg/modules/libxaa.so [0x11ed12]
5: X [0x80d7adc]
6: X [0x80df918]
7: /usr/lib/xorg/modules/extensions/libglx.so [0xc33ecf]
8: X(xf86Wakeup+0x3bd) [0x80e6acd]
9: X(WakeupHandler+0x59) [0x808c199]
10: X(WaitForSomething+0x1b9) [0x81a0579]
11: X(Dispatch+0x8d) [0x8087fcd]
12: X(main+0x485) [0x806fa65]
13: /lib/libc.so.6(__libc_start_main+0xdc) [0x4c944f2c]
14: X(FontFileCompleteXLFD+0x1e9) [0x806eda1]

Fatal server error:
Caught signal 11.  Server aborting

(II) AIGLX: Suspending AIGLX clients for VT switch
(WW) I810(0): Successfully set original devices
(WW) I810(0): Setting the original video mode instead of restoring
	the saved state
(WW) I810(0): Extended BIOS function 0x5f05 failed.
(II) I810(0): BIOS call 0x5f05 not supported, setting refresh with VBE 3 method.

What my computer is successfully attampting on resume. The monitor that you are 
using might be specific to the problem. Can you use S-c-display and add a 
generic entry in the xorg.conf file which is relevent to your monitor? you 
should be able to find this information wherever the specs for your monitor can 
be found.

Resuming:
(II) I810(0): xf86BindGARTMemory: bind key 7 at 0x04440000 (pgoffset 17472)
(WW) I810(0): PGTBL_ER is 0x00000029

You get the backtrace, I get stats for my real type of monotor that I am using. 
See below.

(II) Loading sub module "ddc"
(II) LoadModule: "ddc"
(II) Reloading /usr/lib/xorg/modules/libddc.so
(II) I810(0): VESA VBE DDC supported
(II) I810(0): VESA VBE DDC Level 2
(II) I810(0): VESA VBE DDC transfer in appr. 1 sec.
(II) I810(0): VESA VBE DDC read successfully
(II) I810(0): Manufacturer: DEL  Model: 3015  Serial#: 1096044104
(II) I810(0): Year: 2005  Week: 21
(II) I810(0): EDID Version: 1.3
(II) I810(0): Analog Display Input,  Input Voltage Level: 0.700/0.300 V
(II) I810(0): Sync:  Separate  Composite  SyncOnGreen
(II) I810(0): Max H-Image Size [cm]: horiz.: 34  vert.: 27
(II) I810(0): Gamma: 2.20
(II) I810(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display
(II) I810(0): Default color space is primary color space
(II) I810(0): First detailed timing is preferred mode
(II) I810(0): redX: 0.640 redY: 0.330   greenX: 0.300 greenY: 0.600
(II) I810(0): blueX: 0.150 blueY: 0.060   whiteX: 0.313 whiteY: 0.329

  I'm having the same problem with suspend and hibernate - I get kicked back to
the login screen upon resume.  Michael, can you verify this?

  No change with today's xorg updates (I restarted the X server first to be sure):

Nov 20 17:18:03 Updated: mesa-libGL.i386 6.5.1-8.fc6
Nov 20 17:18:05 Updated: mesa-libGLU.i386 6.5.1-8.fc6
Nov 20 17:18:08 Updated: xorg-x11-server-Xorg.i386 1.1.1-47.1.fc6
Nov 20 17:18:13 Updated: mesa-libGL-devel.i386 6.5.1-8.fc6
Nov 20 17:18:14 Updated: xorg-x11-drv-i810.i386 1.6.5-10.fc6
Nov 20 17:18:15 Updated: glx-utils.i386 6.5.1-8.fc6
Nov 20 17:18:16 Updated: xorg-x11-drv-ati.i386 6.6.3-1.fc6
Nov 20 17:18:17 Updated: mesa-libGLU-devel.i386 6.5.1-8.fc6

Just a long shot since another bug was related to the display. It however did
not reference the GUI to VT then back to the GUI as this bug has as a symptom.
Are you both using a similar monitor? I see tthat on recovery from VT suspend,
the display is detected  again. As stated, it gets the real display that I use
in the same place as referenced in the backtraces above.

Sorry for the noise but I'm trying to give out ideas. I am about exhausted from
new ideas as of now though.

  I'm using a Dell E196FP 19" flat panel.  From attachment #139041 [details], it appears
he's using a Dell 1905FP 19" flat panel.

Thanks! I see that I have a Dell 3015 and am using the analog output. Are you
using DVI or analog?

Clip from above regarding my monitor.
Manufacturer: DEL  Model: 3015  Serial#: 1096044104
(II) I810(0): Year: 2005  Week: 21
(II) I810(0): EDID Version: 1.3
(II) I810(0): Analog Display Input,  Input Voltage Level: 0.700/0.300 V

  My el cheapo monitor only has analog output.  Googling shows that the 1905FP
has both analog and digital output.

Well that at least leaves out DVI vs. analog being a factor. In the first log
was mention of a workaround being initialized. I read part way through my
submitted log and did not see a reference to a workaround. Workarounds are not
fixes, maybe the workaround does not fix the VT switching problem.

I'll read through the log again to make sure Xorg.0.log does not mention a
workaround initiated.

Yep, I had two workarounds in the file. One for the VBE restore and the other
like the first submitted log.

  I bought an SAA7134 TV tuner card (KWorld Global TV Terminator) and now after
watching TV, X won't restart unless I reboot.  Presumably it's a kernel bug, I
reported it as bug #220916.  It's possible it's related to this bug somehow,
since a fair number of people probably have this card and if it affected all of
them, someone else would have reported it already.

  On F7, same hardware, the problem doesn't exist for me anymore! 
Unfortunately, bug #220916 does, but that affects far fewer people and is
presumably unrelated.