Bug 213703

That's wrong -- returning to X is just with Alt+F7, not Ctrl+Alt+F7.

  I just tried Alt-F7, and it does exactly the same thing.  So the bug still
exists.  (BTW, when did the shortcut take effect?)  I've been notified of bug
#211712 which appears closely related, if not the same bug.  As with the people
there, I'm using Intel 865G integrated video.

adding to cc list and operating on an integrated 865G with a July 2004 version 
of xorg.conf that works like a champ. The video information may need adjusting 
in order to assure you are setup for a capable display. The driver section 
should work fine for normal X operation, no killing the server. Attachment 
will be submited next.

Created attachment 140288 [details]
xorg.conf w/ maximum values

Use as template to see if you can get X working without a respawn because of an
aborted X.
One note. Try in runlevel 5 so you can get a clean Xorg.0.log. Every time X
reswawns, the log is overwritten or renamed as old.

  It would be easier if you could advise me first on exactly how to get logfiles
containing whatever error is causing the problem.  I don't see the "signal 11".
 Does the crash happen right after Ctrl-Alt-F1, or after Alt-F7?  And is there a
way to temporarily increase the size of the log files?  There are only two of
them, Xorg.0.log and Xorg.0.log.old, and they have a very short lifetime
currently.  It's hard to be sure that the relevant error is in the log when the
files don't persist through the transition to the VC and back.

If you start in runlevel 3 and start X with startx, X will not respawn the
display manager which will overwrite the Xorg.0.log file. Every time it respawns
you lose the previous information.
It is possible to read the Xorg.0.log file when X is relogged into. I do not
think that the act of logging in will put gdm information into xorg.0.log or
not, once your actual X session is completed. I advise runlevel 3 since it seems
safer. Xorg.0.log would contain the failed session and Xorg.0.log should contain
the X session before the crash.
Now for determining if X crashes once you shift to the VT or if X crashes once
you change from the VT to the X session, you can run 'ps -A |grep gnome' in the
VT before changing back to X with F7 if you are running GNOME. I assume you
would specify a known X program which should be running with X for another
desktop like KDE ot XFCE.

Regarding the xorg.conf file. The reason one was provided is because s-c-display
gives you a minimum configuration with newer versions of X that are released.
There are three different reports for X misbehaving. The provided xorg.conf is
more elaborate and has done well since 2004. Compare the usage of the file to
the one that s-c-display generates. You may not see a signal 11 because you are
being affected by another element that gives the other user signal 1l.
For me, the xscreensavers gave me error 11 and there was a blank screen with the
latest configuration of xorg.conf which I tried on my system. I did not change
to a VT and then back to X with the 2006 configuration that was generated by
s-c-display.
I  hope the explanation is helpful. Good luck and have success with getting the
data to fix the problem.
Also, I take it that if you see no programs that require X to keep alive in the
terminal, X would be dead at the VT switch. If you have X children programs, X
is alive until your switch from VT to GUI.

Created attachment 140342 [details]
Xorg.0.log before going to F1

Created attachment 140343 [details]
Xorg.0.log after going to F1

Created attachment 140344 [details]
Xorg.0.log after Alt-F7

  I'm using GNOME.  The crash happens when I go from F1 back to X.  Here's what
I did:
1) Logged out of X, logged into F1 as root.
2) init 3
3) Logged out of F1, logged into F1 as ordinary user.
4) startx
5) Created log file Xorg.0.log.before_F1.
6) Ctrl-Alt-F1
7) Logged into F2, created file Xorg.0.log.after_F1.
8) Logged out of F2, did Alt-F7.  Lots of console error messages, the last being
"xinit: connection to X server lost".  Back in F1.
10) Created log file Xorg.0.log.after_F7.

  The 3 files are attached above.

From the third attached log I see that it hit a problem and started dumping
information, Thus the backtrace. Then it successfully suspends the AIGLX for the
VT switch. (At least the program supposes this by the info) Then, after it
switches back from the VT, it gets up to the successfully set original devices
and then the following step is not recorded since X is blown up.
I guess the problem is happening on the switchback and resuming of the server.
I can't help you more than to say that there is a problem with the configuration
or the driver for i810 and either the RH developers will sort through this or
you might need to file a bug report upstream with xorg-x11 to get any progress.
The other signal 11 problem seemed to have a bactrace and similar results that
you experienced with the VT switching.

Hopefully the xgl maintainers can help out further. Also, the component seems to
be the i810 video driver as the component with the bug.

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.
(II) I810(0): xf86UnbindGARTMemory: unbind key 8
(II) I810(0): xf86UnbindGARTMemory: unbind key 0
(II) I810(0): xf86UnbindGARTMemory: unbind key 1
(II) I810(0): xf86UnbindGARTMemory: unbind key 3
(II) I810(0): xf86UnbindGARTMemory: unbind key 2
(II) I810(0): xf86UnbindGARTMemory: unbind key 4
(II) I810(0): xf86UnbindGARTMemory: unbind key 5
(II) I810(0): xf86UnbindGARTMemory: unbind key 6
(II) I810(0): xf86UnbindGARTMemory: unbind key 7
(WW) I810(0): Successfully set original devices (2)

for easier side by side comparisions as with the other signal 11 error, I
provide the link below.
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139041

