Hi Wez, Thanks for taking time to help me with this. I do appreciate it.
I'm sorry but I can't see how this could be related to a networking or memory problem. Every service on this machine works flawlessly. This is the main reason I haven't upgraded it. There are no performance issues with networking, CPU, or memory resources. I can successfully connect to the X server (XDMCP) remotely using Xnest or Hummingbird Exceed, albeit with much more overhead than VNC. We've never had any hung X sessions until now with this VNC installation. Likewise, other network connectivity software (ssh,ftp,www,nfs) all work well. My gut feeling is that the XFree86 source I used to build Xvnc and vnc.so is not compatible with the XFree86 source that was used to build the native X server, perhaps because it required modification to build on this Sun Sparc server. I'm going to try to get it to build using the source available for this platform. Maybe Tom 'spot' Callaway, the lead Red Hat developer for Aurora, will have some insights on what might be going wrong. Thanks again for your help! --Cal Webster On Fri, 2006-11-10 at 05:29, James Weatherall wrote: > Hi Calvin, > > A VNC Viewer connected to the console X server of a system will normally > kick you off when you logout, because logout is normally implemented by > restarting the X server. > > The fact that the system hangs when you connect in to Xvnc servers as well > as when you connect in to the console X server means that it's not related > to your graphics card or drivers. The VNC server doesn't have low-level > access to the hardware of your computer, so it's not that either. > > It sounds like your computer has some more serious memory or networking > issue, to be honest. > > Cheers, > > Wez @ RealVNC Ltd. > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Calvin Webster > > Sent: 09 November 2006 22:03 > > To: James Weatherall > > Cc: 'VNC Mailing List' > > Subject: RE: vnc-server-3.3.3r2-28.2: "connection refused" or > > "end of stream" > > > > Hi Wez, > > > > I tried connecting to the console display using "vncviewer winggear:0" > > early this morning and it didn't freeze. I played around for > > a couple of > > minutes to be sure, then logged out of my X session at which point the > > VNC viewer closed (usually it stays open on console displays). I was > > able to log back in again, though, and could not get it to fail. > > > > Next I tried connecting to one of the virtual displays that are > > configured as xinetd services exactly as they are on the RHEL 4, FC 5, > > and RHL 9 machines. This time it locked up the vnc server > > system just as > > the connection to the console display had done before. I can > > still ping > > it but all network services are unavailable and the physical > > console is > > unresponsive. After this I disabled the xinetd vnc services > > until I get > > a handle on what may be causing it. Each service represents a > > different > > combination of geometry and color depth to which multiple connections > > can be made. > > > > Here is a sample of the 8 different services configured, each with a > > corresponding entry in /etc/services. > > > > Excerpt from /etc/xinetd.d/vnc > > ------------------------------ > > ## [72] Color Depth: 24-bit Geometry: 1024x768 > > service vnc1024x768x24 > > { > > disable = yes > > flags = REUSE > > protocol = tcp > > socket_type = stream > > wait = no > > user = nobody > > server = /usr/bin/Xvnc > > server_args = -inetd -query localhost -once -geometry > > 1024x768 -depth 24 -desktop Pegasus > > } > > ------------------------------ > > > > Corresponding entry in /etc/services: > > ------------------------------ > > vnc1024x768x24 5972/tcp # VNC Service 1024x768, 24-bit color > > depth > > ------------------------------ > > > > I found these warnings in /var/log/XFree86.0.log > > All but the frame buffer warning are listed in logs of working servers > > too. > > ------------------------------ > > (WW) Open APM failed (/dev/apm_bios) (No such device) > > (WW) ATI(0): Cannot shadow an accelerated frame buffer. > > (WW) ATI(0): Option "SecurityTypes" is not used > > (WW) ATI(0): Option "UserPasswdVerifier" is not used > > (WW) ATI(0): Option "PasswordFile" is not used > > ------------------------------ > > > > I found this in /var/log/messages: > > ------------------------------ > > Nov 9 08:01:24 winggear gdm[3376]: > > gdm_slave_xioerror_handler: Fatal X > > error - Restarting :0 > > ------------------------------ > > > > More in-line comments below > > > > Any further insights would be appreciated. > > > > Thanks! > > > > --Cal > > > > > > On Wed, 2006-11-08 at 07:40, James Weatherall wrote: > > [snip] > > > The only instance we've ever seen of vnc.so causing hangs > > when loaded into > > > the console X server was with a RedHat 7.3 test system with > > a particular > > > model of graphics card for which the console X server's > > drivers were rather > > > ropey. The current vnc.so has to grab the pixel data > > *back* from the > > > graphics card, which is obviously not as well > > supported/tested as the more > > > common task of putting pixels onto the graphics card. Our > > card did also > > > display some weird behaviours even without vnc.so > > installed, though, so we > > > couldn't be sure that that was the cause. > > > > The graphics card info taken from /etc/sysconfig/hwconf: > > > > - > > class: VIDEO > > bus: PCI > > detached: 0 > > device: fb0 > > driver: Card:ATI Mach64 > > desc: "ATI|3D Rage Pro 215GP" > > vendorId: 1002 > > deviceId: 4750 > > subVendorId: 0000 > > subDeviceId: 0000 > > pciType: 1 > > - > > > > Note: This is a PCI-based SuperSparc IIe (Ultra 5 clone I believe). > > > > > One other thing to remember is that if you replace vnc.so > > while you have a > > > console X server running, you must remember to move or rm > > the old one before > > > copying the new one into place, otherwise you overwrite the > > library binary > > > while it's still in use, which will either fail the copy, > > or cause the X > > > server to hang. > > > > There was never a vnc.so until I installed this one. > > > > Is it possible that the custom Xvnc build still doesn't match the > > XFree86 installed? > > > > Here's the version data from the top of /var/log/XFree86.0.log: > > ------------------------------ > > XFree86 Version 4.2.1 (Custom Build: 4.2.1-13.73.23sparc) / X Window > > System (protocol Version 11, revision 0, vendor release 6600) > > Release Date: 18 October 2002 > > ... > > Build Operating System: Linux 2.4.20-2.31sparc sparc [ELF] > > Build Host: aurora-dev.cb.de > > > > > > Module Loader present > > OS Kernel: Linux version 2.4.20-2.31sparc ([EMAIL PROTECTED]) (gcc > > driver version > > egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) executing gcc version > > egcs-2.92.11) #1 Wed Sep 24 15:39:05 EDT 2003 > > ------------------------------ > > _______________________________________________ > > VNC-List mailing list > > VNC-List@realvnc.com > > To remove yourself from the list visit: > > http://www.realvnc.com/mailman/listinfo/vnc-list _______________________________________________ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
