Need help: 3Com Ethernet Board with ULTIRX 1.2
Paul Marsh
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
HOWARD HANTMAN
> 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