Date: Wed, 30 Jul 2014 22:33:15 +0200 (CEST) From: freebsd-scsi@uriah.heep.sax.de (Joerg Wunsch) To: freebsd-scsi@freebsd.org Cc: ken@freebsd.org Subject: Re: Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds Message-ID: <20140730203315.0EED1295B@uriah.heep.sax.de> In-Reply-To: <20140730191915.9B944267B@uriah.heep.sax.de> References: <20140729090724.GA26577@uriah.heep.sax.de> <201407291823.s6TINAad032318@higson.cam.lispworks.com> <20140729191829.GK3121@uriah.heep.sax.de> <20140729204354.GA78616@nargothrond.kdm.org> <20140729224414.E2AAE276@uriah.heep.sax.de> <20140730035230.GA81800@nargothrond.kdm.org> <20140730060330.GA3272@uriah.heep.sax.de> <20140730153229.GA86368@nargothrond.kdm.org> <20140730191915.9B944267B@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
freebsd-scsi@uriah.heep.sax.de (Joerg Wunsch) wrote:
>> If the residual value in the info field is correct, then we may have a
>> problem with the way that scsi_get_sense_info() is handling it.
>
> I think that's the case; the sense info looks OK to me, and makes sense (:-);
> 32762 for the SPACE command, 55296 for the READ which is 64 KiB - 10 KiB.
>
> I'll look into scsi_get_sense_info().
Looking closer, I think scsi_get_sense_info() is fine. I turne on CAM
debugging for sa0, and get:
(sa0:sym2:0:3:0): CDB[0]=0x11 Key 0x8 ASC/ASCQ 0x0/0x5 CAM STATUS 0xc flags 0x0 resid 32762 dxfer_len 0
So at that point (end of CAM_SCSI_STATUS_ERROR handling inside
saerror()), the residula is still fine. A few lines before, that
residual value is assigned to either softc->last_io_resid, or
softc->last_ctl_resid, depending on the CCB type.
Now, this gets us closer... There is now only *one* CCB type
present in sa(4), SA_CCB_BUFFER_IO (with value 0). The former
SA_CCB_WAITING that used to be present in the driver is gone.
I don't fully understand why it has been dropped, but this looks
like an error to me, as obviously, the typemask macro is still
around (suggesting there were more than one type), and as we
can see, some decisions are still based on it.
This also explains why I have seen a single situation where
the number of tape files has been reported correctly (as 5, in
my case): the entire result is now semi-random.
I think, somehow, SA_CCB_WAITING needs to be reintroduced into
sastart(), but the differences to the code in FreeBSD 8.x are
too many for me to decide *where*. Perhaps it is the piece
if (periph->immediate_priority <= periph->pinfo.priority) {
CAM_DEBUG_PRINT(CAM_DEBUG_SUBTRACE,
("queuing for immediate ccb\n"));
Set_CCB_Type(start_ccb, SA_CCB_WAITING);
SLIST_INSERT_HEAD(&periph->ccb_list, &start_ccb->ccb_h,
periph_links.sle);
periph->immediate_priority = CAM_PRIORITY_NONE;
wakeup(&periph->ccb_list);
} else if (bp == NULL) {
that needs to be placed before the current check for bp == NULL?
--
cheers, Joerg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140730203315.0EED1295B>