From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 30 20:33:22 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E259165A; Wed, 30 Jul 2014 20:33:22 +0000 (UTC) Received: from uriah.heep.sax.de (uriah.heep.sax.de [213.240.137.9]) by mx1.freebsd.org (Postfix) with ESMTP id 9F2FA21A5; Wed, 30 Jul 2014 20:33:22 +0000 (UTC) Received: by uriah.heep.sax.de (Postfix, from userid 107) id 0EED1295B; Wed, 30 Jul 2014 22:33:15 +0200 (CEST) Mime-Version: 1.0 Sender: j@uriah.heep.sax.de X-Newsreader: knews 1.0b.1 Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E 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> In-Reply-To: <20140730191915.9B944267B@uriah.heep.sax.de> From: freebsd-scsi@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds X-Original-Newsgroups: local.freebsd.scsi To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=us-ascii Message-Id: <20140730203315.0EED1295B@uriah.heep.sax.de> Date: Wed, 30 Jul 2014 22:33:15 +0200 (CEST) Cc: ken@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 20:33:23 -0000 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. ;-)