Date: Tue, 1 Aug 2000 00:02:07 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: scsi@FreeBSD.ORG Subject: Re: Problems using a QUANTUM DLT 7000 Message-ID: <Pine.BSF.4.10.10007312355340.70618-100000@beppo.feral.com> In-Reply-To: <20000731222214.M4854@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 31 Jul 2000, Alfred Perlstein wrote: > I've got a 3.5-stable box here that I just hooked a quantum-dlt-7000 > to. I started getting IO errors after writing about 200 megabytes or > so to it: > > Unexpected busfree. LASTPHASE == 0x0 > SEQADDR == 0x10f > (sa0:ahc0:0:14:0): WRITE FILEMARKS. CDB: 10 0 0 0 2 0 > (sa0:ahc0:0:14:0): ILLEGAL REQUEST asc:3d,0 > (sa0:ahc0:0:14:0): Invalid bits in identify message > (sa0:ahc0:0:14:0): failed to write terminating filemark(s) > (pass1:ahc0:0:14:0): Bus Device Reset Message Sent > ahc0: Bus Device Reset on A:14. 1 SCBs aborted > > Here's my probe messages, anyone work with this stuff and can > give a hint as to what I've messed up? I've seen this before with DLTs- they seem to just go out to lunch. What's happend above is that the DLT dropped the bus unexpectedly- this causes an EIO. The WRITE FILEMARKS (two terminating filemarks) is being blown away because somebody put something funky in an identify message- this may have been a parity error or an ahc bug. Then ahc decides to do a bus device reset on the tape drive. Nothing directly occurs to me on this- it's a cascade effect of something that the DLT does (no known reason) and then some stumbles in ahc. The sa driver is fairly blameless in all of this. My gut feeling says parity error. One response I've seen from targets (I don't think it's valid, but I do know they do this) on detecting a parity error is to drop off the bus. Instead, they should just abort the transaction with a CHECK CONDITION (as a lot of device do- next Sense Key will be ABORTED CMD and Parity Error as the ASC/ASCQ). But what happens next is some garbage is also detected by the target on the IDENTIFY message- seems to me that this is indicative of parity errors on the cable. > > ahc0: <Adaptec aic7880 Ultra SCSI adapter> rev 0x00 int a irq 9 on pci0.20.0 > ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs > Waiting 15 seconds for SCSI devices to settle > sa0 at ahc0 bus 0 target 14 lun 0 > sa0: <QUANTUM DLT7000 2255> Removable Sequential Access SCSI-2 device > sa0: 20.000MB/s transfers (10.000MHz, offset 8, 16bit) > da0 at ahc0 bus 0 target 15 lun 0 > da0: <SEAGATE ST446452W 0001> Fixed Direct Access SCSI-2 device > da0: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing Enabled > da0: 44884MB (91923356 512 byte sectors: 255H 63S/T 5721C) > changing root device to wd0s1a > cd0 at ahc0 bus 0 target 3 lun 0 > cd0: <NEC CD-ROM DRIVE:464 1.05> Removable CD-ROM SCSI-2 device > cd0: 10.000MB/s transfers (10.000MHz, offset 15) > cd0: Attempt to query device size failed: NOT READY, Medium not present > > sa and da are external devices with a terminator. > cd0 is an internal device. I think the problem is that they're all > on the same bus and the cd's transfer rate is not the same as the > disk and tape. is that the case? What do i need to be doing here? > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.10007312355340.70618-100000>