waiting for X server to begin accepting connections .
Hello, Tonight, from home, over my employer's VPN connection: impossible to start Gnu emacs over X. After the usual expr dumping core: /usr/bin/startx: line 47: 6444 Segmentation fault (core dumped) expr "$1" : ':[0-9][0-9]*$' > /dev/null 2>&1 I get an effect which I have already seen, but only until now in a transient mode: waiting for X server to begin accepting connections . .. .. .. .. Only now, it goes on until timeout, and reproduces on the next try... The log ends in: xwin> tail -2 XWin.0.log [ 12500.250] winMultiWindowXMsgProc - XOpenDisplay () returned and successfully opened the display. [ 12500.250] winClipboardProc - XOpenDisplay () returned and successfully opened the display. My command (in a batch file): chdir C:\cygwin\bin bash --login -c "/usr/bin/startx /usr/bin/emacs -g 90x37+150+0 -- /usr/bin/X :0 -multiwindow -clipboard" What can be the cause? Thanks Marc http://old.nabble.com/file/p33432156/cygcheck.out cygcheck.out -- View this message in context: http://old.nabble.com/waiting-for-X-server-to-begin-accepting-connections-.-tp33432156p33432156.html Sent from the cygwin-xfree mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Xwin.exe always take about 50% CPU load on Windows 7 with XDCMP connection
On 02/03/2012 09:24, Kees Dekker wrote: > I’m using Xwin.exe (version 5. Feb 2012, X.org servers – 1.11.4-3) on my > Windows 7 system. When connecting with XDCMP (using startxdcmp.bat, with > %RUN% XWin -query %REMOTE_HOST% -once -lesspointer -clipboard > -emulate3buttons), after connect, the CPU load is about 50%. Even when > nothing is done (only the CDE desktop is running, nothing else). > > On another Windows 7 system, also connecting with XDCMP to the same server, > same CDE, the CPU load is not that high. The version of XWin is one of 5. > Feb 2009. > > The XCDMP server is a Solaris 10 system, using Solaris classic CDE (not the > Java Desktop environment). The high CPU load did not happen when the CDE > waits for the logon screen, but happens as soon as login was completed. > > BTW. Just when I was writing this email I decided to check (again) for a > newer version, and there was one… Moving to X.org servers 1.11.4-5 seems to > solve this issue ☺. However, I did not find any release note telling that > this problem was solved…. I'm not sure where you were looking if you didn't find [1]. 'On Cygwin 1.7.10 this caused XWin to spin, when started from a non-cygwin process, spamming the log with "_XSERVTransSocketUNIXAccept: accept() failed" messages.' [1] http://cygwin.com/ml/cygwin-xfree-announce/2012-02/msg4.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Xwin.exe always take about 50% CPU load on Windows 7 with XDCMP connection
Hi, I’m using Xwin.exe (version 5. Feb 2012, X.org servers – 1.11.4-3) on my Windows 7 system. When connecting with XDCMP (using startxdcmp.bat, with %RUN% XWin -query %REMOTE_HOST% -once -lesspointer -clipboard -emulate3buttons), after connect, the CPU load is about 50%. Even when nothing is done (only the CDE desktop is running, nothing else). On another Windows 7 system, also connecting with XDCMP to the same server, same CDE, the CPU load is not that high. The version of XWin is one of 5. Feb 2009. The XCDMP server is a Solaris 10 system, using Solaris classic CDE (not the Java Desktop environment). The high CPU load did not happen when the CDE waits for the logon screen, but happens as soon as login was completed. Regards, Kees BTW. Just when I was writing this email I decided to check (again) for a newer version, and there was one… Moving to X.org servers 1.11.4-5 seems to solve this issue ☺. However, I did not find any release note telling that this problem was solved….