Date: Fri, 16 Jun 2000 00:32:20 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: Kevin Day <toasty@dragondata.com> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Bus resets appearing on wrong scsi busses? Message-ID: <20000616003219.B49742@panzer.kdm.org> In-Reply-To: <200006160615.BAA57754@celery.dragondata.com>; from toasty@dragondata.com on Fri, Jun 16, 2000 at 01:15:13AM -0500 References: <20000615233529.A49174@panzer.kdm.org> <200006160615.BAA57754@celery.dragondata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 16, 2000 at 01:15:13 -0500, Kevin Day wrote: > > > I've got a system with many(7) SCSI busses. One bus has nothing other than a > > > tape drive and autoloader. When I eject the tape from drive, it executes > > > correctly, but I get: > > > > > > # camcontrol eject 3:1:0 > > > Unit stopped successfully, Media ejected > > > (pass7:ahc1:0:0:0): SCB 0xd - timed out while idle, SEQADDR == 0xa > > > ahc1: Issued Channel A Bus Reset. 1 SCBs aborted > > > > > > Which really makes no sense, considering I wasn't talking to that device: > > > > > > # camcontrol devlist > > > *snip* > > > <EXABYTE Exabyte EZ17 1.06> at scbus3 target 0 lun 0 (pass7,ch0) > > > <EXABYTE EXB-89008E00012F V41b> at scbus3 target 1 lun 0 (sa0,pass8) > > > *snip* > > > > > > Then, another random scsi bus (even on a different card) will reset: > > > > > > (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. > > > > > > > > > Has anyone seen anything like this? dmesg follows: > > > > That does seem rather odd. > > > > What happens if you type: > > > > camcontrol inquiry 3:1:0 -v > > # camcontrol inquiry 3:1:0 -v > pass8: <EXABYTE EXB-89008E00012F V41b> Removable Sequential Access SCSI-2 device > pass8: Serial Number 0060154037 > pass8: 20.000MB/s transfers (10.000MHz, offset 15, 16bit) > > also: > > # camcontrol inquiry 3:0:0 -v > pass7: <EXABYTE Exabyte EZ17 1.06> Removable Changer SCSI-2 device > pass7: Serial Number 38002141 > pass7: 3.300MB/s transfers Looks fine, I guess the commands are getting to the correct device. > > Also, did you happen to rescan the bus to get the tape drive to appear? > > Typically the pass device is the first to attach. > > Nope. Both targets 0 and 1 are physically the same device, too, which makes > the attach order even weirder. Hmm, odd indeed. Or maybe not. I don't think the sa(4) driver does any I/O to the drive on attach, so I suppose it does make sense. > > How long after you attempt to eject the tape does the timed out while idle > > message appear? > > About 5 seconds. Then a second or two after that, I get the weird "bus reset > delivered". So that indicates that some command was timing out after 5 seconds, but it was a command to the changer.... The weird thing is, 'camcontrol eject' has a timeout of 120 seconds. So it must be some other command. > > Were you doing any changer operations at the same time? > > Nope. > > > > > Is the behavior consistent? > > Yes, except for which other bus gets reset. It seems to pick a random scbus > and reset it. Hmm, that is weird indeed. > > Also, why are you using camcontrol to eject the tape instead of 'mt offline'? > > I was trying to be consistant with the other camcontrol commands I plan on > using to load/unload the tapes with the changer. (I'd rather pass my script > a bus:target:lun alone, than a bus:target:lun AND device name.) Make sense in one respect, but why not use chio to do the changer operations? With camcontrol you'll have to manually compose all of the SCSI commands to move tapes from the bins to the tape drive. Well, here are two things to try: - manually specify a 120 second timeout for the eject command. e.g.: camcontrol eject 3:1:0 -t 120 -v That shouldn't make any difference, since 120 seconds is the timeout that camcontrol should be using, but it's worth a shot. - try ejecting the tape with mt instead of camcontrol. Ken -- Kenneth Merry ken@kdm.org 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?20000616003219.B49742>