Bug 10388

Have you got an Xming log file for this?

(In reply to comment #1)

> Have you got an Xming log file for this?

Installed a server with the final released FC7 and now seems ok (the server does have xen which meansit has an older kernel than a non-xen FC7 install)

I will be installing a couple of other servers over the next few days, if they're OK too I suspect this bug can be closed ....

(In reply to comment #2)

> Installed a server with the final released FC7 and now seems ok 

Oh well spoke too soon, that session lasted for a couple of hours or so and only hung once I logged out of gnome (the session was started with gnome-session from plink/xlaunch)

but on the next session it "hung" a few seconds after starting up, the differences were that the server had been yum updated from the initial FC7 release to be up to date, the console was switched from running gnome with vesa driver to just being in runlevel3 and text console, and I had upgraded xming from 6.9.90.32 to 6.9.90.37

Lots of changes at once not helpful I know, but I thought it was working.

When it freezes it isn't totally dead, it just pauses for 30+ seconds at a time, as the xming.exe is fullscreen no local win32 apps can re-paint until xming comes abck to life, then if you switch back to xming each X screen paint also takes 30+ seconds.

What type of log file will help track this down?

(In reply to comment #3)
 
> When it freezes it isn't totally dead

OK, I'm understanding a little more about what makes this problem come and go (not much idea on the underlying cause though)

If I have a gnome-terminal running, so long as it has focus the regular flashing of the cursor is /almost/ enough to keep the session alive, if I hover the mouse over other desktop items they highlight properly, or display tooltips, sometimes it freezes for about a minute but comes back to life again.

But as soon as I click e.g. the gnome menu bar and allow focus to leave the terminal window the response goes very lumpy as the terminal cursor stops flashing, if I leave window running either a continual "ls -lR /" or e.g. have gnome-system-monitor running displaying it's graphs tab then the session stays alive and fairly responsive.

However the amount of data being tunnelled through plink is huge, average 300Kbytes/sec over a LAN connection.

If I make a similar plink/xlaunch connection to a remote ancient FC3 server it only consumes about 8Kbytes/sec to display the same  gnome-system-monitor and idle gnome-terminal sessions within a desktop.

So it seems to need a constant supply of data coming from the X-client into Xming's server to stop something going to sleep, if it does go to sleep it only seems to process one "event" every minute, but if you can use that slow response to start something which will generate more output it all comes back to life again.

Something changed within FC7 that tickles this, I've made perfectly good connections to FC1 to FC5 and Tru64 servers with various xming (and cygwin/X) versions.

 

(In reply to comment #4)

> OK, I'm understanding a little more 

I thought I'd try to eliminate the plink/SSH tunnel as a source of problems, set the server back to runlevel5 and made sure gdm was set to accept XDMCP

tried a full screen xdmcp login from xlaunch, I get the gdm login screen displayed, and can enter username and password, then just get black screen and xming.exe is taking >95% CPU.

pasted below is xming log file

Welcome to the Xming X Server
Vendor: Colin Harrison
Release: 6.9.0.37
OS: Windows XP
FreeType2: 2.3.4
Contact: http://sourceforge.net/forum/?group_id=156984

Xming :0 -fullscreen -query 192.168.1.169 -clipboard 

XdmcpRegisterConnection: newAddress 192.168.1.101
(--) 5 mouse buttons found
(--) Setting autorepeat to delay=500, rate=31
(--) winConfigKeyboard - Layout: "00000452" (00000452) 
(EE) Keyboardlayout "United Kingdom Extended" (00000452) is unknown
Could not init font path element C:\Program Files\Xming/fonts/TTF/, removing from list!
Could not init font path element C:\Program Files\Xming/fonts/Type1/, removing from list!
Could not init font path element C:\Program Files\Xming/fonts/75dpi/, removing from list!
Could not init font path element C:\Program Files\Xming/fonts/100dpi/, removing from list!
Could not init font path element C:\Program Files\Xming\fonts\cyrillic, removing from list!
Could not init font path element C:\WINDOWS\Fonts, removing from list!
winProcEstablishConnection - Hello
winProcEstablishConnection - Xdmcp enabled, waiting to start clipboard client until fourth call.
winProcEstablishConnection - Hello
winProcEstablishConnection - Xdmcp enabled, waiting to start clipboard client until fourth call.
winProcEstablishConnection - Hello
winProcEstablishConnection - Xdmcp enabled, waiting to start clipboard client until fourth call.
winProcEstablishConnection - Hello
winInitClipboard ()
winProcEstablishConnection - winInitClipboard returned.
winClipboardProc - Hello
winClipboardProc - DISPLAY=127.0.0.1:0.0
winClipboardProc - XOpenDisplay () returned and successfully opened the display.
winProcQueryTree - Clipboard client already launched, returning.

winClipboardIOErrorHandler!

winClipboardProc - setjmp returned for IO Error Handler.

(In reply to comment #5)

> I thought I'd try to eliminate the plink/SSH tunnel 

Final update for today ..

Since the XDMCP wasn't successful, I just started xming with
xming :0 -fullscreen -clipboard -ac 

then manually logged onto the FC7 server using putty.exe
then did

export DISPLAY=my.xp.ip.adr:0.0
gnome-session&

lo and behold a fully responsive session which nevertheless is very bandwidth hungry, taking about 175Kbyte/sec to display gnome-session-monitor's scrolling graph and over 400Kbytes/sec with an "ls -lR /"

Try without the -clipboard option

(In reply to comment #7)

> Try without the -clipboard option

No different unfortunately, it seems that anything which sends a trickle of screen updates keeps the session alive, if the updates stop the session only seems capable of performing one "action" per timeout period of about 30 seconds, affects every F7 box I have, regardless of connection method, seems I was wrong when I though I could work around by starting session with export DISPLAY froma putty session, I just happened to run a program that did constant screen updates.

I don't think this is a problem anymore with later versions.