Two weeks ago I asked :
> Is it possible to put more than 2 (we need 4 and we have spare ones) Ethernet
> controllers in a 3/180 ?
Curt Freeland <curt@ecn.purdue.edu> sent me the Sun-Spots Digest, v6n223 from
slevy@uf.msc.umn.edu (Stuart Levy) on 10 Sep 88 20:11:29 GMT, which I'll append.
It says : If you have kernel sources (we don't :-( ), it's easy, if not, it is
still possible with sort of mayor adb hacking.
All others, namely
Charles.Grady@eng.auburn.edu
aahvdl@eye.psych.umn.edu
poffen@sj.ate.slb.com
miker@sbcoc.com
birger@vest.sdata.no
siegl@tunamea.tuwien.ac.at
datri@lovecraft.convex.com
johnl@microware.com
suggest either to divide the problem to more than a single machine (which we do
at the moment) or to use a "real" router like CISCO. Well, I'd love to do that
but there is a problem which originally caused me to ask the question.
I am responsible only for true computers in our network, starting at the AUI port
of the machines. The responsibility and exclusive maintenance of network hardware
like cables, bridges and true routers lies in the not very skilful hands of our
local computing center. They wouldn't give me a login on a CISCO, and it would
SNM report to them, not to me. So in case of problems, we would fully rely upon
their having time and knowlegde, which we would better not.
My conclusion is to leave the network topology as it is for the moment and perhaps
to try the adb hacking on a weekend.
Thanks a lot, though.
/|
/ | Eckhard R"uggeberg
/ | DLR G"ottingen
_____/___|_____ Abt. SM-TS
/ / / / Bunsenstr. 10
/ / / /
/____/____/____/ 3400 G"ottingen / Germany
| /
| / Tel. : 0551/709-2429
| / Fax : 0551/709-2446
|/ E-Mail : Eckhard.Rueggeberg@ts.go.dlr.de
Niulize nitakujibu
*************************************************************
Subject: Sun-Spots Digest, v6n223
Date: 10 Sep 88 20:11:29 GMT
SUN-SPOTS DIGEST Friday, 9 September 1988 Volume 6 : Issue 223
...
Date: Thu, 8 Sep 88 10:02:43 CDT
From: slevy@uf.msc.umn.edu (Stuart Levy)
Subject: How to put lots of Ethernet controllers on your Sun
There are two reasons you can't do it immediately: Sun doesn't tell you
the necessary switch settings, and the supplied OBJ/if_ie.o is compile for
NIE = 2.
Here's how we configure extra Ethernet cards. The following slice of
config file should be self-explanatory if you also read the Sun Hardware
Installation Manual's instructions on adding a second (ie1) Ethernet. The
addresses shown here are somewhat arbitrary; they were chosen not to
overlap each other nor any other device we had. These are just the
combinations we've tried. Though we've run cards with each of these
switch settings, and though I had no reason to stop at ie6 except that it
filled an 80-char line, we've only actually operated 4 extra cards
(ie1..4) at once.
#
# ie controller & VME-Multibus adapter switch settings:
# ie1 is as described in the Sun Hardware Installation Manual.
# Switches which change on other cards are:
# ie U503 sw 1-8 -- addr (A12-19) of 16K block of regs within Multibus space
# ie U505 sw 1-4 -- addr (A12-15) of block of buffer RAM within Multibus space
# ie U506 sw 1-8 -- size of buffer RAM (64K, 128K, or 256K, in strange code)
# adap DIP 7 sw 1-8 -- addr (A23-16) of Multibus space within 16M VME space
# adap DIP 8 sw 1-8 -- size (A23-16) of Multibus space
# adap DIP 12 sw 1-8 -- interrupt vector (bits 0-7)
#
# Sun sets ie1's interrupt vector to 1b (68000 generic level 3 interrupt)
# rather than 75 (as listed in the config file), God knows why. 75 works too.
#
# Switches: x = off O = on
#
# U506 codes: 256K=xOOxxOOx 128K=(forgot) 64K=OxxOOxxO (switch order 1-8)
# All presently set at 256K.
#
# Controller ie1 ie2 ie3 ie4 ie5 ie6
#------------------- -------- -------- -------- -------- -------- --------
#Multibus space size 0x100000 0x080000 0x080000 0x080000 0x080000 0x080000
#Adaptor DIP 8 sw1-8 OOOOxxxx OOOOOxxx OOOOOxxx OOOOOxxx OOOOOxxx OOOOOxxx
#
#Multibus space addr 0xE00000 0xC80000 0xC00000 0xB80000 0xB00000 0xA80000
#Adaptor DIP 7 sw1-8 xxxOxxxx xxOOxxxx xxOOOxxx xOxxxxxx xOxxOxxx xOxOxxxx
#
#interrupt vector 0x1B 0x76 0x77 0x78 0x79 0x7A
#Adaptor DIP12 sw1-8 xxOxxOOO OxxOxxxO xxxOxxxO OOOxxxxO xOOxxxxO OxOxxxxO
#
#ie registers addr 0xE88000 0xC88000 0xC08000 0xB88000 0xB08000 0xA88000
#ie ctrlr U503 sw1-8 xxxOxxxO xxxOxxxO xxxOxxxx xxxOxxxO xxxOxxxx xxxOxxxO
#
#ie RAM addr 0xE40000 0xCC0000 0xC40000 0xBC0000 0xB40000 0xAC0000
#ie ctrlr U505 sw1-4 xxOx xxOO xxOx xxOO xxOx xxOO
#
device ie0 at obio ? csr 0xc0000 priority 3
device ie1 at vme24d16 ? csr 0xe88000 priority 3 vector ieintr 0x75
device ie2 at vme24d16 ? csr 0xc88000 priority 3 vector ieintr 0x76
device ie3 at vme24d16 ? csr 0xc08000 priority 3 vector ieintr 0x77
device ie4 at vme24d16 ? csr 0xb88000 priority 3 vector ieintr 0x78
device ie5 at vme24d16 ? csr 0xb08000 priority 3 vector ieintr 0x79
device ie6 at vme24d16 ? csr 0xa88000 priority 3 vector ieintr 0x7a
The other part is coming up with if_ie.o willing to handle lots of ie's.
If you have source this is easy, just recompile. If you don't it may
still be possible as follows (though I haven't tried this).
If_ie.o contains six uninitialized arrays whose sizes are proportional to
NIE. Since they're uninitialized, they appear in the .o file as "common"
areas defined only by their size. So the ambitious adb'er could just
change their sizes by the factor {desired_NIE}/{old_NIE}, where old_NIE = 2.
The tables are
00000640 C _iepgmap
00000008 C _ieinfo
000004d0 C _ie_softc
00000640 C _iecbmap
00000640 C _iememmap
Also there are two NIE references in the code which need to change. Right
at the beginning of iereset(), its parameter is compared to NIE. And at
the beginning of iepoll() is a loop over ie_softc using a pointer and
ceasing at &ie_softc[NIE]; so the .o file appears to compare a pointer to
the size of ie_softc, i.e. initially 0x4d0. Beware that optimization may
have moved that test to the end of the routine. Don't ask me if you want
to undertake this -- you're on your own.
Stuart Levy, Minnesota Supercomputer Center
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:43 CDT