login problem.

Reinhard Doelz doelz at urz.unibas.ch
Thu Mar 1 18:30:13 AEST 1990


GREAT. I was reporting this problem to SGI in fall 1989, and they (ISO)
told me thatothers encounter the same problem. I hacked a workaround
which temporarily fixes the problem, because even 3.2.1. didn't fix it. 
The following is a repost of a message I sent to INFO-IRIS in december.
Hope this helps...

Reinhard 

===========================================

We are running a 120GTX OS 3.2.1.
The program shown below runs on two processors. 
The graphics manager fails to start up and the graphics is unusable (No 
window manager).

*DOCUMENTATION:*
The /usr/adm/SYSLOG says  (truncated, only significant lines shown)

Dec  7 09:17:00 modl grcond[290]: CIO: IRIX System V Release 3.2
                                 IP5 Version 10171414
Dec  7 09:17:00 modl grcond[290]: CIO: CPU 1 taking over time and accounting 
                                  functions
Dec  7 09:17:00 modl grcond[290]: CIO: gfx_wait_cx:  context switch timed out
Dec  7 09:17:00 modl grcond[290]: CIO:
Dec  7 09:17:00 modl grcond[290]: CIO: gm-2 (configured for IP5) 1.14+
Dec  7 09:17:00 modl grcond[290]: CIO:
Dec  7 09:17:00 modl grcond[290]: CIO: DEBUG_NOISE at 0x9806648C
Dec  7 09:17:00 modl grcond[290]: CIO: Loading PP ucode Version:  
                                  @(#) PEAPOD 1.2 pp microcode assembler 
                                  - 6/20/87
Dec  7 09:17:00 modl grcond[290]: CIO: Sat Aug 19 19:10:21 1989 
                                  user unknown revision(1.123CLOVER2IP5GT)
Dec  7 09:17:00 modl grcond[290]: CIO: 

tried and failed ... as reported.

... and therefore I conclude that the grcond is unable to start up. 

*WORKAROUND:*
The IRIS is fully networked running nfs, 4DDN and TCP/IP thus eventually 
suffering from this. Therefore, I changed the kernel in /usr/sysgen/master.d
to read the network on CPU0 as follows: 

107c107
< #define NBUF 100              /* # buffers in disk buffer cache */
---
> #define NBUF 400              /* # buffers in disk buffer cache */
215c215
< #define MAXSC 26
---
> #define MAXSC 30
353c353
< int           network_processor = 1;
---
> int           network_processor = 0;
modl [/usr/sysgen/master.d] %

... did an lboot and problem solved. 

*PROBLEM REPRODUCTION:*
The fortran program causing the problem is a special application. However, 
a C program will do it as well. The following is a dummy routine which 
performs the crashes: 

        real x(100,1000), y(100,1000)
        seed=123456
        do 100 i=1,100
                do 101 ii=1,1000
                        x(ii,i)=rand(seed)
101                     continue
100             continue
        write (6,*)'ran done'
        do 200 i=1,100
                do 201 ii=1,1000
                        y(ii,i)=sin(x(ii,i))*cos(x(ii,i))
                        y(ii,i)=
     *                  (y(ii,i)**1.003)**(1-(sin(x(ii,i))/1000))
                        do 202 iii=1,900
                                y(ii,i)=
     *                          y(ii,i)**(1-(sin(x(ii,i))/1000))
202                             continue
201                     continue
200             continue
        stop
        end

pfa concurrentizes the 200 do loop which gives a fully paralelly running 
program. 

*ALTERNATIVE WORKAROUND:*
In order to avoid the kernel modification you could also log in from 
another (not the console) terminal, or even log in as root NOGRAPHICS, 
call the debugger saying dbx -p # ( # being the parallel job) which is 
equivalent to sending a schedctl call to this process. One could 
do it more elegantly by using a small C routine but I didn't bother about 
that. 

  
  ************************************************************************
  *   Dr. Reinhard Doelz           *           SWITZERLAND               *
  *     Biocomputing               *                                     *
  *      Biozentrum                * doelz%urz.unibas.ch at relay.cs.net    *
  * Klingelbergstrasse 70          *                                     *
  *     CH-4056 Basel              *                                     *
  ************************************************************************



More information about the Comp.sys.sgi mailing list