Date: Mon, 6 Mar 2000 20:43:18 -0700 From: "Kenneth D. Merry" <ken@kdm.org> To: Mike Smith <msmith@FreeBSD.ORG> Cc: scsi@FreeBSD.ORG, gibbs@FreeBSD.ORG Subject: Re: chio trap with not-ready changer Message-ID: <20000306204318.B80256@panzer.kdm.org> In-Reply-To: <200003070158.RAA03274@mass.cdrom.com>; from msmith@FreeBSD.ORG on Mon, Mar 06, 2000 at 05:58:21PM -0800 References: <20000304161054.A61108@panzer.kdm.org> <200003070158.RAA03274@mass.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 06, 2000 at 17:58:21 -0800, Mike Smith wrote:
> > Oooh, I think I know what may be going on here. I suspect you're hitting
> > the following case in cam_periph_error():
> >
> > } else {
> > /* decrement the number of retries */
> > retry = ccb->ccb_h.retry_count > 0;
> > if (retry)
> > ccb->ccb_h.retry_count--;
> > /*
> > * If it was aborted with no
> > * clue as to the reason, just
> > * retry it again.
> > */
> > error = ERESTART;
> > }
> >
> > You hit that when there is a SCSI error, but autosense failed, and there
> > are still retries left.
>
> Sorry; doesn't look like it. Some simple printf tracing suggests that
> it's actually the CAM_SCSI_STATUS_ERROR/CAM_STATUS_BUSY case that's
> getting called. That'd also explain the 1s delay between commands.
Oooooh. Well that's not nearly as broken as I thought. In fact, it's
probably acceptable behavior.
> Not sure yet why it's not "just working" after the unit comes ready - I'm
> guessing that's because we don't send two TUR's in sequence.
>
> Shouldn't we spin using TUR if the unit's not ready, until it does become
> ready?
We don't currently have the ability to fire off error recovery commands in
response to the SCSI status byte. So there's not an easy way to do that
right now. Hopefully Justin has addressed that in his error recovery
rewrite.
I think the best thing for you to do at the moment is what you did
originally -- make the SCSI_DELAY long enough for the changer to become
ready. I know it's painful, but you can probably tweak it to within 10
seconds or so of what you need.
A TUR handler would give you two things that that wouldn't do -- it would
let the drive probe succeed as soon as the changer is ready, and it would
allow the rest of the system to boot while the changer sits there waiting
to become ready.
Sorry we don't have an immediate solution, but hopefully we can get things
right with Justin's revamp of the error recovery code.
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?20000306204318.B80256>