The backtrace to end of his log is as below:
Backtrace:
0: /usr/bin/Xorg(xf86SigHandler+0x81) [0x80e53b1]
1: [0xbe0420]
2: /usr/lib/xorg/modules/drivers/i810_drv.so [0x4d96b6]
3: /usr/lib/xorg/modules/drivers/i810_drv.so [0x4e4a54]
4: /usr/lib/xorg/modules/libxaa.so [0x50fd12]
5: /usr/bin/Xorg [0x80d7adc]
6: /usr/bin/Xorg [0x80df918]
7: /usr/lib/xorg/modules/extensions/libglx.so [0x471ecf]
8: /usr/bin/Xorg(xf86Wakeup+0x3bd) [0x80e6acd]
9: /usr/bin/Xorg(WakeupHandler+0x59) [0x808c199]
10: /usr/bin/Xorg(WaitForSomething+0x1b9) [0x81a0579]
11: /usr/bin/Xorg(Dispatch+0x8d) [0x8087fcd]
12: /usr/bin/Xorg(main+0x485) [0x806fa65]
13: /lib/libc.so.6(__libc_start_main+0xdc) [0x300f2c]
14: /usr/bin/Xorg(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.
(II) I810(0): xf86UnbindGARTMemory: unbind key 8
(II) I810(0): xf86UnbindGARTMemory: unbind key 0
(II) I810(0): xf86UnbindGARTMemory: unbind key 1
(II) I810(0): xf86UnbindGARTMemory: unbind key 3
(II) I810(0): xf86UnbindGARTMemory: unbind key 2
(II) I810(0): xf86UnbindGARTMemory: unbind key 4
(II) I810(0): xf86UnbindGARTMemory: unbind key 5
(II) I810(0): xf86UnbindGARTMemory: unbind key 6
(II) I810(0): xf86UnbindGARTMemory: unbind key 7
(WW) I810(0): Successfully set original devices (2)

  I had noticed that by opening the two logs in separate tabs, going to the end
of each page, and flipping back and forth, the two cases were almost identical,
except for some probably irrelevant formatting differences in the backtrace.  So
this shows that it's a duplicate of the other bug.

*** This bug has been marked as a duplicate of 211712 ***

Hopefully a resolution can be initialized from the two similar cases. My only
recommendation is to change the component to the i810 driver for a smaller
spectrum to isolate the problem.

Thanks, the bug sounds specific to the i810 driver. I'll try the s-c-display
generated xorg.conf file after changing back and forth with the working 2004
genre version of xorg.conf which does not show the failure.
I suppose if the ctl-atl-F1 then clt-alt-f7 (or simply alt-f7) causes the server
to bail out, the problem is tickled by the less elaborate fc6 version of xorg.conf.
I'll try tomorrow. If it seems that the problem is due to the less specific
xorg.conf that is stylish now, I'll open a bug report against
system-config-display and link the three known bugs as caused by the limited
version of xorg.conf which does not work well.

Created attachment 140473 [details]
Using FC6 generated file - no server crash

I reconfigured the Xorg.conf file with S-c-display (moved 2004 version out of
way and configured with s-c-display version in FC6). The server did not crash.
It does look like it is doing some acpi related tricks when getting by where
you are crashing. you can compare where the VT switching takes place in the
log.

(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
(II) I810(0): BIOS call 0x5f05 not supported, setting refresh with VBE 3 
method.
(II) I810(0): xf86UnbindGARTMemory: unbind key 8
(II) I810(0): xf86UnbindGARTMemory: unbind key 0
(II) I810(0): xf86UnbindGARTMemory: unbind key 1
(II) I810(0): xf86UnbindGARTMemory: unbind key 3
(II) I810(0): xf86UnbindGARTMemory: unbind key 2
(II) I810(0): xf86UnbindGARTMemory: unbind key 4
(II) I810(0): xf86UnbindGARTMemory: unbind key 5
(II) I810(0): xf86UnbindGARTMemory: unbind key 6
(II) I810(0): xf86UnbindGARTMemory: unbind key 7
(WW) I810(0): Successfully set original devices (2)
(II) Open ACPI successful (/var/run/acpid.socket)
(II) AIGLX: Resuming AIGLX clients after VT switch
(II) I810(0): xf86BindGARTMemory: bind key 8 at 0x007df000 (pgoffset 2015)
(II) I810(0): xf86BindGARTMemory: bind key 0 at 0x07fff000 (pgoffset 32767)
(II) I810(0): xf86BindGARTMemory: bind key 1 at 0x07ffb000 (pgoffset 32763)
(II) I810(0): xf86BindGARTMemory: bind key 3 at 0x07fea000 (pgoffset 32746)
(II) I810(0): xf86BindGARTMemory: bind key 2 at 0x07ffa000 (pgoffset 32762)
(II) I810(0): xf86BindGARTMemory: bind key 4 at 0x07fe2000 (pgoffset 32738)
(II) I810(0): xf86BindGARTMemory: bind key 5 at 0x07000000 (pgoffset 28672)
(II) I810(0): xf86BindGARTMemory: bind key 6 at 0x06800000 (pgoffset 26624)
(II) I810(0): xf86BindGARTMemory: bind key 7 at 0x04440000 (pgoffset 17472)
(WW) I810(0): PGTBL_ER is 0x00000029