Dear alpha managers,
the mysterious problems with our 2100 4/200 that arose when moving from
DU 3.2 to 4.0B are solved (see my original post below)!
The problems came from an intermitting malfunction of the machine's ethernet
adapter (tu0: DECchip 21040-AA: Revision: 2.2).
As the machine has a second network interface communication with some
machines was possible without any problems. However, the gateway of our
subnet was connected over the tu0-interface and therefore the problems with
remote NFS servers. A colleague of mine came across the fault by chance
when he tried to transfer a large amount of data via ftp over the interface
in question. The transfer hung after just a few kBs. In contrast, smaller
transfers even over NFS sometimes worked and no errors showed up in any
log files or during self tests.
As I did not yet contact DEC service we just deactivated the tu0-interface
and do all communication over the second one ... and the machine works
without problems as usually.
Regards,
Gernot
My original post:
>
> Dear alpha managers,
>
> recently we installed Digital Unix 4.0B including the whole set of available
> patches on all our alpha-systems ranging from 3000/300 to 500/400 (all single
> processor systems) with absolutely no problems.
>
> However, the very same installation on our 4-processor 2100 4/200 turned out
> to be completely unusable. Therefore, we decided to do a clean installation
> directly on the system itself without any patches applied and only very
> little local adaptation --- same result.
>
> And that's what happens: The system boots up without any complaint.
> However, NFS-mounts (established by 'amd 5.2.2.2' as NFS3 for systems running
> DU4.0B and NFS2 for other servers such as systems running Solaris) that are
> performed without problems by ALL OTHER of our alpha systems either sometimes
> fail completely (NFS2 server ?? not responding ...) or hang randomly during
> normal operation.
>
> This is especially strange for our installation of X11R6 that comes via NFS
> from different servers (binaries and sharable things separately).
> E.g. a 'xterm' started via NFS ends up in the uniteruptable IO-state 'U' like
>
> 1516 ttyp2 U 0:00.37 xterm
>
> Sometimes such windows show up on the screen around half an hour later(!!!)!
> The local version /usr/bin/X11/xterm seems to have no problems.
>
> The other strange thing is that programs seem to run 2 to 3 times slower
> on the machine running DU 4.0B than on our old configuration using DU 3.2
> (we switched back and forth several times to confirm this fact!).
>
> We made various comparisons between the old 3.2 and the new 4.0B installation
> and did not find anything significantly different that might cause such
> a strange beheaviour. We also browsed through the new release notes of
> the current firmware update versions without finding hints on possible
> anomalies observed on multiprocessor systems.
>
> Did anybody encounter similar effects on a 2100 4/200 or can somebody
> confirm that 4.0B normally should run on such machines without problems?
> We would very much appreciate any help in resolving this strange beheaviour.
>
> Regards,
>
> Gernot
>
--
Dr. Gernot A. Fink Phone: (+49 521) 106-2933; -2935
Universitaet Bielefeld Fax: (+49 521) 106-2992
Technische Fakultaet EMail: gernot_at_techfak.uni-bielefeld.de
Angewandte Informatik SnailMail: Postfach 100131, 33501 BIELEFELD
Received on Fri Oct 24 1997 - 13:10:19 NZDT