Help needed: 3Com Ethernet Controll

[Steven Bellovin]

...

> The 3com board has dual-ported Unibus memory instead of a DMA transfer
> mechanism for the host to access received and transmitted data.  For the
> Vax 780 family to use this memory, it must disable the Unibus map registers
> for the Unibus address range that covers the memory.  Due to the design 
> of the Unibus map (at least on the 780), you only can disable a consecutive
> block of Unibus map registers starting at Unibus address 0 and going up.
> Hence the requirement that the 3com memory be set to address 0.

Not quite.  There's really no reason to disable the UBA map registers for
the desired range; if no one references those addresses, there's no harm
in having them enabled.  The real problem is that the 4.2 code has no
way to specify a different address for the 3Com board's UNIBUS memory, so
it always sticks it at zero.  An undocumented side effect of this, incidentally,
is that you can only have on 3Com board per UBA unless you hack the driver.
And since the unit number isn't passed to the probe routine, that's difficult
to do in any clean fashion.  (Unclean methods need not apply; I know several
of them....)

> But if another device requests dedicated access to the Unibus ahead of the
> 3com in the autoconfigure sequence (as I suspect the ra disks do for faster
> UBA access), addresses from 0 to some number will be marked in use, and
> when it comes time to disable the map and allocate the memory window,
> the Unibus management routines will complain because it cannot get the
> exact address range needed for the 3com board.

It's not so much "dedicated access"; rather, they allocate a chunk of UBA
map space, which just happens to be at the front -- i.e., location 0, just
what the 3Com board wants.  They're supposed to release the space, but not
all drivers do; in particular, some versions of the uda driver do not.

> The Fix?  Put the "device ec0 ..." entry *before* any other unibus devices
> in your configuration file, rebuild the kernel, and try it.  Devices are
> probed and attached in the order they appear in the configuration file.

That's a good idea; however, standard 4.2bsd probes all disk drivers first.
If it is the ra81 (and that's the most likely answer), you'll have to rearrange
the code in autoconf to probe the non-disks first.

		--Steve Bellovin