Description of problem:
Summary line is accurate. When problem occurs, doing a restart of X does not
recover. Only way to recover is via a reboot.
Version-Release number of selected component (if applicable):
Fc7 test4 with all updates as of May 6th, 2007
Create two or three users on the FC7 not with XEN kernel. After logging onto
one, switch to the other, logon to it, then switch back. Try this twice.
Steps to Reproduce:
Reboot of system necessary.
To work as intended
Although I reported it in Fc6 6.93 test4, the problem still is present in fc7
production (non XEN).
I will advise if the problem is present in the XEN version.
Whatever, I just wont use that facility.
Here it is just before fc8 release, and the problem persists. Since the initial
posting I have upgraded system as follows:
a) memory 2.5 gig
b) Mother board intel d945gnt (with most recent bios update)
c) fc7 64bit Gnome interface version
d) all updates (yum update or pup) completed.
The summary information (below) does not change.
If I log to two virtual users (ctl-alt-f1, ctl-alt-f2), and then try to return
to Gnome (ctl-alt-f7), I will hear the switch (terminal -- NEC Multisync
E1100+) has relay to change but screen remains dark. Multiple ctl-alt-backspace
does not restore screen.
Only recourse is a reboot.
Here is further information.
a) problem is with both 32 bit and 64 bit distributions executing from the same pc.
b) Mother board is an intel d945gnt, using built-in video (945 bios driver)
c) Video resolution 1024 x 768
d) memory 2.5gigs
With kernel 22.214.171.124-41.fc8 and ati card, it works. (32bit version of pc).
Will report back to you with Intel System.
Hello Matthias. Here is some results following further testing. The problem has
to do with recursion.
Following further testing. Starting from User A.
User A calls User B, who does some work, and then user B exits.
Result: All is OK, One can return to User A.
User A calls User B, who does some work, calls User C. User C exits and returns
to B and then user B exits and it returns to A. All is OK.
User A calls User B, who does some work, calls User A. User A logs in, even
though he is already logged in. He does some work and exits and then the system
does not allow the return to B.
The problem is that in Case 3, User A is logged twice when actived the second
time, and it fouls up Gnome. When the screen does not return, I know that the
system prompt is present because I turned on sound to indicate the presence of a
system prompt logon screen.
Sound returns at the right time, telling me to log, but the screen is black.
What is available when the screen is black is the text logon via ctl-alt-f1..
ctl-alt-f6 ctl-alt-f7 is the black screen.
NB. In Case3, ctl-alt-backspace resets gnome, but does not restore the screen in
the sense of removing the blackout. Logon screen remains blacked out. BUT
ctl-alt-f1 is available to issue a reboot.
I believe that the fix is to have the code check that the user X was not still
previously logged in. If X was previously logged in, generate an error message.
User Y should only be able to return to User X if he/she exits.
This checking should only be done when trying to do a switch-user.
Logon recursion is not allowed.
Hmm, how do you log in a second time as A ?
The fast-user-switch-applet should already keep track of logged in users, and do
the right thing when you switch to them (bring up the existing session), as
Log as A, switch user to B, and switch user to A. If I recall, it should not
allow B to switch user to A. Ergo, problems of black screen.
I did Log as A, switch to B, in B, switch to C, in C log to A.
And it did it.
and it forces reboot, as the screen remains blanked out.
With ctl-alt-f1, I sometimes have the text screen, and sometimes not.
When not, I am able to do logon, (first prompt), and then password.
Followed by reboot. (all in the black).
Sorry, I still don't follow. If I repeat your A,B,C sequence, I get back to the
first session at the end, ending up on the screensaver lock dialog. And
everything works just fine.
Unless you mean something different with "log to" as opposed to "switch to" in
Log as A, switch to B, in B, switch to C, in C log to A.
I regret but this problem is with a Intel d945gnt and the i810 driver (video is
on the mother board). It happens with 32 bit and 64 bit versions of Fedora 7.
I believe the problem is one of X windows not being reset properly. Is it
possible that something is not saved on the stack. For example, I did not test
the preceding sequence, where, between user A and User B, I do a screen
Lets try it in 7 days, when fc8 is out and I have fc8 installed.
Here is some feedback. The same problem exists in fc8 test3. And I have more
If one never touches compiz or beryl, then there is no corruption of files in
one of the hidden subdirectories directories of the user directory ~
I took three logons that did not include my existing user id, and I could not
make the problem occur.
Right now, I have a home directory that I will clean of personal stuff, and I
will forward it.
FWI. The problem also occurs with two other distributions. UBUNTU, and
PClinuxOS. The problem is truly with compiz and / or beryl.
Advise if I need to send you my stripped down home directory.
Well, Today, Feb 5, 2008, with kernel 126.96.36.199-107.fc8 I tried several
iterations to a depth of 4.
Everything worked (gnome-->gnome) 5 cycles
(gnome->gnome->kde) 2 cycles
No lockup and also X windows did not die.
Therefore, for the X64 non-zen version of fedora and version 8, everything works.
Later, I will report the same experiment using Fedora 7 X64 Non Zen version,
using the same hardware as last reported.
Did the Fedora 7 tests, with all users not on compiz, and no recursion.
After two levels, of nesting (logon leslie --> logon Laurie --> Logon guest01)
The system failed. (black screen of death).
The ctl-alt-sequences of f1 to f7 or backspace) could not restore the system.
I tried usb plugging and unplugging, got some error messages, but... no luck
The messages included lost page, and dead device.
On reboot, since I could not recover logon screen, the file system indicated
orphan entries. Never-the-less, the forced reboot brought the system back to normal.
This problem, bottom line, is that it still exists in Fed7_X64 non-zen, but does
not exist with Fed8_x64
Closing as fixed in current release per last comment. Thanks.