4.3 tm.c problems/questions

[Richard Stevens]

We have found a problem with the 4.3 tm.c driver (TM11/TE10)
that we're using with an Emulex TC11 controller with 2 Kennedy
9300 tape drives.  (This problem also exists in the 4.2
driver, but we never tried tracking it down until now.)
The problem occurs if you are using both drives and close
one drive, and immediately try to open the same drive again.
(We have a program that writes a tape, closes the drive, opens
it again, and reads the entire tape back for verification.)
The drive that's closed will start rewinding, return to the caller,
who then executes the next open, which will wait in the driver's open
routine, waiting for the "settle down" bit to go off.  When the
"settle down" bit goes off, the driver tests the status for BOTH
SELR (select remote) and TUR (tape unit ready).  If the second
drive is not in use, both bits are on, the tests succeeds and the
open is performed.  However, if the second drive is in use, only
the SELR bit is on, and the driver prints "not online" and the open
fails.

I changed the line in the driver from:

	if ((sc->sc_erreg&(TMER_SELR|TMER_TUR)) != (TMER_SELR|TMER_TUR)) {
		uprintf("te%d: not online\n", teunit);
		return (EIO);
	}

to:

	if ((sc->sc_erreg & (TMER_SELR | TMER_TUR)) == 0) {
		uprintf("te%d: not online, er=%x\n", teunit, sc->sc_erreg);
		return (EIO);
	}

The Emulex TC11 manual says the SELR bit not being on means "the addressed
unit does not exist, the unit is off-line, or the unit is powered off",
so I figured the bit being on is a pretty good indication that the
drive is ready.  This fix does work, in that the next operation
performed on the open'ed drive is done correctly.

However, this appears to be a workaround-hack and not the real solution.
Has anyone seen this problem before ?  This workaround does have the
problem that not only is the TUR bit not on, but the BOT bit is also not
on, so if you're changing density on the tape drive, the open will
fail with the "can't change density in the middle of a tape" error.
The code that gets the drive's status bits (the SENSE operation)
appears to be correct, in that it looks like its addressing the
correct drive, and storing the registers in the per-drive structure,
so having the other drive doing something else shouldn't matter.

Any ideas ??

	Richard Stevens
	Health Systems International, New Haven, CT
           ihnp4 ! hsi ! stevens