Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.bugs.4bsd,comp.unix.wizards Subject: Re: Cant access disks on second UDA50 Message-ID: <7593@mimsy.UUCP> Date: Sat, 18-Jul-87 16:34:43 EDT Article-I.D.: mimsy.7593 Posted: Sat Jul 18 16:34:43 1987 Date-Received: Sun, 19-Jul-87 01:28:18 EDT References: <6683@dartvax.UUCP> <441@eplrx7.UUCP> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 67 Keywords: unibus uda50 Xref: mnetor comp.bugs.4bsd:456 comp.unix.wizards:3303 >In article <6683@dartvax.UUCP> steve@dartvax.UUCP (Steve Campbell) writes: >>controller uda0 at uba0 csr 0172150 vector udintr >>disk ra0 at uda0 drive 0 >>disk ra1 at uda0 drive 1 >>controller uda1 at uba0 csr 0172550 vector udintr >>disk ra2 at uda1 drive 2 >>disk ra3 at uda1 drive 3 In article <441@eplrx7.UUCP> lad@eplrx7.UUCP (Lawrence Dziegielewski) writes: >... I suspect that it's you config that may be wrong. Nope. >Each uda can support 4 devices, This is true. There are only four places to attach drives to the controller. To make the quoted statement comprehensive, add the words `up to' between `support' and `4'. >and you have to (or should) tell config about them. Nay, not so. >In your configuration, you're asking unix to find ra2 on uda1 drive 2. >This is not logically possible. It most certainly is. The requirements are that no Unix-name (raN) can map to the same drive, or in MSCP parlance, unit[*], number on the same uda50 controller. ra0 can be unit 2 on uda1, ra1 unit 7 on uda3, ra2 unit 0 on uda0, and so forth. ----- [*This is a rather unfortunate term, as Unix uses `unit' to mean the number after the word `ra'. E.g., `ra1' is Unix unit 1, though it may be MSCP unit 7: `ra1 at uda3 drive 7'.] >... I also use the secondary uda address of 0160334 in the MVaxes >floating address space. The UDA50A's csr address is set by switches on one of the two boards. If your configuration matches your switches, you are in good shape. Even if not, some fancy footwork in autoconf can sometimes save the day. The `standard' set of UDA50 addresses is 0772150, 0772550, and 0777550 (0772150 is the same as 0172150 due to the funny Unibus mapping). What makes Steve's problem particularly perplexing is that everything works at least a little bit. The machine finds the controllers and drives, and can talk to them a bit, e.g., with raw I/O. Raw transfers do not really work the I/O system very hard, though, so I suspect some sort of hardware glitch with `simultaneous' transfers. (My first suggestion, of course, was to try my driver....) Incidentally, for those running the driver I posted in April, I may soon be posting some patches. In particular, the code should now work on Microvax IIs, although without a small patch to ubainit() the crash dump code will continue to fail just like the 4.3 driver. There is a bug fix relating to disk profiling (dk_busy is cleared too soon) and another dealing with Unibus resets (I am not sure of the presence of the bug, but I had to rewrite that section of code anyway for a KDB50 driver). I have no Microvax handy for testing as yet, and I have other things I must do first, so just consider this a teaser. :-) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris