[ On Sunday, December 3, 2000 at 22:30:56 (-0800), Greywolf wrote: ]
> Subject: EXB-4200c, the continuing saga...
>
> Is it just me, or does it seem odd to anyone else that a MTIOCGET call
> [working from memory; forgive me if that's off a tad] would return
> ENODEV due to missing media?  My EXB-8200 doesn't do that.

I just realised that I have an EXB-4200 attached to a customer's
SPARC-20 clone:

NetBSD 1.5F (GENERIC) #0: Sun Dec  3 19:09:31 EST 2000
    woods@sometimes:/work/NetBSD-obj.sparc/sys/arch/sparc/compile/GENERIC
total memory = 383 MB
avail memory = 351 MB
using 896 buffers containing 19724 KB of memory
bootpath: /iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f,800000/sd@0,0
mainbus0 (root): SUNW,Axil-320
cpu0 at mainbus0: TMS390Z50 v0 or TMS390Z55 @ 75 MHz, on-chip FPU
cpu0: physical 20K instruction (64 b/l), 16K data (32 b/l), 1024K external (32 b/l): cache enabled
obio0 at mainbus0
clock0 at obio0 slot 0 offset 0x200000: mk48t08 (eeprom)
timer0 at obio0 slot 0 offset 0x300000 delay constant 35
zs0 at obio0 slot 0 offset 0x100000 level 12 softpri 6
zstty0 at zs0 channel 0 (console i/o)
zstty1 at zs0 channel 1
zs1 at obio0 slot 0 offset 0x0 level 12 softpri 6
kbd0 at zs1 channel 0
ms0 at zs1 channel 1
fdc0 at obio0 slot 0 offset 0x700000 level 11 softpri 4: chip 82077
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
auxreg0 at obio0 slot 0 offset 0x800000
power0 at obio0 slot 0 offset 0xa01000 level 2
iommu0 at mainbus0 ioaddr 0xe0000000: version 0x1/0x1, page-size 4096, range 64MB
sbus0 at iommu0: clock = 25 MHz
dma0 at sbus0 slot 15 offset 0x400000: rev 2
esp0 at dma0 slot 15 offset 0x800000 level 4: ESP200, 40MHz, SCSI ID 7
scsibus0 at esp0: 8 targets, 8 luns per target
ledma0 at sbus0 slot 15 offset 0x400010: rev 2
le0 at ledma0 slot 15 offset 0xc00000 level 6: address 00:00:3b:80:3c:56
le0: 8 receive buffers, 2 transmit buffers
bpp0 at sbus0 slot 15 offset 0x4800000 level 2 (ipl 3): rev 2
SUNW,DBRIe at sbus0 slot 15 offset 0x8010000 level 9 not configured
eccmemctl0 at mainbus0: version 0x1/0x1
scsibus0: waiting 2 seconds for devices to settle...
probe(esp0:0:0): max sync rate 10.00MB/s
probe(esp0:0:0): unrecognized MESSAGE EXTENDED; sending REJECT
sd0 at scsibus0 target 0 lun 0: <WDIGTL, ENTERPRISE, 1.61> SCSI2 0/direct fixed
sd0: 4157 MB, 5720 cyl, 8 head, 186 sec, 512 bytes/sect x 8515173 sectors
probe(esp0:1:0): max sync rate 10.00MB/s
sd1 at scsibus0 target 1 lun 0: <SEAGATE, ST32430N, 0510> SCSI2 0/direct fixed
sd1: 2049 MB, 3992 cyl, 9 head, 116 sec, 512 bytes/sect x 4197405 sectors
st0 at scsibus0 target 4 lun 0: <EXABYTE, EXB-4200, 216> SCSI2 1/sequential removable
st0: density code 19, 512-byte blocks, write-enabled
probe(esp0:6:0): max sync rate 4.03MB/s
cd0 at scsibus0 target 6 lun 0: <PLEXTOR, CD-ROM PX-4XCH, 1.23> SCSI2 5/cdrom removable
root on sd0a dumps on sd0b
root file system type: ffs


This drive is incredibly finicky (and it behaved in much the same manner
under SunOS-4.1.4 too).  It will reject a perfectly good tape nine times
out of ten, and it takes forever to get ready (as do most modern
helical-scan tape drives).  It doesn't physically eject a tape with
"eject st0", though it does go off-line.

It works fine when a tape's loaded.

	# mt status 
	SCSI tape drive, residual=0
	ds=3<Mounted>
	er=0
	blocksize: 0 (0, 0, 0, 0)
	density: 19 (0, 0, 0, 0)
	current file number: 0
	current block number: 0

When there's no tape loaded 'mt status' gets an EIO from /dev/nrst0:

	# mt status
	mt: /dev/nrst0: Input/output error

even if you use the control mode device:

	# mt -f /dev/erst0 status
	mt: /dev/erst0: Input/output error

Scsictl has similar problems with no tape present:

	# scsictl /dev/erst0 identify
	scsictl: /dev/erst0: Input/output error

but it works OK when a tape is loaded:

	# scsictl /dev/nrst0 identify 
	/dev/nrst0: scsibus0 target 4 lun 0 <EXABYTE, EXB-4200, 216>

These errors are, of course, incredibly bogus, but that seems to be the
state of the scsi tape driver in NetBSD (better than some, but still not
"production quality").  The same errors happen with my Eliant-820 drive
(though it's much better behaved in terms of media handling).

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>