Hello Managers,
Thanks to the many people who wrote back with suggestions about my
problem:
Bob Morningstar
Jonathan Burelbach
Ivan Hoe
Peter Stern
Gustavo Avitabile
Joerg Bruehe
...and anyone I missed
The original post is on the bottom. Upon everyone's suggestion I
checked everything including: /etc/hosts, /etc/resolv.conf, loopback
address, .dtprofile. This type of error seems like a common side effect
to changes on the network. But what I found, independently is what was
causing my problem was my startup command to configure our new gigabit
ethernet interface in /sbin/rc3.d/S98gigabit. All I put in it was the
command
ifconfig alt0 10.10.10.2 up
As soon as I removed it and rebooted. I could log in CDE just fine. So
I decided to just use the GUI network configure, which probably does
more than my command does anyways. I just filled out the 10.*.*.* ip,
and it filled the netmask automatically, and it brought the interface
up. I logged and and again, I couldn't log into CDE!!
I guess, I've isolated the problem down to our Gigabit Ethernet. But
how do I get our interface working, and be able to log into CDE? We
have a very similar setup on our DS20, and it is working as smoothly as
it can be. Why is my ES40 being so uncooperative? It has the latest
firmware (flashed about 3 weeks ago) and 4.0F with no patches. When the
Gigabit ethernet is up, it works fine, and transfers data to our DS20.
Any suggestions?
Thanks in advance,
Kevin
[Original Post]
> Hello Managers,
>
> We are experiencing a problem with our ES40 lately. When there is a
> login attempt on the console, it will get to the "Starting the Common
> Desktop Environment" window, with the hourglass cursor, and not do
> anything else. This only occurs with the Regular Desktop Session. The
> failsafe session and dxsession session works fine. When the screen is
> hung, it also produces a number of unusually intensive ttsession
> processes. Here is the ps of what is running after I attemp a console
> login. Note the unusual tcsh process, I haven't seen anthing like this
> on any of our other machines.
>
> # ps aux | grep kdea
> kdea 12679 39.4 0.0 5.10M 248K ?? R 09:29:18 1:16.87
> /usr/dt/bin/ttsession -s
> kdea 12625 0.0 0.0 4.05M 400K ?? I 09:29:18 0:00.02
> /usr/dt/bin/dthello
> kdea 12556 0.0 0.0 2.34M 496K ttyp1 I 09:23:44 0:00.06
> -tcsh (tcsh)
> root 12685 0.0 0.0 1.68M 184K ttyp1 S + 09:32:26 0:00.00
> grep kdea
> kdea 12519 0.0 0.0 2.25M 368K ?? I 09:29:17 0:00.07
> /usr/bin/tcsh -c unsetenv _ PWD; echo '--- not sourcing
> /usr/users/kdea/.login (see /usr/users/kdea/.dtprofile)' >>
> /usr/users/kdea/.dt/startlog; unsetenv DT; /usr/dt/bin/sdtdbcache -init;
> (set path = ( /usr/dt/bin $path ); /usr/dt/bin/ttsession -s ); exec
> /usr/dt/bin/dtsession >&! /dev/null
> kdea 12676 0.0 0.0 5.03M 312K ?? I 09:29:18 0:00.02
> /usr/dt/bin/ttsession -s
>
> If you know what is wrong, but I'm not giving enough information, please
> email me and I'll tell you what you need to know.
--
Kevin Dea
System Administrator
Alpine Electronics Research of America
Received on Mon Jul 10 2000 - 18:39:42 NZST