richards@uiucdcsb.CS.UIUC.EDU (02/25/86)
It looks like your configuration of the board is correct, but I suspect
that one of your other Unibus drivers are requesting a dedicated part
of the Unibus Map before the 3com board is initialized, preventing it
from properly acquiring the lowest part of the Unibus address space.
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.
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.
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.
Paul Richards University of Illinois at Urbana-Champaign, Dept of Comp Sci
UUCP: {pur-ee,convex,inhp4}!uiucdcs!richards
ARPA: richards@b.cs.uiuc.edu
CSNET: richards%uiuc@csnet-relay
MABELL: (217) 333-3536grandi@noao.UUCP (Steve Grandi) (02/26/86)
In article <14900042@uiucdcsb> richards@uiucdcsb.CS.UIUC.EDU writes: > >It looks like your configuration of the board is correct, but I suspect >that one of your other Unibus drivers are requesting a dedicated part >of the Unibus Map before the 3com board is initialized, preventing it >from properly acquiring the lowest part of the Unibus address space. > >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. > Unfortunately, all CONTROLLERS are probed before any DEVICES so the UDA-50/RA driver will still get in and grab the Unibus memory first. It is a simple hack to autoconf.c to reverse this order so all devices get probed first; I had to do this for one of my 750s with a UDA-50 and a 3-Com card on the same Unibus when I switched to the RIACS UDA driver. -- Steve Grandi, National Optical Astronomy Observatories, Tucson, AZ, 602-325-9228 {arizona,decvax,hao,ihnp4,seismo}!noao!grandi grandi%draco@Hamlet.Caltech.Edu
smb@ulysses.UUCP (Steven Bellovin) (02/27/86)
... > 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