Wilko Bulte wrote...
> As Kenneth D. Merry wrote ...
> > It sounds like there may be a couple of things going on. First, your
> > scanner may not be returning sense information properly.
> >
> > Second, the NCR driver may be doing something wrong.
> >
> > It would be helpful if you could hook this up to your 7890 controller and
> > see what happens. In general, the Adaptec driver behaves a little better
> > than the NCR driver.
>
> The relevant code snippet is:
>
> } else if (ccb->csio.scsi_status ==
> SCSI_STATUS_CHECK_COND
> && status != CAM_AUTOSENSE_FAIL) {
> /* no point in decrementing the retry count
> */
> panic("cam_periph_error: scsi status of "
> "CHECK COND returned but no sense "
> "information is availible. "
> "Controller should have returned "
> "CAM_AUTOSENSE_FAILED");
> /* NOTREACHED */
> error = EIO;
>
> Even if we assume the scanner yelled for attention and/or the ncr
> driver is at fault I don't really understand why the cam layer
> decides to panic the machine. Wouldn't it be sufficient to return
> EIO, or maybe just whine on the console?
Well, perhaps. My guess is that the intent was to catch problems with
incorrectly written device drivers. It looks like it may have caught a
problem in the NCR driver somewhere. I can't remember the rationale behind
having a panic instead of a printf at the moment.
> IIRC I've seen systems report 'no sense' in their log files in situations
> like this (non-FreeBSD systems that is). So I *guess* there are
> SCSI devices out there that exhibit this behaviour..
Apparantly so. I sent Rene a patch to turn the panic into a printf. The
idea is that the error will get propagated back up, and we may be able to
get a better idea of just what is failing.
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
