Date: Tue, 29 Feb 2000 23:36:15 -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: <20000229233615.A28297@panzer.kdm.org> In-Reply-To: <200003010621.WAA03657@mass.cdrom.com>; from msmith@FreeBSD.ORG on Tue, Feb 29, 2000 at 10:21:39PM -0800 References: <20000229225036.B27747@panzer.kdm.org> <200003010621.WAA03657@mass.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--BXVAT5kNtrzKuDFl
Content-Type: text/plain; charset=us-ascii
On Tue, Feb 29, 2000 at 22:21:39 -0800, Mike Smith wrote:
> > Okay, I think I know why the panic is happening at least. I don't
> > understand why you're getting the unit attention error, though, since we
> > generally retry unit attention errors unconditionally.
> >
> > Try the attached patch and see if it fixes things up. Once you've got the
> > panic fixed, we can attempt to solve the unit attention problem.
>
> Ok, it's not panicking anymore:
>
> pass0 at ahc0 bus 0 target 4 lun 0
> pass0: <SPECTRA STL-8000 1.94> Removable Changer SCSI-2 device
> pass0: Serial Number 3
> pass0: 3.300MB/s transfers
> ...
> (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.
> (Sorry for the lag, rebooting this box is a bit slow due to the Mylex
> controller's interminable firmware diagnostics.)
That's okay.
Ken
--
Kenneth Merry
ken@kdm.org
--BXVAT5kNtrzKuDFl
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.28374.0 Tue Feb 29 23:34:33 2000
--- /a/ken/perforce/FreeBSD-ken/src/sys/cam/scsi/scsi_ch.c Tue Feb 29 23:33:00 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) ?
***************
*** 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:
{
--- 688,704 ----
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 ****
--- 706,713 ----
wakeup(&done_ccb->ccb_h.cbfcnp);
return;
}
+ default:
+ break;
}
xpt_release_ccb(done_ccb);
}
--BXVAT5kNtrzKuDFl--
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?20000229233615.A28297>