Created attachment 331206 [details] My Package List Description of problem: This might be related to bug #482997 and bug #481679, but on 2.6.27.12-170.2.5.fc10.x86_64, not 2.6.28.1-17.fc10.x86_64 or 2.6.28.1-19.fc10.i686, as their respective reporter claims the bug to be exclusive on their respective kernel versions, which is the reason I am filing this one. Those 2 bugs with this one combined might be regrouped into a single bug. After selecting "Other..." when gdm-user-switch-applet is activitated, the user is brought into a regular gdm login screen with the middle white space (which is supposed to hold all of the usernames, and in my case, my own username) blank. The panel at the bottom is without any item as well, just blank. "Ctrl+Alt+Fx", "Ctrl+Alt+Backspace" and "Ctrl+Alt+Delete" were attempted, and none ever worked. CapsLk does not work as well. As for X itself, I do not have system-config-display installed, so /etc/X11/xorg.conf doest not exist. Hence I am not sure whether the Xorg option "DontZap" is on or not. For a complete list of packages please refer to the attachment. Version-Release number of selected component (if applicable): $ yum list gdm-user-switch-applet gdm kernel kernel-firmware xorg-x11-drv-i810.x86_64 Loaded plugins: refresh-packagekit Installed Packages gdm.x86_64 1:2.24.0-12.fc10 installed gdm-user-switch-applet.x86_64 1:2.24.0-12.fc10 installed kernel.x86_64 2.6.27.5-117.fc10 installed kernel.x86_64 2.6.27.12-170.2.5.fc10 installed kernel-firmware.noarch 2.6.27.12-170.2.5.fc10 installed xorg-x11-drv-i810.x86_64 2.5.0-4.fc10 installed $ rpm -qa > package-list.txt How reproducible: Please check out the section next. Steps to Reproduce: (Supposed that you just landed onto GNOME vis GDM with your personal account.) 1. Move the cursor to the gdm-user-switch-applet on the right section of the top panel and click. 2. Now a menu appears with available user accounts, and an option at the bottom *"Other..."*. Click on "Other...". 3.Congratulations! On the good old GDM login screen everything except mouse freezes up! Actual results: Everything except mouse freezes. And X cannot be killed via regular "Ctrl+Alt+Fx", "Ctrl+Alt+Backspace" and "Ctrl+Alt+Delete" (I have not tried ssh yet). The middle space which is supposed to hold usernames is blank. The panel at the bottom is without any item as well. Expected results: GDM is supposed to provide usernames to click on to log in with some items to click on at the bottom panel. X is supposed to be able to be killed or switched via regular keyboard combo. The system is supposed to be able to shutdown via regular keyboard combo. Additional info: For package list pls see attachment.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf), X server log file (/var/log/Xorg.*.log) and dmesg output to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. We will review this issue again once you've had a chance to attach this information. Thank you in advance.
Created attachment 331207 [details] My dmesg
Created attachment 331208 [details] My X Log
Created attachment 331209 [details] My X Log
Created attachment 331210 [details] My X Log
Created attachment 331211 [details] My X Log
It appears that this issue goes way yet it still distorts the workspace with kernel 2.6.28.7.
Never mind, it seems that for some occasions it works, albeit partially with 2.6.28.7. For most of the time it does not. For those occasions that it does not work "top" says follows: top - 09:47:11 up 18 min, 4 users, load average: 1.04, 0.94, 0.59 Tasks: 177 total, 4 running, 172 sleeping, 0 stopped, 1 zombie Cpu(s): 51.2%us, 0.2%sy, 0.0%ni, 48.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 3987596k total, 1246740k used, 2740856k free, 16348k buffers Swap: 6029304k total, 0k used, 6029304k free, 565688k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3424 root 20 0 361m 7436 4544 R 99.7 0.2 10:07.86 Xorg 3229 jzhou 20 0 785m 114m 25m R 1.7 3.0 0:22.32 firefox 2436 root 20 0 404m 48m 12m S 0.7 1.2 0:17.93 Xorg 3628 jzhou 20 0 14880 1192 872 R 0.3 0.0 0:00.50 top 1 root 20 0 4084 868 616 S 0.0 0.0 0:00.63 init 2 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kthreadd 3 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0 4 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0 5 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0 6 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/1 7 root 15 -5 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/1 8 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/1 9 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 events/0 10 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 events/1 11 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 khelper 14 root RT -5 0 0 0 S 0.0 0.0 0:00.00 kstop/0 15 root RT -5 0 0 0 S 0.0 0.0 0:00.00 kstop/1 It might be related to X issues in general.
The "top" stuff is done through ssh. However, one more symptom should be noted that when you tried to log in with "ssh -o 'ForwardX11 yes'" option, firefox will freeze, or almost freeze, if you happen to start it. (In reply to comment #8) > Never mind, it seems that for some occasions it works, albeit partially with > 2.6.28.7. For most of the time it does not. For those occasions that it does > not work "top" says follows: > > top - 09:47:11 up 18 min, 4 users, load average: 1.04, 0.94, 0.59 > Tasks: 177 total, 4 running, 172 sleeping, 0 stopped, 1 zombie > Cpu(s): 51.2%us, 0.2%sy, 0.0%ni, 48.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st > Mem: 3987596k total, 1246740k used, 2740856k free, 16348k buffers > Swap: 6029304k total, 0k used, 6029304k free, 565688k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 3424 root 20 0 361m 7436 4544 R 99.7 0.2 10:07.86 Xorg > 3229 jzhou 20 0 785m 114m 25m R 1.7 3.0 0:22.32 firefox > 2436 root 20 0 404m 48m 12m S 0.7 1.2 0:17.93 Xorg > 3628 jzhou 20 0 14880 1192 872 R 0.3 0.0 0:00.50 top > 1 root 20 0 4084 868 616 S 0.0 0.0 0:00.63 init > 2 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kthreadd > 3 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0 > 4 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0 > 5 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0 > 6 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/1 > 7 root 15 -5 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/1 > 8 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/1 > 9 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 events/0 > 10 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 events/1 > 11 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 khelper > 14 root RT -5 0 0 0 S 0.0 0.0 0:00.00 kstop/0 > 15 root RT -5 0 0 0 S 0.0 0.0 0:00.00 kstop/1 > > It might be related to X issues in general.
Just a note that there are now several similar reports with different hardware: Bug 482997, Bug 484516, Bug 450197, and Bug 439294.
*** Bug 488828 has been marked as a duplicate of this bug. ***
I also have the same problem. My uname -rv result is below 2.6.27.24-170.2.68.fc10.i686 #1 SMP Wed May 20 23:10:16 EDT 2009
Just a note that this again works on F-11
Thanks. I hope to try it soon on a 64-bit system.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.