Bug 665540

Summary: [VMware_SVGA_II] from runlevel 3 can't logout from X environment
Product: [Fedora] Fedora Reporter: jjletho67-bugzilla
Component: xorg-x11Assignee: X/OpenGL Maintenance List <xgl-maint>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: bugs.michael, gabicr, htd, jmccann, robatino, rstrode, xgl-maint
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: [cat:lockup]
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-16 21:23:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
output of ps -ef while experiencing the problem
none
Xorg.0.log while the problem is in place none

Description jjletho67-bugzilla 2010-12-24 15:33:00 UTC
Description of problem:
In runlevel 3, after entering X with the startx command, it's impossible to logout and go back to the text only console: destop manager disappear but X remain active, without mouse and keyboard interaction.

Version-Release number of selected component (if applicable):
Fedora 14 with all update applyed. (upgrade from a fedora 13 installation)
gnome-session 2.32.0 release 1.fc14 (not sure this is the real root cause of the problem)

How reproducible:
Always

Steps to Reproduce:
1. boot in runlevel 3 and login (normal user or root)
2. start the X environment with the startx command (gnome desktop manager)
3. logout from X using the "log out <username>" command in the System menu
  
Actual results:
desktop manager disappear but X remain active. No keyboard nor mouse interaction are possible. The desktop background image is visualized on the screen and nothing else.

Expected results:
gnome session and X are fully terminated and text only console appear on the screen.

Additional info:
After the logout attempt the system is still active, I can login remotely with ssh and interact with it. From the remote ssh session I was able to start again the desktopmanager and kill it again, but X never die. Switcing from runlevel 3 to runlevel 5 let the graphical user login appear on the screen, but going back to runlevel 3 still does not kill X.
The hardware is a vmware virtual machine. with Fedora 13 I have never had this problem.

Comment 1 jjletho67-bugzilla 2010-12-24 15:36:11 UTC
This bugs looks correlated or similar to bugs 649940 and 640925

Comment 2 htd 2010-12-24 16:55:21 UTC
I can confirm this on three machines running F14 (all the other machines here already run on opensuse, because of the bugs mentioned above, they are blocking ones in my case). And yes, this seems strongly related to 649940 and 640925.

Comment 3 jjletho67-bugzilla 2010-12-24 17:03:22 UTC
I switched the desktop from gnome to kde and the problem persist. Probably the bug it's not gnome related.

Comment 4 jjletho67-bugzilla 2010-12-25 22:10:38 UTC
Created attachment 470691 [details]
output of ps -ef while experiencing the problem

output of the command ps -ef after this sequence of actions:

1) boot in runlevel 3
2) login with a normal user
3) startx
4) logout with the "log out <username>" button in the system menu
5) the screen show only the background image, no menu, no windows, no mouse, no keyboard
6) login into the machin remotely with ssh
7) ps -ef

Comment 5 jjletho67-bugzilla 2010-12-25 22:32:21 UTC
Created attachment 470692 [details]
Xorg.0.log while the problem is in place

The content of the file Xorg.0.log immediately after the problem comes up. I took it remotely through an ssh connection.

Comment 6 jjletho67-bugzilla 2010-12-25 22:34:45 UTC
I'm able to reproduce the issue with KDE, GNOME, FLUXBOX and FVWM desktop environment. I suspect the problem is in Xorg or in the kernel. I'm changing the affected component.

Comment 7 htd 2010-12-26 08:41:02 UTC
This is not a kernel problem, the bug is persistent with all vanilla kernels, from stable mainline to the latest 2.6.37-rc7-git2 (without any F14 patches, straight vanilla).

Comment 8 jjletho67-bugzilla 2010-12-26 14:59:46 UTC
hdt are you experiencing the problem on f14 fresh installation or have you upgraded from f13/f2/.... ? This could be another important parameter to consider.

Comment 9 jjletho67-bugzilla 2010-12-26 17:12:08 UTC
I did a test with an F14 fresh installation (NO upgrade from F13, NO patch after installation) and the problem occours, so we can EXCLUDE that upgrading from f13 is causing the problem.

Comment 10 htd 2010-12-26 18:11:24 UTC
Two of my affected machines are directly installed from a F14 DVD, one is preupgraded from F13. All three have the same bug. I don't know if this is already present in plain F14, directly afer installing. Usually, I install from DVD and run a "yum update" directly after.

Comment 11 jjletho67-bugzilla 2010-12-27 11:55:37 UTC
htd: yes i confirm the bug is present in plain F14 DVD, yesterday i did a clean installation from a DVD without any patch and I reproduced the problem.

htd What kind of hardware are you using ? 
I'm working on vmware player 3, but in the next few days i will try also on different hw.

Comment 12 jjletho67-bugzilla 2011-01-20 17:36:19 UTC
I verified i can reproduce the problem also with the livecd. This allowed me to further investigate the problem on a different hardware, those are the results:

Test 1 (vmware hardware)
1) boot the vmware virtual machine with the F14 Livecd in runlevel 3
2) login as root
3) startx
4) logout using the system menu
5) screen/keyboard/moused frozen, problem reproduced

Test 2 (Intel q35 based pc,82Q35 Express Integrated Graphics Controller )
1) boot a pc with Intel q35 chipset and an onboard graphics card with the F14 livecd, in runlevel 3
2) login as root
3) startx
4) logout using the system menu
5) the text console is visualized -> the problem is NOT reproduced

So the bug seems to be hardware related!
the xorg-x11-drv-vmware driver could be the source of the problem, is someone of you able to build an updated package using the latest xorg version of the driver ?
(The last fedora version is 11.0.1 while on xorg the latest is 11.0.3)

Comment 13 gabicr 2011-01-30 10:45:24 UTC
For me this bug is present on:
- 1 physical machine with Nvidia drivers x86 PAE architecture;
- 1 Vmware (Player) virtual machine x86_64 architecture;

However on Lenovo W500 laptop, x86_64 this bug doesn't appear.

All 3 machines are installed from scratch.

Comment 14 Andre Robatino 2011-04-25 19:36:18 UTC
I tried this on my VirtualBox 4.0.6 F14 x86_64 guest with updates-testing enabled and could not reproduce it. I booted in runlevel 3, logged in as an ordinary user, and ran startx. Logging out from X brings me back to the console prompt.

Comment 15 jjletho67-bugzilla 2011-04-26 11:13:54 UTC
I did a test on a different pc: core i7, asus p6t mb, nvidia gt210 /gt220 and i REPRODUCED the issue. 

So at this time the problem is for sure hwa related, but NOT limited to a single specific type of hw.

Comment 16 Fedora End Of Life 2012-08-16 21:23:55 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping