bph@buengc.BU.EDU (Blair P. Houghton) (09/23/89)
This is with Ultrix 3.1, UWS 2.1, X11R3, on a VAXstation II/GPX; the display is a vr290. A few hours after starting up the xcons (by putting the proper line in /etc/ttys and doing kill -HUP 1), the console-display's X server (Xqdsg) locks up. Not only is the server going south, but it takes the display head with it. It sends video gibberish, making a tightly-meshed lissajous pattern on the screen. Because of the severity of the mess, I thought at first that it was the vr290 that was bad. Then I remembered that I had just tried xcons, and I had been wondering why my predecessor as manager of these machines had not used it. I can fix it temporarily by rlogin from the second vr290 (it's a two-headed GPX) and kill -KILL on the Xqdsg and all other processes attached to ttyv0, including the xcons, but init starts up both the X server and xcons, and a couple of hours later it all crashes again. Removing the xcons line from /etc/ttys eliminates the problem (it hasn't crashed in days). But that's no solution. It won't do to have random warnings scribbled all over the console's screen, especially when running display-intensive CAD tools. I'd appreciate any help or insight. --Blair "Even a lollipop. :-)"
perry@ccssrv.UUCP (Perry Hutchison) (09/23/89)
In article <4327@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: > This is with Ultrix 3.1, UWS 2.1, X11R3, on a VAXstation II/GPX; the display > is a vr290. <description of nasty xcons/Xserver bug> > Removing the xcons line from /etc/ttys eliminates the problem > But that's no solution. It won't do to have random warnings scribbled > all over the console's screen Try a Sun. :-) :-) :-) Seriously, is it possible to assign the console function to a VT-100 attached to a serial port so as to get the system messages off the vr290?
mbr@aoa.UUCP (Mark Rosenthal) (09/27/89)
In article <4327@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: [ Description of X-server going south when using xcons ] >Removing the xcons line from /etc/ttys eliminates the problem (it hasn't >crashed in days). > >But that's no solution. It won't do to have random warnings scribbled >all over the console's screen, especially when running display-intensive >CAD tools. > >I'd appreciate any help or insight. This is neither help nor insight, but merely confirmation that you are not imagining this. I ran into the same problem with a similar configuration: VaxStation II/GPX, Ultrix 3.0. I think the model no. of the monitor was VR 260, but I'm not sure. In any case, it was DEC's black & white monitor. The screen would display a faint band of unsynched video, about 4" high, across the center of the tube. I seemed to be able to force the problem by filling up one of the disk partitions. That never did make any sense to me. I speculate that perhaps it has something to do with the format of the error generated when a disk partition fills up, but who knows. In any case, I never found a solution to the problem. DEC's support line was no help at all. They took three days to come up with the answer that they considered "xcons" and "xterm" to be unsupported products, and that I should run DECwindows instead. Sadly, my solution is what you call "no solution". Comment out the xcons line in /etc/ttys, and make sure your window manager has a refresh screen selection. Yecch! -- Mark of the Valley of Roses ...!bbn.com!aoa!mbr
bph@buengc.BU.EDU (Blair P. Houghton) (09/29/89)
In article <945@aoa.UUCP> mbr@aoa (Mark Rosenthal) writes: >In article <4327@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: >> [ Description of X-server going south when using xcons ] > >I seemed to be able to force the problem by filling up one of the disk >partitions.[...] I speculate that perhaps it has something to do with >the format of the error generated when a disk partition fills up, but >who knows. > >In any case, I never found a solution to the problem. DEC's support line was >no help at all. They took three days to come up with the answer that they >considered "xcons" and "xterm" to be unsupported products, and that I should >run DECwindows instead. "Your Guccis need a lace, but we don't know how to tie it, so here's some enormous rubber boots instead...buckle away." >Sadly, my solution is what you call "no solution". Comment out the xcons line >in /etc/ttys, and make sure your window manager has a refresh screen selection. Both done long ago. "Refresh" is at the top of the pop-up menu. Several people have mentioned using cat -u /dev/xcons which actually does the job for a while, but then causes the same server symptoms as running xcons(8X). I think you're right about the "format of the error generated" being the problem. I don't get it just by filling up disks, though. The "cat -u..." command has another problem: if the server dies, you can never kill that cat, even as root and logged in on a separate character terminal. It ignores kill -9. The only cure is reboot. Actually, I could live with the non-xcons screen-scribbling messages, but there's documentation to the effect that (and please don't ask me where, I think it was buried in the section on ed(1) :-) these messages will only become visible if you kill the server, which is true: when Xqdsg terminates, the invisible ink suddenly becomes readable, but only for the half-second it takes init to start up another Xqdsg... the only cure here must be to halt init(oyveh). --Blair "Hey, this one's got a busted buckle on it..."
klee@gilroy.pa.dec.com (Ken Lee) (10/03/89)
In article <4327@buengc.BU.EDU>, bph@buengc.BU.EDU (Blair P. Houghton) writes: > A few hours after starting up the xcons (by putting the proper line > in /etc/ttys and doing kill -HUP 1), the console-display's X server > (Xqdsg) locks up. Note that the xcons and xterm -L stuff will be removed from X11R4 by MIT. At best, it's kind of flakey. Try using xdm or dxsession instead. Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@decwrl.dec.com uucp: uunet!decwrl!klee
grunwald@foobar.colorado.edu (Dirk Grunwald) (10/03/89)
In article <1880@bacchus.dec.com> klee@gilroy.pa.dec.com (Ken Lee) writes: Newsgroups: comp.unix.ultrix Date: 2 Oct 89 22:41:22 GMT Sender: news@decwrl.dec.com Organization: DEC Western Software Laboratory In article <4327@buengc.BU.EDU>, bph@buengc.BU.EDU (Blair P. Houghton) writes: > A few hours after starting up the xcons (by putting the proper line > in /etc/ttys and doing kill -HUP 1), the console-display's X server > (Xqdsg) locks up. Note that the xcons and xterm -L stuff will be removed from X11R4 by MIT. At best, it's kind of flakey. Try using xdm or dxsession instead. Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@decwrl.dec.com uucp: uunet!decwrl!klee ---- How does XDM solve the problem? It doesn't initiate a console-like window, it only prompts for passwords & starts your .xsession. dxsession, on the other hand, *does* capture console output; but w/o source, there's no way to see how this is done. Right now, I use all X11R3 tools except for dxsession, precisely because dxsession captures all console output. Kind of stiff cost, though. Dirk Grunwald -- Univ. of Colorado at Boulder (grunwald@foobar.colorado.edu)
rick@ssbell.UUCP (Richard Ohnemus) (10/03/89)
In article <12315@boulder.Colorado.EDU> grunwald@foobar.colorado.edu writes: >In article <1880@bacchus.dec.com> klee@gilroy.pa.dec.com (Ken Lee) writes: > In article <4327@buengc.BU.EDU>, bph@buengc.BU.EDU (Blair P. Houghton) writes: <<< text from xcons discussion deleted >>> > >How does XDM solve the problem? It doesn't initiate a console-like >window, it only prompts for passwords & starts your .xsession. > >dxsession, on the other hand, *does* capture console output; but w/o >source, there's no way to see how this is done. Right now, I use >all X11R3 tools except for dxsession, precisely because dxsession captures >all console output. Kind of stiff cost, though. > >Dirk Grunwald -- Univ. of Colorado at Boulder (grunwald@foobar.colorado.edu) You can capture all of the console output by opening /dev/xcons and reading from it. I have modified xdm to do this (console output can be ignored or sent to a log file (probably should go to another window on the screen)). I have also written another client that opens a small window and displays the console output. This client is started by xdm when a logon is successful. The client runs the session file instead of xdm so you get the added advantage that stdout and stderr are also displayed in the window instead of going into the bit bucket. I can send this code to any one that wants it. If I get enough requests I'll just post it to alt.sources. -- I never receive credit for anything I write! (I'm an Ohnemus. 8-) Rick Ohnemus UUCP: rick@ssbell Sterling Software FSG/IMD INTERNET: rick@ssbell.uu.net 1404 Ft. Crook Rd. South Phone: (402) 291-8300 Bellevue, NE. 68005-2969 FAX: (402) 291-4362
garyf@mehlville.ncsa.uiuc.EDU (Gary Faulkner) (10/04/89)
In article <1880@bacchus.dec.com>, klee@gilroy.pa.dec.com (Ken Lee) writes: > Note that the xcons and xterm -L stuff will be removed from X11R4 by > MIT. At best, it's kind of flakey. Try using xdm or dxsession > instead. Ok, I know that dxsession solves the problem which xcons is attempting to solve, but does xdm do that also (dxsession is rather large, and I had problems with using it and xterm together)? Thanks > > Ken Lee > DEC Western Software Laboratory, Palo Alto, Calif. > Internet: klee@decwrl.dec.com > uucp: uunet!decwrl!klee Gary Faulkner National Center for Supercomputing Applications - University of Illinois Internet: garyf@mehlville.ncsa.uiuc.edu Disclaimer: I've only stated my opinion, not anyone elses.