From Bugzilla Helper: User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2 i686) Description of problem: My gnome session automatically logs out after sometime with input condition 0x11 Here is the sequence: ----------------- Jul 1 21:40:00 lexus kernel: Uniform CD-ROM driver unloaded Jul 1 21:40:00 lexus kernel: hdc: ATAPI 40X DVD-ROM drive, 512kB Cache, UDMA(33) Jul 1 21:40:00 lexus kernel: Uniform CD-ROM driver Revision: 3.12 Jul 1 21:52:13 lexus kernel: [drm:r128_do_wait_for_fifo] *ERROR* r128_do_wait_for_fifo failed! Jul 1 21:52:13 lexus last message repeated 2 times Jul 1 21:57:43 lexus gnome-name-server[1965]: input condition is: 0x11, exiting Jul 1 21:57:43 lexus gdm(pam_unix)[1873]: session closed for user prabir Jul 1 21:57:44 lexus gdm[1873]: gdm_auth_user_remove: /home/prabir is not owned by uid 0. Jul 1 21:57:44 lexus gdm[1873]: gdm_auth_user_remove: Ignoring suspiciously looking cookie file /home/prabir/.Xauthority Jul 1 21:57:46 lexus modprobe: modprobe: Can't locate module char-major-81 Jul 1 21:57:48 lexus kernel: [drm:r128_do_wait_for_fifo] *ERROR* r128_do_wait_for_fifo failed! Jul 1 21:57:48 lexus kernel: [drm:r128_do_wait_for_fifo] *ERROR* r128_do_wait_for_fifo failed! Jul 1 22:10:01 lexus kernel: Uniform CD-ROM driver unloaded I am using downloaded version of Redhat 7.1 and Gnome as desktop Thanks, Prabir How reproducible: Always Steps to Reproduce: 1. Login to gnome session 2. keep idle for some time 3. automatically logs out Additional info: I have recntly installed Win4Lin 3.0 for RedHat. The Win4Lin modified RedHat 2.4.2 kernel is running. This occurs with or without Win4lin session running. This may not be related to the above problem
Other research I've done today has indicated that this may have to do with xscreensaver (thus the idle time required for the problem to happen); reference http://lists.ximian.com/archives/public/support/2001-February/000409.html for that info. Our cases have been intermittently repeatable but not reproducable at will; as all our machines which exhibit this behavior are running in random mode, I suspect it may narrow to a particular screensaver module or two, but that's pure gut feeling.
We have seen this problem 9 times on one Linux workstation recently. The system is running RH 7.1 with linux 2.2.19. Syslog reports this: Jul 20 14:21:27 bills gnome-name-server[17074]: input condition is: 0x10, exiting Quentin Fennessy Advanced Micro Devices
Ditto here. Every night the same thing: Aug 9 01:40:11 pc-005196 gnome-name-server[1122]: input condition is: 0x11, exiting Aug 9 01:40:11 pc-005196 gdm(pam_unix)[989]: session closed for user robr Aug 9 01:40:11 pc-005196 gdm[989]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0
We are also getting this behavior on a dozen many RedHat 7.1 machines. The error occurs sometimes several times a day, sometimes not for weeks, sometimes when someone is at console, sometimes when there is no console activity, with the screen saver set to random, and when the screensaver is set to "No screensaver". The only *possible* (but not definite) correlation I have seen is that the crashes often (but by no means always) occur when changing the window size of a Mozilla window by dragging its border.
The "input condition" message is just a symptom of losing your X server; it simply means the file descriptor for gnome-name-server's X connection had an error, i.e. the X server crashed or was killed. The messages like this may help debug the X issue: Jul 1 21:52:13 lexus kernel: [drm:r128_do_wait_for_fifo] *ERROR* r128_do_wait_for_fifo failed!
Please upgrade to the latest XFree86 release 4.1.0-25 for RHL 7.1, as well as the latest kernel. Does this problem still occur?
I believe that our fix to this problem was upgrading the kernel to 2.4.9. We have not seen this problem in a long time. We have also not seen this problem with RedHat 7.2.
Ah, indeed.. I missed that somehow. [drm:r128_do_wait_for_fifo] *ERROR* r128_do_wait_for_fifo failed! is a very very old error that came up, which was very long ago fixed, so I assumed this bug was a new bug causing the same to occur. Thanks for the update. Closing bug as fixed in ERRATA kernel 2.4.9