marsh@umt.UUCP (Paul Marsh) (09/10/86)
We recently installed Ultrix 1.2 on our VAX 785, which was running 4.2bsd. After changing autoconf.c to look at non-mass storage peripherals before looking at mass storage peripherials, we booted the new kernel and got the following errors: ecprobe: cannot reserve uba addresses uda0 at uba0 csr 172150 vec 4, ipl 15 failed to initialize step3: sa fffa4a0uda500 failed to init failed to initialize step3: sa fffa4a0uda500 failed to init mba0 at address 0x20010000 mt0 at mba0 drive 0 mu0 at mt0 slave 0 panic: iinit The ecprobe message is generated after a failed call to the routine ubamem. The 4.2 code and the Ultrix code appear to be basically the same. Can anyone tell me what might have changed with Ultrix to cause this to break? Any ideas will be very much appreciated. Thanks in advance. -- UUCP : ... ! ucbvax ! ucdavis ! umt ! marsh US Mail : Paul Marsh, University of Montana, Computer Center Missoula, MT 59812 phone : (406) 243-5455
hlh@raybed2.UUCP (HOWARD HANTMAN) (10/02/86)
> We recently installed Ultrix 1.2 on our VAX 785, which was running 4.2bsd. > After changing autoconf.c to look at non-mass storage peripherals before > looking at mass storage peripherials, we booted the new kernel and got the > following errors: > > ecprobe: cannot reserve uba addresses > uda0 at uba0 csr 172150 vec 4, ipl 15 > failed to initialize step3: sa fffa4a0uda500 failed to init > failed to initialize step3: sa fffa4a0uda500 failed to init > mba0 at address 0x20010000 > mt0 at mba0 drive 0 > mu0 at mt0 slave 0 > panic: iinit > > The ecprobe message is generated after a failed call to the routine ubamem. > The 4.2 code and the Ultrix code appear to be basically the same. Can anyone > tell me what might have changed with Ultrix to cause this to break? We upgraded to from Ultrix1.1 to Ultrix1.2 and encountered the same problem. After a good deal of hunting we found that while it is true that the ubamem routines had not changed, some of the other bus setup routines had. As a result, even before the first device attempts to reserve bus addresses, the first three addresses have been taken for temporary use. Since if_ec.c attempts to save addresses starting at 1 (as explained below) the call to ubamem fails. By changing the #define for ECMEM (initially 0000000) you can avoid this. This definition must, of course, match the memory switch settings on the board. Since only switches 15-17 are settable on the board the address must be a multiple of 0100000 octal (decimal 32768). The address allocated is calculated by shifting the address right 9 bits and adding 1; hence allocation will be at multiples of 0100 (64 dec) plus 1. The unibus map addresses only go to 760 octal (496 dec), and 100 oct (64 dec) addresses are required for the board, making the possible board memory addresses and corresponding map addresses are as follows: Memory address Start of map allocation Oct Dec Oct Dec 0100000 32768 0101 65 0200000 65536 0201 129 0300000 98304 0301 193 0400000 131072 0401 257 0500000 163840 0501 321 0600000 196608 0601 385 Depending upon what other boards you have that request a specific address you can make a choice from the above. Most boards do not request addresses this way, rather they ask for temporary space which is assigned wherever it is free. Make sure your ECMEM has a leading zero if you're defining it in octal or the results will clearly be undesireable. To be fair, I must admit that after the fix we did experience problems with one of our DMA devices and were unable to continue using the 3com board. The other board would time out on its DMA transfers apparently due to the 3com's high ipl and interrupt rate. The board combination had worked OK under 1.1. Since both the 3com and the other board were non-DEC support was not forthcoming. With the "normal" array of devices, however, the fix should prove useful. Howard Hantman System Software Engineer Raytheon Co., MSD ...linus!raybed2!hlh