Date: Wed, 1 Mar 2000 00:08:08 -0700 From: "Kenneth D. Merry" <ken@kdm.org> To: Mike Smith <msmith@FreeBSD.ORG> Cc: scsi@FreeBSD.ORG Subject: Re: chio trap with not-ready changer Message-ID: <20000301000808.A28657@panzer.kdm.org> In-Reply-To: <200003010655.WAA04061@mass.cdrom.com>; from msmith@FreeBSD.ORG on Tue, Feb 29, 2000 at 10:55:43PM -0800 References: <20000229233615.A28297@panzer.kdm.org> <200003010655.WAA04061@mass.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--KsGdsel6WgEHnImy
Content-Type: text/plain; charset=us-ascii
On Tue, Feb 29, 2000 at 22:55:43 -0800, Mike Smith wrote:
> > > (ch0:ahc0:0:4:0): MODE SENSE(06). CDB: 1a 0 1d 0 20 0
> > > (ch0:ahc0:0:4:0): UNIT ATTENTION asc:29,0
> > > (ch0:ahc0:0:4:0): Power on, reset, or bus device reset occurred
> > > (ch0:ahc0:0:4:0): fatal error, failed to attach to device
> > > (ch0:ahc0:0:4:0): lost device
> > > (ch0:ahc0:0:4:0): removing device entry
> > >
> > > Now what? 8)
> >
> > Well, I still can't figure out how you're getting a failure from a unit
> > attention error. I suppose the next thing to try is to bump the retry
> > count. The attached patch is the same as before, but with the retry count
> > set to 3 instead of 1.
>
> Ok. Just for kicks I tried 100 rather than 3, based on the assumption in
> my previous reply. Now it takes a _lot_ longer to give up; well past the
> point where the library becomes ready.
>
> Unfortunately, it's still failing:
>
> (ch0:ahc0:0:4:0): MODE SENSE(06). CDB: 1a 0 1d 0 20 0
> (ch0:ahc0:0:4:0): UNIT ATTENTION asc:29,0
> (ch0:ahc0:0:4:0): Power on, reset, or bus device reset occurred
> (ch0:ahc0:0:4:0): fatal error, failed to attach to device
> (ch0:ahc0:0:4:0): lost device
> (ch0:ahc0:0:4:0): removing device entry
>
> I don't know whether it's necessary to clear this condition somehow...
Well, normally, issuing any command other than an inquiry will clear a
unit attention condition.
What happens if you do something like:
camcontrol tur passN -v
Where passN is the passthrough device that attached to it? If it returns
errors, try it a few times in a row.
Also, it might be interesting to see what CAM status is getting returned
each time. The attached patch is the same as the previous patch, except
that it will print out the CAM status, SCSI status and retry count for
each failed command during the probe phase.
Ken
--
Kenneth Merry
ken@kdm.org
--KsGdsel6WgEHnImy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="scsi_ch.c.patch.20000229"
==== //depot/FreeBSD-ken/src/sys/cam/scsi/scsi_ch.c#3 - /a/ken/perforce/FreeBSD-ken/src/sys/cam/scsi/scsi_ch.c ====
*** /tmp/tmp.28764.0 Wed Mar 1 00:07:36 2000
--- /a/ken/perforce/FreeBSD-ken/src/sys/cam/scsi/scsi_ch.c Wed Mar 1 00:07:22 2000
***************
*** 551,557 ****
* Get the element address assignment page.
*/
scsi_mode_sense(&start_ccb->csio,
! /* retries */ 1,
/* cbfcnp */ chdone,
/* tag_action */ MSG_SIMPLE_Q_TAG,
/* dbd */ (softc->quirks & CH_Q_NO_DBD) ?
--- 551,557 ----
* Get the element address assignment page.
*/
scsi_mode_sense(&start_ccb->csio,
! /* retries */ 3,
/* cbfcnp */ chdone,
/* tag_action */ MSG_SIMPLE_Q_TAG,
/* dbd */ (softc->quirks & CH_Q_NO_DBD) ?
***************
*** 621,626 ****
--- 621,635 ----
} else {
int error;
+ xpt_print_path(periph->path);
+ printf("CAM status = %#x, retry count = %d\n",
+ done_ccb->ccb_h.status,
+ done_ccb->ccb_h.retry_count);
+
+ if ((done_ccb->ccb_h.status & CAM_STATUS_MASK) ==
+ CAM_SCSI_STATUS_ERROR)
+ scsi_sense_print(&done_ccb->csio);
+
error = cherror(done_ccb, 0, SF_RETRY_UA |
SF_NO_PRINT | SF_RETRY_SELTO);
/*
***************
*** 688,695 ****
xpt_announce_periph(periph, announce_buf);
softc->state = CH_STATE_NORMAL;
free(mode_header, M_TEMP);
cam_periph_unlock(periph);
! break;
}
case CH_CCB_WAITING:
{
--- 697,713 ----
xpt_announce_periph(periph, announce_buf);
softc->state = CH_STATE_NORMAL;
free(mode_header, M_TEMP);
+ /*
+ * Since our peripheral may be invalidated by an error
+ * above or an external event, we must release our CCB
+ * before releasing the probe lock on the peripheral.
+ * The peripheral will only go away once the last lock
+ * is removed, and we need it around for the CCB release
+ * operation.
+ */
+ xpt_release_ccb(done_ccb);
cam_periph_unlock(periph);
! return;
}
case CH_CCB_WAITING:
{
***************
*** 697,702 ****
--- 715,722 ----
wakeup(&done_ccb->ccb_h.cbfcnp);
return;
}
+ default:
+ break;
}
xpt_release_ccb(done_ccb);
}
--KsGdsel6WgEHnImy--
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?20000301000808.A28657>