Bring up Reno

Chris Torek torek at elf.ee.lbl.gov
Sat Apr 13 03:25:07 AEST 1991


In article <2032 at tharr.UUCP> jhma at tharr.UUCP (James Aldridge) writes:
>The Major problem I have had installing 4.3BSD-Reno on our 11/750 is that it
>doesn't recognise our tape drive when using the supplied kernels.  We have an
>Emulex TC12 (ts11 compatible) tape controller which has worked quite happily
>under all previous 4.x BSD releases.  4.3 Reno, recognises that there is some
>sort of controller present but complains that "zs0: didn't interrupt".

I wrote this code.  It worked fine on my VAXen at Maryland (which had
Dilog `DEC' controllers and Emulex TC13s) and apparently works on a
real DEC TS11 controller at Berkeley, but you are not the first one to
report this.  I cannot explain it---the code obeys all the rules in the
Emulex manual.  If I had some time with a system with this problem I
could no doubt fix it (and maybe this explains why the original driver
author thought it was `too hard' to make it interrupt).

There is a `quick fix': in tsprobe(), just before

	if (cvec == 0 || cvec == 0x200)	/* no interrupt */
		ubarelse(numuba, &a);

add

	if (cvec == 0x200 && ctlr == 0) {
		/*
		 * No interrupt, assume standard vector		XXX
		 * (need to find out why this happens)
		 */
		cvec = 0224;
		br = 0x15;
	}

This will only support ts0; if you prefer you can make it:

	if (cvec == 0x200) {
		/*
		 * No interrupt, assume standard vector		XXX
		 * (need to find out why this happens)
		 */
		cvec = (unsigned)reg & 7 ? 0260 : 0224;
		br = 0x15;
	}

(which then makes the following test for 0x200 fail, so it could be
removed).  This will make the code act as before except when the
probe succeeds (then the code will use the real interrupt vector).

The 4.3reno code is older than the stuff I have now, which just uses
TS_IE|TS_SETCHR (no TS_SENSE) and allows up to 2 minutes for the
interrupt (in case the controller is busy with a rewind), but this did
not fix the problem on the other system on which it was reported.  If
you are in the SF Bay area and have a machine with this problem, and
will let me experiment, send me mail....
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek at ee.lbl.gov



More information about the Comp.bugs.4bsd.ucb-fixes mailing list