Hello Managers,
I've finally solve my problem where CDE logins stalled when the Gigabit
Ethernet interface was up. Thanks a lot to Joe Fletcher who sent me the
following email:
[Joe Fletcher's email]
> I've got an ES40 running it's networking over a gigabit interface.
> Things to try if you haven't done them already. Get the 4.0F patch kits:
> there are some DEGPA specific patches in there. Disable autonegotiation
> (see man alt for details). You might even try getting the card swapped out.
> In my case I think the firmware update on the ES40 was what finally fixed
> it but I'd been through the above list anyway so it's probably a
> combination of two or more components.
What fixed the problem was merely patching the OS with the DEGPA
specific patch on the patch kit. Joe also suggested on a seperate email
to flush the routing tables, but this wasn't necessary in my case.
[update post]
> 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?
[first post]
> > 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.
Thanks everyone,
Kevin
--
Kevin Dea
System Administrator
Alpine Electronics Research of America
Received on Mon Jul 10 2000 - 22:34:34 NZST