| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3225.1 | | JAMIN::OSMAN | Eric Osman, dtn 226-7122 | Mon Jan 27 1997 11:49 | 12 |
|
Which wxserver (version number and date stamp) as shown in the about box,
are you seeing this on ? What transport for your dxsession.
Oh, are you starting dxsession as a regular x client, or via xdmcp ? If
xdmcp, I know we fixed a problem in that area within last two weeks, so
you'll need the EFT2B(+?) field test to include that.
But if you're starting dxsession as a regular x client, then this may
be a new problem.
/Eric
|
| 3225.2 | Additional Information | FLYWAY::WALKERN | Skiing Skippy... | Tue Jan 28 1997 06:01 | 24 |
| Hi,
Here are a few answers.
>> Which wxserver (version number and date stamp) as shown in the about box,
>> are you seeing this on ? What transport for your dxsession.
T3.0.551 (Intel)
Jan 8 1997, 22:57:21
>> Oh, are you starting dxsession as a regular x client, or via xdmcp ? If
>> xdmcp, I know we fixed a problem in that area within last two weeks, so
>> you'll need the EFT2B(+?) field test to include that.
I have the "Enable XDMCP" box empty in the control panel - I guess this is what
you mean.
Hope this helps,
Regards,
Nick
|
| 3225.3 | Unix 4.0 is OK | FLYWAY::WALKERN | Skiing Skippy... | Wed Jan 29 1997 05:01 | 12 |
| Hi,
Something else I just noticed - I started the session manager from a Unix 4.0B
system, and the problem is non-existent!
The system I am experiencing the problem on is running Unix 3.2D-1 - is it
possible that the problem lies in the version of Motif, or some sort of setup
on the server, rather than on the client?
Regards.
Nick
|
| 3225.4 | | JAMIN::OSMAN | Eric Osman, dtn 226-7122 | Wed Jan 29 1997 10:12 | 23 |
|
I successfully ran dxsession from Digital unix 4.0 yesterday.
Actually, first it failed with
Major opcode of failed request: 109 (X_ChangeHosts)
Minor opcode of failed request: 0
Resource id in failed request: 0x16
Serial number of failed request: 131
Current serial number in output stream: 135
But this seems to be related to some new-style decnet node name in the
security list of that session manager. A strange workaround for that particular
problem was to turn on xdmcp in excursion control panel for that node (which
should have nothing to do with it!). You might try that. (I tried both
indirect and query).
Another thing you might try is turning on excursion logging to window, plus go
into the excursion menu and turn on "protocol request logging". See if
you can tell what requests (oh, turn on "protocol event logging" too in case
it's those) are clogging things up. That might shed light.
/Eric
|
| 3225.5 | Problem in .Xdefaults fixed | FLYWAY::WALKERN | Skiing Skippy... | Wed Jan 29 1997 10:43 | 14 |
| Hi,
I solved it myself!!
There is (was) a line in my .Xdefaults file that needed removing - afterwards,
everything is ok.
DXsession.screen_saver_enable: disable
Does anyone have an idea what the problem here could be?
Regards,
Nick
|
| 3225.6 | | PEACHS::GHEFF | Got a head with wings | Wed Jan 29 1997 11:34 | 3 |
| Yipes. eXcursion has traditionally ignored the X screensaver.
#Gary
|
| 3225.7 | WXSERVER using 100% CPU but Client is a VMS system | SSDEVO::MORGAN | Brad Morgan, DTN 522-3449 | Thu Apr 17 1997 14:31 | 6 |
| I've got the same problem, 100% of the AlphaStation CPU being consumed
by WXSERVER. In this case, the client machine is a VAX/VMS system. The
only X applications running are a session manager and 5 decterms. Killing
all the X applications doesn't help.
The server is V3.0.554(Alpha) Jan 23, 1997, 14:55:04
|
| 3225.8 | Solved it myself... | SSDEVO::MORGAN | Brad Morgan, DTN 522-3449 | Thu Apr 17 1997 14:33 | 7 |
| The solution is similar on the VMS side...Don't disable the screen saver
(in Options, Screen Background).
Strange thing is that I've never seen the "enabled" screen saver kick in
on my system!
Brad
|