Bug 213703 - Ctrl-Alt-F7 doesn't restore logged-in X session
Ctrl-Alt-F7 doesn't restore logged-in X session
Status: CLOSED DUPLICATE of bug 211712
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-i810 (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-02 12:14 EST by Andre Robatino
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-04 22:52:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
xorg.conf w/ maximum values (2.86 KB, text/plain)
2006-11-03 12:26 EST, Jim Cornette
no flags Details
Xorg.0.log before going to F1 (51.97 KB, text/plain)
2006-11-04 01:13 EST, Andre Robatino
no flags Details
Xorg.0.log after going to F1 (52.76 KB, text/plain)
2006-11-04 01:14 EST, Andre Robatino
no flags Details
Xorg.0.log after Alt-F7 (55.11 KB, text/plain)
2006-11-04 01:16 EST, Andre Robatino
no flags Details
Using FC6 generated file - no server crash (224.78 KB, text/plain)
2006-11-06 08:57 EST, Jim Cornette
no flags Details

  None (edit)
Description Andre Robatino 2006-11-02 12:14:48 EST
Description of problem:
 If I log into X, then go to a virtual console with Ctrl-Alt-F1, then back to X
with Ctrl-Alt-F7, it doesn't restore my session, but kicks me back to the login
screen.

Version-Release number of selected component (if applicable):
xorg-x11-server-1.1.1-47.fc6

How reproducible:
always
Comment 1 Matěj Cepl 2006-11-03 06:00:16 EST
That's wrong -- returning to X is just with Alt+F7, not Ctrl+Alt+F7.
Comment 2 Andre Robatino 2006-11-03 08:02:35 EST
  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.
Comment 3 Jim Cornette 2006-11-03 12:23:30 EST
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.
Comment 4 Jim Cornette 2006-11-03 12:26:22 EST
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.
Comment 5 Andre Robatino 2006-11-03 17:33:54 EST
  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.
Comment 6 Jim Cornette 2006-11-03 22:51:18 EST
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.
Comment 7 Andre Robatino 2006-11-04 01:13:18 EST
Created attachment 140342 [details]
Xorg.0.log before going to F1
Comment 8 Andre Robatino 2006-11-04 01:14:55 EST
Created attachment 140343 [details]
Xorg.0.log after going to F1
Comment 9 Andre Robatino 2006-11-04 01:16:11 EST
Created attachment 140344 [details]
Xorg.0.log after Alt-F7
Comment 10 Andre Robatino 2006-11-04 01:17:41 EST
  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.
Comment 11 Jim Cornette 2006-11-04 22:38:12 EST
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)
Comment 12 Jim Cornette 2006-11-04 22:46:32 EST
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)
Comment 13 Andre Robatino 2006-11-04 22:52:27 EST
  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 ***
Comment 14 Jim Cornette 2006-11-05 11:19:03 EST
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.
Comment 15 Jim Cornette 2006-11-05 16:47:20 EST
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.
Comment 16 Jim Cornette 2006-11-06 08:57:57 EST
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.
Comment 17 Jim Cornette 2006-11-06 09:00:06 EST
(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

Note You need to log in before you can comment on or make changes to this bug.