From owner-freebsd-scsi@FreeBSD.ORG Tue Jul 29 09:07:46 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 2B1B4DEB for ; Tue, 29 Jul 2014 09:07:46 +0000 (UTC) Received: from uriah.heep.sax.de (uriah.heep.sax.de [IPv6:2a01:170:1047::9]) by mx1.freebsd.org (Postfix) with ESMTP id DAF0F2D7F for ; Tue, 29 Jul 2014 09:07:45 +0000 (UTC) Received: from uriah.heep.sax.de (localhost [127.0.0.1]) by uriah.heep.sax.de (Postfix) with ESMTP id AA06E2722 for ; Tue, 29 Jul 2014 11:07:30 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on uriah.heep.sax.de X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from uriah.heep.sax.de (p578a6f91.dip0.t-ipconnect.de [87.138.111.145]) by uriah.heep.sax.de (Postfix) with ESMTPSA for ; Tue, 29 Jul 2014 11:07:30 +0200 (CEST) Date: Tue, 29 Jul 2014 11:07:24 +0200 From: Joerg Wunsch To: freebsd-scsi@freebsd.org Subject: Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds Message-ID: <20140729090724.GA26577@uriah.heep.sax.de> Reply-To: Joerg Wunsch Mail-Followup-To: Joerg Wunsch , freebsd-scsi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 X-GPG-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 User-Agent: Mutt/1.5.21 (2010-09-15) 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: Tue, 29 Jul 2014 09:07:46 -0000 After finally migrating my Bacula database from SQlite into PostgreSQL in the course of upgrading the machine to new hardware as well as from FreeBSD 8.2 to 10-stable, Bacula now experiences strange behaviour: The number of files mismatch! Volume=32767 Catalog=33 Correcting Catalog What happens is that Bacula, when trying to go to end of recorded medium, issues the equivalent of mt fsf 32767 and then mt status in order to know which tape file it is located at. In FreeBSD 8.2, this correctly yielded the actual tape file number (i. e., 33 in the above case), but in FreeBSD 10, it yields 32767. You can perform "mt fsf" ad nauseum now, and each time, it pretends it were advancing one more file ... I did a glance at the source code differences between 8.2 and 10.x, but nothing sprang into my eye immediately. Does anyone have an idea? Anyone out there who can test this on their machines? (One other change is that the machine turned from i386 into amd64 architecture, so there's also a minor chance the problem might be 64-bit related, although I wouldn't assume this to be the case.) -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi@FreeBSD.ORG Tue Jul 29 18:34:10 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 6DC6E83F for ; Tue, 29 Jul 2014 18:34:10 +0000 (UTC) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [46.17.166.21]) by mx1.freebsd.org (Postfix) with ESMTP id E67A423F0 for ; Tue, 29 Jul 2014 18:34:09 +0000 (UTC) Received: from higson.cam.lispworks.com (higson.cam.lispworks.com [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.5/8.14.5) with ESMTP id s6TINAJ6004202; Tue, 29 Jul 2014 19:23:10 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id s6TINA3G032322; Tue, 29 Jul 2014 19:23:10 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id s6TINAad032318; Tue, 29 Jul 2014 19:23:10 +0100 Date: Tue, 29 Jul 2014 19:23:10 +0100 Message-Id: <201407291823.s6TINAad032318@higson.cam.lispworks.com> From: Martin Simmons To: Joerg Wunsch In-reply-to: <20140729090724.GA26577@uriah.heep.sax.de> (message from Joerg Wunsch on Tue, 29 Jul 2014 11:07:24 +0200) Subject: Re: Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds References: <20140729090724.GA26577@uriah.heep.sax.de> Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@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: Tue, 29 Jul 2014 18:34:10 -0000 >>>>> On Tue, 29 Jul 2014 11:07:24 +0200, Joerg Wunsch said: > > After finally migrating my Bacula database from SQlite into PostgreSQL > in the course of upgrading the machine to new hardware as well as from > FreeBSD 8.2 to 10-stable, Bacula now experiences strange behaviour: > > The number of files mismatch! Volume=32767 Catalog=33 > Correcting Catalog > > What happens is that Bacula, when trying to go to end of recorded > medium, issues the equivalent of > > mt fsf 32767 > > and then > > mt status > > in order to know which tape file it is located at. > > In FreeBSD 8.2, this correctly yielded the actual tape file number > (i. e., 33 in the above case), but in FreeBSD 10, it yields 32767. > You can perform "mt fsf" ad nauseum now, and each time, it pretends it > were advancing one more file ... > > I did a glance at the source code differences between 8.2 and 10.x, > but nothing sprang into my eye immediately. Does anyone have an > idea? > > Anyone out there who can test this on their machines? > > (One other change is that the machine turned from i386 into amd64 > architecture, so there's also a minor chance the problem might be > 64-bit related, although I wouldn't assume this to be the case.) Maybe you are now connecting the tape drive via a different SCSI driver? It sounds like you are running Bacula with "Fast Forward Space File = yes" in the configuration. FWIW, my latest hardware on FreeBSD 8.3 works with that, but for some reason my previous hardware on an older FreeBSD needed the traditional FreeBSD Bacula configuration described here: http://www.bacula.org/7.0.x-manuals/en/problems/Testing_Your_Tape_Drive_Wit.html#SECTION00437000000000000000 I didn't ever check why it needed that. Beware that changing the eotmodel will cause incompatibility with any existing tapes. __Martin From owner-freebsd-scsi@FreeBSD.ORG Tue Jul 29 19:18:31 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5475D54B; Tue, 29 Jul 2014 19:18:31 +0000 (UTC) Received: from uriah.heep.sax.de (uriah.heep.sax.de [IPv6:2a01:170:1047::9]) by mx1.freebsd.org (Postfix) with ESMTP id 12AB027E3; Tue, 29 Jul 2014 19:18:31 +0000 (UTC) Received: by uriah.heep.sax.de (Postfix, from userid 107) id 61B6F24C7; Tue, 29 Jul 2014 21:18:29 +0200 (CEST) Date: Tue, 29 Jul 2014 21:18:29 +0200 From: Joerg Wunsch To: freebsd-scsi@freebsd.org Subject: Re: Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds Message-ID: <20140729191829.GK3121@uriah.heep.sax.de> Mail-Followup-To: Joerg Wunsch , freebsd-scsi@freebsd.org, Martin Simmons , "Kenneth D. Merry" References: <20140729090724.GA26577@uriah.heep.sax.de> <201407291823.s6TINAad032318@higson.cam.lispworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201407291823.s6TINAad032318@higson.cam.lispworks.com> 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 X-GPG-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "Kenneth D. Merry" 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: Tue, 29 Jul 2014 19:18:31 -0000 As Martin Simmons wrote: > Maybe you are now connecting the tape drive via a different SCSI > driver? No, I forgot to say: the tape drive/library is a Sun L9 which has HV-Diff-SCSI, so I have to use the exact same Symbios Logic SCSI controller (and driver) as before. > It sounds like you are running Bacula with "Fast Forward Space File > = yes" in the configuration. Yes, that's the case. However, even without that, I'm afraid the Bacula logic would run into an infinite loop, as a single FSF operation now always succeeds, and pretends it encountered a new tape file. (Besides, the "Fast Forward Space File" thing did work for many years.) Looking into saspace() in sys/cam/scsi/scsi_sa.c, I see: ==================================================================== } else if (code == SS_FILEMARKS && softc->fileno != (daddr_t) -1) { softc->fileno += (count - softc->last_ctl_resid); if (softc->fileno < 0) /* we must of hit BOT */ softc->fileno = 0; softc->blkno = 0; ==================================================================== That piece of code ought to be responsible when the SPACE command hit a filemark. It hasn't been changed for more than a decade though. Now the following SVN log message rang a bell to me: ==================================================================== r225950 | ken | 2011-10-03 22:32:55 +0200 (Mo, 03. Okt 2011) | 146 Zeilen Add descriptor sense support to CAM, and honor sense residuals properly in CAM. ==================================================================== It went in after my older (working) 8.2 system, it talks about residual handling, and the code above uses "softc->last_ctl_resid". It wouldn't surprise me if that's somehow related to the issue. I'm Cc'ing Ken (as the committer of 225950) for an opinion, just in case he doesn't follow the list so closely. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi@FreeBSD.ORG Tue Jul 29 20:43:57 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36C5F5EE for ; Tue, 29 Jul 2014 20:43:57 +0000 (UTC) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE34522AA for ; Tue, 29 Jul 2014 20:43:56 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.9/8.14.2) with ESMTP id s6TKhsxm078783; Tue, 29 Jul 2014 14:43:54 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.9/8.14.9/Submit) id s6TKhsuH078782; Tue, 29 Jul 2014 14:43:54 -0600 (MDT) (envelope-from ken) Date: Tue, 29 Jul 2014 14:43:54 -0600 From: "Kenneth D. Merry" To: Joerg Wunsch , freebsd-scsi@freebsd.org, Martin Simmons Subject: Re: Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds Message-ID: <20140729204354.GA78616@nargothrond.kdm.org> References: <20140729090724.GA26577@uriah.heep.sax.de> <201407291823.s6TINAad032318@higson.cam.lispworks.com> <20140729191829.GK3121@uriah.heep.sax.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140729191829.GK3121@uriah.heep.sax.de> User-Agent: Mutt/1.5.23 (2014-03-12) 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: Tue, 29 Jul 2014 20:43:57 -0000 On Tue, Jul 29, 2014 at 21:18:29 +0200, Joerg Wunsch wrote: > As Martin Simmons wrote: > > > Maybe you are now connecting the tape drive via a different SCSI > > driver? > > No, I forgot to say: the tape drive/library is a Sun L9 which has > HV-Diff-SCSI, so I have to use the exact same Symbios Logic SCSI > controller (and driver) as before. > > > It sounds like you are running Bacula with "Fast Forward Space File > > = yes" in the configuration. > > Yes, that's the case. However, even without that, I'm afraid the > Bacula logic would run into an infinite loop, as a single FSF > operation now always succeeds, and pretends it encountered a new tape > file. (Besides, the "Fast Forward Space File" thing did work for many > years.) > > Looking into saspace() in sys/cam/scsi/scsi_sa.c, I see: > > ==================================================================== > } else if (code == SS_FILEMARKS && softc->fileno != (daddr_t) -1) { > softc->fileno += (count - softc->last_ctl_resid); > if (softc->fileno < 0) /* we must of hit BOT */ > softc->fileno = 0; > softc->blkno = 0; > ==================================================================== > > That piece of code ought to be responsible when the SPACE command hit > a filemark. It hasn't been changed for more than a decade though. > > Now the following SVN log message rang a bell to me: > > ==================================================================== > r225950 | ken | 2011-10-03 22:32:55 +0200 (Mo, 03. Okt 2011) | 146 Zeilen > > Add descriptor sense support to CAM, and honor sense residuals properly in > CAM. > ==================================================================== > > It went in after my older (working) 8.2 system, it talks about > residual handling, and the code above uses "softc->last_ctl_resid". > > It wouldn't surprise me if that's somehow related to the issue. Yes, it could be related. The descriptor sense changes abstracted out sense data handling so that fixed and descriptor sense would be handled in the same way. The residual got bumped up from 32 to 64 bits to accommodate the increased size of the descriptor sense fields. In theory the values should be equivalent, but it is possible that there is breakage. Can you put a printf in the above code snippet, and print out the count, fileno, and last_ctl_resid before fileno is set? That might tell us something. The original code in saerror did this with the residual: info = (int32_t) scsi_4btoul(sense->info); resid = info; resid was then assigned to last_ctl_resid. Everything was a 32 bit value; info was int32_t and resid was uint32_t. The new code (in scsi_get_sense_info() in scsi_all.c) effectively does: uint32_t info_val; info_val = scsi_4btoul(sense->info); *info = info_val; if (signed_info != NULL) *signed_info = (int32_t)info_val; info and signed_info are uint64_t and int64_t, respectively. The info value is what makes it into last_ctl_resid. Another possibility here is that the driver is setting the sense residual incorrectly. If that happens, then we would think that the info field isn't present in the sense, and would report the entire transfer length as the residual. (For a space command, I don't think there would be a transfer.) The sym(4) driver does set the sense residual, but I'd have to dig into it a little more to figure out whether it is doing the right thing. Hopefully a few printfs will give us a better idea of what is going on. If the printf in saspace() doesn't show anything suspicious, the next place to look would be at the sense_len in saerror(). > I'm Cc'ing Ken (as the committer of 225950) for an opinion, just in > case he doesn't follow the list so closely. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Tue Jul 29 22:44:17 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35B26FB2; Tue, 29 Jul 2014 22:44:17 +0000 (UTC) Received: from uriah.heep.sax.de (uriah.heep.sax.de [213.240.137.9]) by mx1.freebsd.org (Postfix) with ESMTP id E936220E6; Tue, 29 Jul 2014 22:44:16 +0000 (UTC) Received: by uriah.heep.sax.de (Postfix, from userid 107) id E2AAE276; Wed, 30 Jul 2014 00:44:14 +0200 (CEST) Mime-Version: 1.0 X-Newsreader: knews 1.0b.1 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) 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> In-Reply-To: <20140729204354.GA78616@nargothrond.kdm.org> From: j@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: <20140729224414.E2AAE276@uriah.heep.sax.de> Date: Wed, 30 Jul 2014 00:44:14 +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: Tue, 29 Jul 2014 22:44:17 -0000 "Kenneth D. Merry" wrote: > Can you put a printf in the above code snippet, and print out the count, > fileno, and last_ctl_resid before fileno is set? That might tell us > something. Incidently, I had exactly the same idea just before you wrote it. ;-) I had to do a full kernel rebuild though, so it took a while to complete. My old FreeBSD 8.2 hardware is also still around, and I could reproduce the problem on an elderly DLT2000 drive I've got, which could easily be swapped between both machines. In each case, the drive was attached to a sym(4) driver (just in case). On the FreeBSD 10 machine, I get the following: sym2: <810a> port 0xc000-0xc0ff mem 0xfe920000-0xfe9200ff irq 21 at device 7.0 on pci4 sym2: No NVRAM, ID 7, Fast-10, SE, parity checking sa0 at sym2 bus 0 scbus5 target 3 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: Serial Number JF74130050 sa0: 5.000MB/s transfers (5.000MHz, offset 8) (sa0:sym2:0:3:0): 10240-byte tape record bigger than supplied buffer saspace(): fileno 0, count 32767, resid 0 (The "bigger than supplied buffer" message is probably from "mt stat".) On the FreeBSD 8.2 machine, the printout for the same tape was saspace(): fileno 0, count 32767, resid 32762 (The tape has 5 filemarks on it.) So we are probably on the right track. > Another possibility here is that the driver is setting the sense residual > incorrectly. I've seen that CAM debugging can now be turned on the fly. Maybe that would be of some help here? It's already past midnight, so I'm heading for bed now. Thanks for the responses so far! -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 30 03:52:33 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 6DD8FDAF for ; Wed, 30 Jul 2014 03:52:33 +0000 (UTC) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F18F92031 for ; Wed, 30 Jul 2014 03:52:32 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.9/8.14.2) with ESMTP id s6U3qUL1082066; Tue, 29 Jul 2014 21:52:30 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.9/8.14.9/Submit) id s6U3qUEp082065; Tue, 29 Jul 2014 21:52:30 -0600 (MDT) (envelope-from ken) Date: Tue, 29 Jul 2014 21:52:30 -0600 From: "Kenneth D. Merry" To: Joerg Wunsch Subject: Re: Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds Message-ID: <20140730035230.GA81800@nargothrond.kdm.org> 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> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: <20140729224414.E2AAE276@uriah.heep.sax.de> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-scsi@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 03:52:33 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jul 30, 2014 at 00:44:14 +0200, Joerg Wunsch wrote: > "Kenneth D. Merry" wrote: > > > Can you put a printf in the above code snippet, and print out the count, > > fileno, and last_ctl_resid before fileno is set? That might tell us > > something. > > Incidently, I had exactly the same idea just before you wrote it. ;-) > > I had to do a full kernel rebuild though, so it took a while to complete. > My old FreeBSD 8.2 hardware is also still around, and I could reproduce > the problem on an elderly DLT2000 drive I've got, which could easily be > swapped between both machines. In each case, the drive was attached to > a sym(4) driver (just in case). Ahh. Now I know who to send sa(4) driver patches to test. :) I've got a large set of patches for the sa(4) driver to improve its support of modern tape hardware. The challenge is making sure that I haven't broken older hardware in the process. The patches aren't quite ready for testing, but I'm hoping to have time to get them cleaned up soon. > On the FreeBSD 10 machine, I get the following: > > sym2: <810a> port 0xc000-0xc0ff mem 0xfe920000-0xfe9200ff irq 21 at device 7.0 on pci4 > sym2: No NVRAM, ID 7, Fast-10, SE, parity checking > sa0 at sym2 bus 0 scbus5 target 3 lun 0 > sa0: Removable Sequential Access SCSI-2 device > sa0: Serial Number JF74130050 > sa0: 5.000MB/s transfers (5.000MHz, offset 8) > (sa0:sym2:0:3:0): 10240-byte tape record bigger than supplied buffer > saspace(): fileno 0, count 32767, resid 0 > > (The "bigger than supplied buffer" message is probably from "mt stat".) Yes, it does a test read to try to figure out what the blocksize of the tape is. > On the FreeBSD 8.2 machine, the printout for the same tape was > > saspace(): fileno 0, count 32767, resid 32762 > > (The tape has 5 filemarks on it.) > > So we are probably on the right track. Yes, it looks like we're not getting the residual set properly. The most likely cause is that the sym(4) driver is sending back an incorrect sense residual, which is causing us to ignore some of the sense data. > > Another possibility here is that the driver is setting the sense residual > > incorrectly. > > I've seen that CAM debugging can now be turned on the fly. Maybe that would > be of some help here? Well, it isn't CAM-specific, but we can use DTrace to figure some of it out. If you have DTrace enabled (kldload dtraceall), you can run the attached D script and we'll see what the residual is. If the attachment gets trimmed by the list software, the script is also available here: http://people.freebsd.org/~ken/tapetest.d On my test system with a SAS-attached LTO-6 (using an mpr(4) controller), here is what happens if I do a 524290 byte read with dd from a tape written with 524288 byte blocks: {black-pearl:/usr/home/kenm:!:0} dd if=/dev/nsa0 of=/dev/null bs=524290 count=1 0+1 records in 0+1 records out 524288 bytes transferred in 0.008861028 secs (59167853 bytes/sec) {black-pearl:/usr/home/kenm:!:0} dd if=/dev/nsa0 of=/dev/null bs=524290 count=1 0+1 records in 0+1 records out 524288 bytes transferred in 0.003310369 secs (158377510 bytes/sec) {black-pearl:/usr/home/kenm:!:0} dtrace -s tapetest.d dtrace: script 'tapetest.d' matched 1 probe CPU ID FUNCTION:NAME 0 401 saerror:entry Opcode 08, Status 0xc Data: Len 524290, Resid 2, Sense: Len 252, Resid 0 0 401 saerror:entry Opcode 08, Status 0xc Data: Len 524290, Resid 2, Sense: Len 252, Resid 0 If the sense residual is set too high, that will explain why we're not getting the info field back and therefore why we're setting the last_ctl_resid value to 0. > It's already past midnight, so I'm heading for bed now. Thanks for the > responses so far! You're welcome! Hopefully we can track this down. Ken -- Kenneth Merry ken@FreeBSD.ORG --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tapetest.d" /*- * Copyright (c) 2014 Spectra Logic Corporation * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions, and the following disclaimer, * without modification. * 2. Redistributions in binary form must reproduce at minimum a disclaimer * substantially similar to the "NO WARRANTY" disclaimer below * ("Disclaimer") and any redistribution must be conditioned upon * including a substantially similar Disclaimer requirement for further * binary redistribution. * * NO WARRANTY * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT * HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * POSSIBILITY OF SUCH DAMAGES. * * Authors: Ken Merry (Spectra Logic Corporation) * * $FreeBSD$ */ #pragma D option cleanrate=5000hz #pragma D option dynvarsize=8192000 /* * This is a simple DTrace script to print out basic information about * calls to saerror(). This was originally written to help diagnose * problems with the sense residual, but could be used for other purposes. * * Note that CAM_STATUS_MASK == 0x3f and CAM_SCSI_STATUS_ERROR == 0x0c. * DTrace doesn't seem to decode the enum, so we just use hard-coded values * here. */ fbt:kernel:saerror:entry /(args[0]->ccb_h.status & 0x3f) == 0x0c/ { printf("Opcode %02x, Status %#x Data: Len %u, Resid %u, Sense: Len %u, Resid %u\n", args[0]->csio.cdb_io.cdb_bytes[0], args[0]->ccb_h.status & 0x3f, args[0]->csio.dxfer_len, args[0]->csio.resid, args[0]->csio.sense_len, args[0]->csio.sense_resid); } --LZvS9be/3tNcYl/X-- From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 30 06:03:34 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 522C596B; Wed, 30 Jul 2014 06:03:34 +0000 (UTC) Received: from uriah.heep.sax.de (uriah.heep.sax.de [IPv6:2a01:170:1047::9]) by mx1.freebsd.org (Postfix) with ESMTP id 10A7F2D7A; Wed, 30 Jul 2014 06:03:34 +0000 (UTC) Received: by uriah.heep.sax.de (Postfix, from userid 107) id BFB0A2539; Wed, 30 Jul 2014 08:03:31 +0200 (CEST) Date: Wed, 30 Jul 2014 08:03:31 +0200 From: Joerg Wunsch To: freebsd-scsi@freebsd.org Subject: Re: Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds Message-ID: <20140730060330.GA3272@uriah.heep.sax.de> Mail-Followup-To: Joerg Wunsch , freebsd-scsi@freebsd.org, "Kenneth D. Merry" 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140730035230.GA81800@nargothrond.kdm.org> 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 X-GPG-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "Kenneth D. Merry" 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 06:03:34 -0000 As Kenneth D. Merry wrote: > Ahh. Now I know who to send sa(4) driver patches to test. :) The only thing is that I don't love to reboot my main server machine gratuitously. But everything I could do on old scratch hardware is possible. I've also got a Tandberg SLR5 still around, I simply can't throw it away ... (Replacing the L9 by some SAS-attached LTO-x library is already planned.) > {black-pearl:/usr/home/kenm:!:0} dtrace -s tapetest.d > dtrace: script 'tapetest.d' matched 1 probe > CPU ID FUNCTION:NAME > 0 401 saerror:entry Opcode 08, Status 0xc Data: Len 524290, Resid 2, Sense: Len 252, Resid 0 > > 0 401 saerror:entry Opcode 08, Status 0xc Data: Len 524290, Resid 2, Sense: Len 252, Resid 0 Here's the DTrace output, first a dd with a blocksize of 64 KiB (on a standard tar tape with 10 KiB records), then I did a rewind, followed by "mt fsf 32767". root@uriah:~ # dtrace -s /tmp/tapetest.d dtrace: script '/tmp/tapetest.d' matched 1 probe CPU ID FUNCTION:NAME 3 406 saerror:entry Opcode 08, Status 0xc Data: Len 65536, Resid 55296, Sense: Len 252, Resid 223 0 406 saerror:entry Opcode 11, Status 0xc Data: Len 0, Resid 0, Sense: Len 252, Resid 223 It seems we are getting no residual for the SPACE command?! -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 30 15:32:32 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 6003DB36 for ; Wed, 30 Jul 2014 15:32:32 +0000 (UTC) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C1A12F16 for ; Wed, 30 Jul 2014 15:32:31 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.9/8.14.2) with ESMTP id s6UFWUi1086500; Wed, 30 Jul 2014 09:32:30 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.9/8.14.9/Submit) id s6UFWTug086499; Wed, 30 Jul 2014 09:32:29 -0600 (MDT) (envelope-from ken) Date: Wed, 30 Jul 2014 09:32:29 -0600 From: "Kenneth D. Merry" To: Joerg Wunsch , freebsd-scsi@freebsd.org Subject: Re: Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds Message-ID: <20140730153229.GA86368@nargothrond.kdm.org> 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> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: <20140730060330.GA3272@uriah.heep.sax.de> User-Agent: Mutt/1.5.23 (2014-03-12) 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 15:32:32 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jul 30, 2014 at 08:03:31 +0200, Joerg Wunsch wrote: > As Kenneth D. Merry wrote: > > > Ahh. Now I know who to send sa(4) driver patches to test. :) > > The only thing is that I don't love to reboot my main server machine > gratuitously. But everything I could do on old scratch hardware is > possible. I've also got a Tandberg SLR5 still around, I simply can't > throw it away ... I know what you mean. :) (I've got 3 standalone tape drives and 2 tape libraries that I haven't been able to part with yet...) > (Replacing the L9 by some SAS-attached LTO-x library is already > planned.) Yep, you'll get much more capacity that way. > > {black-pearl:/usr/home/kenm:!:0} dtrace -s tapetest.d > > dtrace: script 'tapetest.d' matched 1 probe > > CPU ID FUNCTION:NAME > > 0 401 saerror:entry Opcode 08, Status 0xc Data: Len 524290, Resid 2, Sense: Len 252, Resid 0 > > > > 0 401 saerror:entry Opcode 08, Status 0xc Data: Len 524290, Resid 2, Sense: Len 252, Resid 0 > > Here's the DTrace output, first a dd with a blocksize of 64 KiB (on a > standard tar tape with 10 KiB records), then I did a rewind, followed > by "mt fsf 32767". > > root@uriah:~ # dtrace -s /tmp/tapetest.d > dtrace: script '/tmp/tapetest.d' matched 1 probe > CPU ID FUNCTION:NAME > 3 406 saerror:entry Opcode 08, Status 0xc Data: Len 65536, Resid 55296, Sense: Len 252, Resid 223 > > 0 406 saerror:entry Opcode 11, Status 0xc Data: Len 0, Resid 0, Sense: Len 252, Resid 223 > > It seems we are getting no residual for the SPACE command?! The SPACE command doesn't send data, so it makes sense that there is no data length and no data residual. The sense length and residual show that we have 29 bytes of sense data. That is plenty of length to allow for us to have a look at the info field, which is in bytes 3-6. I have attached an updated DTrace script. This will print out the info field, and we'll see what the drive is returning in the info field. 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. If the value in the info field is incorrect, then we'll probably need to look at the sym(4) driver. Ken -- Kenneth Merry ken@FreeBSD.ORG --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tapetest.d" /*- * Copyright (c) 2014 Spectra Logic Corporation * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions, and the following disclaimer, * without modification. * 2. Redistributions in binary form must reproduce at minimum a disclaimer * substantially similar to the "NO WARRANTY" disclaimer below * ("Disclaimer") and any redistribution must be conditioned upon * including a substantially similar Disclaimer requirement for further * binary redistribution. * * NO WARRANTY * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT * HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * POSSIBILITY OF SUCH DAMAGES. * * Authors: Ken Merry (Spectra Logic Corporation) * * $FreeBSD$ */ #pragma D option cleanrate=5000hz #pragma D option dynvarsize=8192000 /* * This is a simple DTrace script to print out basic information about * calls to saerror(). This was originally written to help diagnose * problems with the sense residual, but could be used for other purposes. * * Note that CAM_STATUS_MASK == 0x3f and CAM_SCSI_STATUS_ERROR == 0x0c. * DTrace doesn't seem to decode the enum, so we just use hard-coded values * here. */ fbt:kernel:saerror:entry /(args[0]->ccb_h.status & 0x3f) == 0x0c/ { printf("Opcode %02x, Status %#x Data: Len %u, Resid %u, Sense: Len %u, Resid %u\n", args[0]->csio.cdb_io.cdb_bytes[0], args[0]->ccb_h.status & 0x3f, args[0]->csio.dxfer_len, args[0]->csio.resid, args[0]->csio.sense_len, args[0]->csio.sense_resid); } fbt:kernel:scsi_get_sense_info:entry /(arg1 >= 7)/ { printf("Sense info: %x,%x,%x,%x\n", args[0]->sense_buf[2], args[0]->sense_buf[3], args[0]->sense_buf[4], args[0]->sense_buf[5]); } --qMm9M+Fa2AknHoGS-- From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 30 19:19:17 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1528B22 for ; Wed, 30 Jul 2014 19:19:17 +0000 (UTC) Received: from uriah.heep.sax.de (uriah.heep.sax.de [IPv6:2a01:170:1047::9]) by mx1.freebsd.org (Postfix) with ESMTP id 5FBFB292A for ; Wed, 30 Jul 2014 19:19:17 +0000 (UTC) Received: by uriah.heep.sax.de (Postfix, from userid 107) id 9B944267B; Wed, 30 Jul 2014 21:19:15 +0200 (CEST) Mime-Version: 1.0 Sender: j@uriah.heep.sax.de X-Newsreader: knews 1.0b.1 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) 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> In-Reply-To: <20140730153229.GA86368@nargothrond.kdm.org> 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: <20140730191915.9B944267B@uriah.heep.sax.de> Date: Wed, 30 Jul 2014 21:19:15 +0200 (CEST) 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 19:19:17 -0000 "Kenneth D. Merry" wrote: >> (Replacing the L9 by some SAS-attached LTO-x library is already >> planned.) > > Yep, you'll get much more capacity that way. That's the main reason, yes. My pile of DLT media is getting quite full. > I have attached an updated DTrace script. This will print out the info > field, and we'll see what the drive is returning in the info field. Here's the output (this time, "mt fsf 32767" first, and the "dd" command second). root@uriah:~ # dtrace -s /tmp/tapetest.d dtrace: script '/tmp/tapetest.d' matched 2 probes CPU ID FUNCTION:NAME 1 406 saerror:entry Opcode 11, Status 0xc Data: Len 0, Resid 0, Sense: Len 252, Resid 223 1 21086 scsi_get_sense_info:entry Sense info: 0,0,7f,fa 3 406 saerror:entry Opcode 08, Status 0xc Data: Len 65536, Resid 55296, Sense: Len 252, Resid 223 3 21086 scsi_get_sense_info:entry Sense info: 0,0,d8,0 ^C > 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(). -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) 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. ;-) From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 30 20:42:01 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E560F72E; Wed, 30 Jul 2014 20:42:01 +0000 (UTC) Received: from uriah.heep.sax.de (uriah.heep.sax.de [IPv6:2a01:170:1047::9]) by mx1.freebsd.org (Postfix) with ESMTP id A2735226B; Wed, 30 Jul 2014 20:42:01 +0000 (UTC) Received: by uriah.heep.sax.de (Postfix, from userid 107) id 4645729B8; Wed, 30 Jul 2014 22:42:00 +0200 (CEST) Mime-Version: 1.0 Sender: j@uriah.heep.sax.de X-Newsreader: knews 1.0b.1 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) 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> <20140730203315.0EED1295B@uriah.heep.sax.de> In-Reply-To: <20140730203315.0EED1295B@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: <20140730204200.4645729B8@uriah.heep.sax.de> Date: Wed, 30 Jul 2014 22:42:00 +0200 (CEST) Cc: mav@freebsd.org, 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:42:02 -0000 freebsd-scsi@uriah.heep.sax.de (Joerg Wunsch) wrote: > 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? The respective change that broke it (on HEAD) was r256843. I'm Cc'ing Alexander Motin (mav@) who committed that change. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 30 21:11:02 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 59A1D20F; Wed, 30 Jul 2014 21:11:02 +0000 (UTC) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BB5A32613; Wed, 30 Jul 2014 21:11:01 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id k48so1829641wev.41 for ; Wed, 30 Jul 2014 14:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=fADcFLXWVMpfoxHU2QlLc82t81Sq4IYAP66Eie921l8=; b=AFSe8hqAz46cNgmPiCAlYuCevUqb7/UdJQ3z62b6ZmzFCMQ0Y1/8z1ZdmWMzkrGiOT 2HdThi3RzuCVYhVxH4F7c7SWrjHabF/kzS7Iy3ygybnJEBO/BhWAEC6PQRRrfRY+BRRs 1lmTtx4M59istqe4J71JlV4hf/ws52qf3D4jJzx9VMa6bOndw6qvN2dr5W1cf4s1wclX 1UWYwUz2Qm4mrz8zBs7Ao6HskVw7emCdd85Wm0Fw3dwLqhi3aI1WT2svPhR02iS4kxkZ 9jRILYs6F+Qz0S+0ouuUjizmm9SBNZ9PLZ8+MQb4npNgLbkMczTIIiimixNXbaS9Onuk C7cw== X-Received: by 10.180.19.1 with SMTP id a1mr10902532wie.16.1406754659937; Wed, 30 Jul 2014 14:10:59 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id gc8sm13624911wic.3.2014.07.30.14.10.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 14:10:59 -0700 (PDT) Sender: Alexander Motin Message-ID: <53D95F61.4080701@FreeBSD.org> Date: Thu, 31 Jul 2014 00:10:57 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joerg Wunsch , freebsd-scsi@freebsd.org Subject: Re: Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds 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> <20140730203315.0EED1295B@uriah.heep.sax.de> <20140730204200.4645729B8@uriah.heep.sax.de> In-Reply-To: <20140730204200.4645729B8@uriah.heep.sax.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 21:11:02 -0000 On 30.07.2014 23:42, Joerg Wunsch wrote: > freebsd-scsi@uriah.heep.sax.de (Joerg Wunsch) wrote: > >> 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? > > The respective change that broke it (on HEAD) was r256843. I'm Cc'ing > Alexander Motin (mav@) who committed that change. Yes, that was me who removed that second type handling from sastart(). The same was done for all other drivers as part of CAM simplification efforts. Probably I missed the fact that sa(4) uses that type for something else. So while type may indeed be restored (I have no idea about that aspect of sa(4) driver, neither have hardware to test it), it should probably be set in some other point, since calls of type previously called SA_CCB_WAITING are no longer going through that path in sastart(). If needed, it may possibly be set after cam_periph_getccb() calls, or may be made the default and set it only for IO case in single place. -- Alexander Motin From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 30 21:51:20 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 8F874F4C; Wed, 30 Jul 2014 21:51:20 +0000 (UTC) Received: from uriah.heep.sax.de (uriah.heep.sax.de [IPv6:2a01:170:1047::9]) by mx1.freebsd.org (Postfix) with ESMTP id A832229B8; Wed, 30 Jul 2014 21:51:19 +0000 (UTC) Received: by uriah.heep.sax.de (Postfix, from userid 107) id 682382157; Wed, 30 Jul 2014 23:51:14 +0200 (CEST) Date: Wed, 30 Jul 2014 23:51:14 +0200 From: Joerg Wunsch To: Alexander Motin Subject: Re: Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds Message-ID: <20140730215113.GA3564@uriah.heep.sax.de> Reply-To: Joerg Wunsch Mail-Followup-To: Joerg Wunsch , Alexander Motin , freebsd-scsi@freebsd.org, ken@freebsd.org References: <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> <20140730203315.0EED1295B@uriah.heep.sax.de> <20140730204200.4645729B8@uriah.heep.sax.de> <53D95F61.4080701@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <53D95F61.4080701@FreeBSD.org> 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 X-GPG-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-scsi@freebsd.org, 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 21:51:20 -0000 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline As Alexander Motin wrote: > Yes, that was me who removed that second type handling from sastart(). > The same was done for all other drivers as part of CAM simplification > efforts. Probably I missed the fact that sa(4) uses that type for > something else. Well, a quick glance at the remainder of the driver shows that the typemask is just a single bit, so if you remove one of its possible values, you should have questioned the entire type field/mask in turn, as it became useless then. #define SA_CCB_BUFFER_IO 0x0 #define SA_CCB_TYPEMASK 0x1 #define SA_POSITION_UPDATED 0x2 #define Set_CCB_Type(x, type) \ x->ccb_h.ccb_pflags &= ~SA_CCB_TYPEMASK; \ x->ccb_h.ccb_pflags |= type SA_CCB_BUFFER_WAITING was indeed not tested anywhere else, but there are decisions based on SA_CCB_BUFFER_IO (which used to be the opposite of SA_CCB_BUFFER_WAITING). These decisions now became random decisions. :-( > So while type may indeed be restored (I have no idea > about that aspect of sa(4) driver, neither have hardware to test it) Not having the hardware doesn't seem to be a good base for modifying the driver in the first place to me. Ken, I think that entire CCB_Type stuff can go away then as it is not used anymore. The only side-effect I see is that parts of MTIOCERRSTAT are rendered useless now, as the distinction between control and IO transfers is gone. Unfortunately, the new Bugzilla doesn't seem to accept me (I tried Peter Wemm's description about kinit / kpasswd), so I cannot open a bug report for it. Attached is a suggested patch. So far, I only compile-tested it. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) --gKMricLos+KVdGMg Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="scsi_sa.c.diff" Index: scsi/scsi_sa.c =================================================================== --- scsi/scsi_sa.c (Revision 269317) +++ scsi/scsi_sa.c (Arbeitskopie) @@ -113,18 +113,8 @@ #define ccb_pflags ppriv_field0 #define ccb_bp ppriv_ptr1 -#define SA_CCB_BUFFER_IO 0x0 -#define SA_CCB_TYPEMASK 0x1 #define SA_POSITION_UPDATED 0x2 -#define Set_CCB_Type(x, type) \ - x->ccb_h.ccb_pflags &= ~SA_CCB_TYPEMASK; \ - x->ccb_h.ccb_pflags |= type - -#define CCB_Type(x) (x->ccb_h.ccb_pflags & SA_CCB_TYPEMASK) - - - typedef enum { SA_FLAG_OPEN = 0x0001, SA_FLAG_FIXED = 0x0002, @@ -250,18 +240,12 @@ * Latched Error Info */ struct { - struct scsi_sense_data _last_io_sense; - u_int64_t _last_io_resid; - u_int8_t _last_io_cdb[CAM_MAX_CDBLEN]; - struct scsi_sense_data _last_ctl_sense; - u_int64_t _last_ctl_resid; - u_int8_t _last_ctl_cdb[CAM_MAX_CDBLEN]; -#define last_io_sense errinfo._last_io_sense -#define last_io_resid errinfo._last_io_resid -#define last_io_cdb errinfo._last_io_cdb -#define last_ctl_sense errinfo._last_ctl_sense -#define last_ctl_resid errinfo._last_ctl_resid -#define last_ctl_cdb errinfo._last_ctl_cdb + struct scsi_sense_data _last_sense; + u_int64_t _last_resid; + u_int8_t _last_cdb[CAM_MAX_CDBLEN]; +#define last_sense errinfo._last_sense +#define last_resid errinfo._last_resid +#define last_cdb errinfo._last_cdb } errinfo; /* * Misc other flags/state @@ -1013,18 +997,10 @@ /* * Yes, we know that this is likely to overflow */ - if (softc->last_resid_was_io) { - if ((g->mt_resid = (short) softc->last_io_resid) != 0) { - if (SA_IS_CTRL(dev) == 0 || didlockperiph) { - softc->last_io_resid = 0; - } + if ((g->mt_resid = (short) softc->last_resid) != 0) { + if (SA_IS_CTRL(dev) == 0 || didlockperiph) { + softc->last_resid = 0; } - } else { - if ((g->mt_resid = (short)softc->last_ctl_resid) != 0) { - if (SA_IS_CTRL(dev) == 0 || didlockperiph) { - softc->last_ctl_resid = 0; - } - } } error = 0; break; @@ -1038,16 +1014,11 @@ ("saioctl: MTIOCERRSTAT\n")); bzero(sep, sizeof(*sep)); - sep->io_resid = softc->last_io_resid; - bcopy((caddr_t) &softc->last_io_sense, sep->io_sense, + sep->io_resid = softc->last_resid; + bcopy((caddr_t) &softc->last_sense, sep->io_sense, sizeof (sep->io_sense)); - bcopy((caddr_t) &softc->last_io_cdb, sep->io_cdb, + bcopy((caddr_t) &softc->last_cdb, sep->io_cdb, sizeof (sep->io_cdb)); - sep->ctl_resid = softc->last_ctl_resid; - bcopy((caddr_t) &softc->last_ctl_sense, sep->ctl_sense, - sizeof (sep->ctl_sense)); - bcopy((caddr_t) &softc->last_ctl_cdb, sep->ctl_cdb, - sizeof (sep->ctl_cdb)); if ((SA_IS_CTRL(dev) == 0 && softc->open_pending_mount) || didlockperiph) @@ -1835,7 +1806,6 @@ bp->bio_data, bp->bio_bcount, SSD_FULL_SIZE, IO_TIMEOUT); start_ccb->ccb_h.ccb_pflags &= ~SA_POSITION_UPDATED; - Set_CCB_Type(start_ccb, SA_CCB_BUFFER_IO); start_ccb->ccb_h.ccb_bp = bp; bp = bioq_first(&softc->bio_queue); xpt_action(start_ccb); @@ -1863,8 +1833,6 @@ softc = (struct sa_softc *)periph->softc; csio = &done_ccb->csio; - switch (CCB_Type(csio)) { - case SA_CCB_BUFFER_IO: { struct bio *bp; int error; @@ -1943,9 +1911,7 @@ bp->bio_resid, bp->bio_bcount)); } biofinish(bp, softc->device_stats, 0); - break; } - } xpt_release_ccb(done_ccb); } @@ -2401,8 +2367,7 @@ /* * Clear I/O residual. */ - softc->last_io_resid = 0; - softc->last_ctl_resid = 0; + softc->last_resid = 0; } return (error); } @@ -2498,21 +2463,11 @@ info /= softc->media_blksize; } } - if (CCB_Type(csio) == SA_CCB_BUFFER_IO) { - bcopy((caddr_t) sense, (caddr_t) &softc->last_io_sense, - sizeof (struct scsi_sense_data)); - bcopy(csio->cdb_io.cdb_bytes, softc->last_io_cdb, - (int) csio->cdb_len); - softc->last_io_resid = resid; - softc->last_resid_was_io = 1; - } else { - bcopy((caddr_t) sense, (caddr_t) &softc->last_ctl_sense, - sizeof (struct scsi_sense_data)); - bcopy(csio->cdb_io.cdb_bytes, softc->last_ctl_cdb, - (int) csio->cdb_len); - softc->last_ctl_resid = resid; - softc->last_resid_was_io = 0; - } + bcopy((caddr_t) sense, (caddr_t) &softc->last_sense, + sizeof (struct scsi_sense_data)); + bcopy(csio->cdb_io.cdb_bytes, softc->last_cdb, + (int) csio->cdb_len); + softc->last_resid = resid; CAM_DEBUG(periph->path, CAM_DEBUG_INFO, ("CDB[0]=0x%x Key 0x%x " "ASC/ASCQ 0x%x/0x%x CAM STATUS 0x%x flags 0x%x resid %jd " "dxfer_len %d\n", csio->cdb_io.cdb_bytes[0] & 0xff, @@ -3248,7 +3203,7 @@ /* * Clear residual because we will be using it. */ - softc->last_ctl_resid = 0; + softc->last_resid = 0; softc->dsreg = (count < 0)? MTIO_DSREG_REV : MTIO_DSREG_FWD; error = cam_periph_runccb(ccb, saerror, 0, 0, softc->device_stats); @@ -3280,14 +3235,14 @@ } else if (code == SS_SETMARKS || code == SS_EOD) { softc->fileno = softc->blkno = (daddr_t) -1; } else if (code == SS_FILEMARKS && softc->fileno != (daddr_t) -1) { - softc->fileno += (count - softc->last_ctl_resid); + softc->fileno += (count - softc->last_resid); if (softc->fileno < 0) /* we must of hit BOT */ softc->fileno = 0; softc->blkno = 0; } else if (code == SS_BLOCKS && softc->blkno != (daddr_t) -1) { - softc->blkno += (count - softc->last_ctl_resid); + softc->blkno += (count - softc->last_resid); if (count < 0) { - if (softc->last_ctl_resid || softc->blkno < 0) { + if (softc->last_resid || softc->blkno < 0) { if (softc->fileno == 0) { softc->blkno = 0; } else { @@ -3314,7 +3269,7 @@ /* * Clear residual because we will be using it. */ - softc->last_ctl_resid = 0; + softc->last_resid = 0; softc->dsreg = MTIO_DSREG_FMK; /* this *must* not be retried */ @@ -3327,7 +3282,7 @@ if (error == 0 && nmarks) { struct sa_softc *softc = (struct sa_softc *)periph->softc; - nwm = nmarks - softc->last_ctl_resid; + nwm = nmarks - softc->last_resid; softc->filemarks += nwm; } --gKMricLos+KVdGMg-- From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 30 22:10:08 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 743BA5A9; Wed, 30 Jul 2014 22:10:08 +0000 (UTC) Received: from uriah.heep.sax.de (uriah.heep.sax.de [IPv6:2a01:170:1047::9]) by mx1.freebsd.org (Postfix) with ESMTP id 2F69E2B2B; Wed, 30 Jul 2014 22:10:08 +0000 (UTC) Received: by uriah.heep.sax.de (Postfix, from userid 107) id 3345D267; Thu, 31 Jul 2014 00:10:07 +0200 (CEST) Date: Thu, 31 Jul 2014 00:10:07 +0200 From: Joerg Wunsch To: Alexander Motin , freebsd-scsi@freebsd.org, ken@freebsd.org Subject: Re: Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds Message-ID: <20140730221006.GA3579@uriah.heep.sax.de> Reply-To: Joerg Wunsch Mail-Followup-To: Joerg Wunsch , Alexander Motin , freebsd-scsi@freebsd.org, ken@freebsd.org References: <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> <20140730203315.0EED1295B@uriah.heep.sax.de> <20140730204200.4645729B8@uriah.heep.sax.de> <53D95F61.4080701@FreeBSD.org> <20140730215113.GA3564@uriah.heep.sax.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140730215113.GA3564@uriah.heep.sax.de> 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 X-GPG-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 User-Agent: Mutt/1.5.23 (2014-03-12) 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 22:10:08 -0000 As Joerg Wunsch wrote: > Ken, I think that entire CCB_Type stuff can go away then as it is not > used anymore. The only side-effect I see is that parts of > MTIOCERRSTAT are rendered useless now, as the distinction between > control and IO transfers is gone. This probably means mt(1) simply cannot distinguish between both anymore, and only report about the last command and last sense. Probably not a big loss. > Attached is a suggested patch. So far, I only compile-tested it. Rebooted and tested. It fixes the "mt fsf 32767" issue, I get correct reports about the number of files again (so hopefully, Bacula will also do then). -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi@FreeBSD.ORG Thu Jul 31 03:58:04 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7951D3A8; Thu, 31 Jul 2014 03:58:04 +0000 (UTC) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F0BEF2EE8; Thu, 31 Jul 2014 03:58:03 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.9/8.14.2) with ESMTP id s6V3vuT0091536; Wed, 30 Jul 2014 21:57:56 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.9/8.14.9/Submit) id s6V3vucP091535; Wed, 30 Jul 2014 21:57:56 -0600 (MDT) (envelope-from ken) Date: Wed, 30 Jul 2014 21:57:56 -0600 From: "Kenneth D. Merry" To: Joerg Wunsch , Alexander Motin , freebsd-scsi@freebsd.org Subject: Re: Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds Message-ID: <20140731035756.GA91452@nargothrond.kdm.org> References: <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> <20140730203315.0EED1295B@uriah.heep.sax.de> <20140730204200.4645729B8@uriah.heep.sax.de> <53D95F61.4080701@FreeBSD.org> <20140730215113.GA3564@uriah.heep.sax.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140730215113.GA3564@uriah.heep.sax.de> User-Agent: Mutt/1.5.23 (2014-03-12) 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: Thu, 31 Jul 2014 03:58:04 -0000 On Wed, Jul 30, 2014 at 23:51:14 +0200, Joerg Wunsch wrote: > As Alexander Motin wrote: > > > Yes, that was me who removed that second type handling from sastart(). > > The same was done for all other drivers as part of CAM simplification > > efforts. Probably I missed the fact that sa(4) uses that type for > > something else. > > Well, a quick glance at the remainder of the driver shows that the > typemask is just a single bit, so if you remove one of its possible > values, you should have questioned the entire type field/mask in turn, > as it became useless then. > > #define SA_CCB_BUFFER_IO 0x0 > #define SA_CCB_TYPEMASK 0x1 > #define SA_POSITION_UPDATED 0x2 > > #define Set_CCB_Type(x, type) \ > x->ccb_h.ccb_pflags &= ~SA_CCB_TYPEMASK; \ > x->ccb_h.ccb_pflags |= type > > SA_CCB_BUFFER_WAITING was indeed not tested anywhere else, but there > are decisions based on SA_CCB_BUFFER_IO (which used to be the opposite > of SA_CCB_BUFFER_WAITING). These decisions now became random > decisions. :-( Ahh, that explains it. > > So while type may indeed be restored (I have no idea > > about that aspect of sa(4) driver, neither have hardware to test it) > > Not having the hardware doesn't seem to be a good base for modifying > the driver in the first place to me. > > Ken, I think that entire CCB_Type stuff can go away then as it is not > used anymore. The only side-effect I see is that parts of > MTIOCERRSTAT are rendered useless now, as the distinction between > control and IO transfers is gone. I think it would be good to keep the ability to report to the application or the user what happened with control and data commands, especially since you may wind up having errors on both types of commands in some cases. (e.g. end of media notification on a write, and then perhaps an issue in writing the filemarks.) I've been thinking about implementing an updated version of the MTIOCERRSTAT ioctl that extends the amount of sense data available. (Along with that, it would give the actual sense length, so that the caller knows how much of the data is valid.) The other change I've been planning on is to get mt to actually decode the sense information. That should be easy once we have the amount of valid sense data reported in the ioctl. My current set of patches greatly increase the amount of data available to applications; most of it is reported via XML. So this would be going along with the general theme of giving the user / application more information and control if they want it. > Unfortunately, the new Bugzilla doesn't seem to accept me (I tried > Peter Wemm's description about kinit / kpasswd), so I cannot open > a bug report for it. > > Attached is a suggested patch. So far, I only compile-tested it. As I said, I think it would be better to keep the ability to report both control and I/O errors. If I have time tomorrow I'll try to come up with something. (Or you can if you have the time.) Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Thu Jul 31 06:09:38 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4810C99; Thu, 31 Jul 2014 06:09:38 +0000 (UTC) Received: from uriah.heep.sax.de (uriah.heep.sax.de [213.240.137.9]) by mx1.freebsd.org (Postfix) with ESMTP id 8FE122AB3; Thu, 31 Jul 2014 06:09:38 +0000 (UTC) Received: by uriah.heep.sax.de (Postfix, from userid 107) id 5D79E2612; Thu, 31 Jul 2014 08:09:36 +0200 (CEST) Date: Thu, 31 Jul 2014 08:09:36 +0200 From: Joerg Wunsch To: freebsd-scsi@freebsd.org Subject: Re: Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds Message-ID: <20140731060936.GB4095@uriah.heep.sax.de> Reply-To: Joerg Wunsch Mail-Followup-To: Joerg Wunsch , freebsd-scsi@freebsd.org, "Kenneth D. Merry" References: <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> <20140730203315.0EED1295B@uriah.heep.sax.de> <20140730204200.4645729B8@uriah.heep.sax.de> <53D95F61.4080701@FreeBSD.org> <20140730215113.GA3564@uriah.heep.sax.de> <20140731035756.GA91452@nargothrond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140731035756.GA91452@nargothrond.kdm.org> 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 X-GPG-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "Kenneth D. Merry" 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: Thu, 31 Jul 2014 06:09:38 -0000 As Kenneth D. Merry wrote: > > SA_CCB_BUFFER_WAITING was indeed not tested anywhere else, but there > > are decisions based on SA_CCB_BUFFER_IO (which used to be the opposite > > of SA_CCB_BUFFER_WAITING). These decisions now became random > > decisions. :-( > > Ahh, that explains it. That's also what I thought then ... in particular, it explains why I have seen one situation where the status has been reported correctly. > I think it would be good to keep the ability to report to the application > or the user what happened with control and data commands, especially since > you may wind up having errors on both types of commands in some cases. > (e.g. end of media notification on a write, and then perhaps an issue in > writing the filemarks.) OK, then it needs some more work. > > Unfortunately, the new Bugzilla doesn't seem to accept me (I tried > > Peter Wemm's description about kinit / kpasswd), so I cannot open > > a bug report for it. Meanwhile Eitan Adler helped me a bit, so the bug report is at: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192285 That way, it has been officially recorded, so we can take the time needed for a real fix. > > Attached is a suggested patch. So far, I only compile-tested it. > > As I said, I think it would be better to keep the ability to report both > control and I/O errors. If I have time tomorrow I'll try to come up with > something. (Or you can if you have the time.) There's no longer any hurry on it now. My patch^H^H^H^H^Hhack works, Bacula could successfully write to the tape automatically for the first time. I'll try looking into an improved version, but I wouldn't want to do too radical changes in order to not cause too much potential for conflict in your other pending patches. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi@FreeBSD.ORG Thu Jul 31 09:14:25 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 BC54D8CE; Thu, 31 Jul 2014 09:14:25 +0000 (UTC) Received: from uriah.heep.sax.de (uriah.heep.sax.de [IPv6:2a01:170:1047::9]) by mx1.freebsd.org (Postfix) with ESMTP id 5DF752F62; Thu, 31 Jul 2014 09:14:25 +0000 (UTC) Received: by uriah.heep.sax.de (Postfix, from userid 107) id 045902CD4; Thu, 31 Jul 2014 11:14:22 +0200 (CEST) Date: Thu, 31 Jul 2014 11:14:22 +0200 From: Joerg Wunsch To: freebsd-scsi@freebsd.org, "Kenneth D. Merry" Subject: Re: Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds Message-ID: <20140731091422.GA37239@uriah.heep.sax.de> Mail-Followup-To: Joerg Wunsch , freebsd-scsi@freebsd.org, "Kenneth D. Merry" References: <20140730035230.GA81800@nargothrond.kdm.org> <20140730060330.GA3272@uriah.heep.sax.de> <20140730153229.GA86368@nargothrond.kdm.org> <20140730191915.9B944267B@uriah.heep.sax.de> <20140730203315.0EED1295B@uriah.heep.sax.de> <20140730204200.4645729B8@uriah.heep.sax.de> <53D95F61.4080701@FreeBSD.org> <20140730215113.GA3564@uriah.heep.sax.de> <20140731035756.GA91452@nargothrond.kdm.org> <20140731060936.GB4095@uriah.heep.sax.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="RnlQjJ0d97Da+TV1" Content-Disposition: inline In-Reply-To: <20140731060936.GB4095@uriah.heep.sax.de> 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 X-GPG-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 User-Agent: Mutt/1.5.23 (2014-03-12) 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: Thu, 31 Jul 2014 09:14:25 -0000 --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline As Joerg Wunsch wrote: > > I think it would be good to keep the ability to report to the application > > or the user what happened with control and data commands, especially since > > you may wind up having errors on both types of commands in some cases. > > (e.g. end of media notification on a write, and then perhaps an issue in > > writing the filemarks.) > > OK, then it needs some more work. Next attempt: in saerror(), rather than basing the decision whether this status report belongs to a read/write or control operation on some CCB flag that needs to be set explicitly, base it on the actual command that led to the status report (SA_READ or SA_WRITE vs. anything else). A similar decision is already done in saerror(). I think this keeps the spirit of the existing implementation as much as possible. So far, only compile-tested. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) --RnlQjJ0d97Da+TV1 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="scsi_sa.c.diff" Index: scsi_sa.c =================================================================== --- scsi_sa.c (revision 269317) +++ scsi_sa.c (working copy) @@ -113,18 +113,10 @@ #define ccb_pflags ppriv_field0 #define ccb_bp ppriv_ptr1 -#define SA_CCB_BUFFER_IO 0x0 -#define SA_CCB_TYPEMASK 0x1 -#define SA_POSITION_UPDATED 0x2 +/* bits in ccb_pflags */ +#define SA_POSITION_UPDATED 0x1 -#define Set_CCB_Type(x, type) \ - x->ccb_h.ccb_pflags &= ~SA_CCB_TYPEMASK; \ - x->ccb_h.ccb_pflags |= type -#define CCB_Type(x) (x->ccb_h.ccb_pflags & SA_CCB_TYPEMASK) - - - typedef enum { SA_FLAG_OPEN = 0x0001, SA_FLAG_FIXED = 0x0002, @@ -1835,7 +1827,6 @@ bp->bio_data, bp->bio_bcount, SSD_FULL_SIZE, IO_TIMEOUT); start_ccb->ccb_h.ccb_pflags &= ~SA_POSITION_UPDATED; - Set_CCB_Type(start_ccb, SA_CCB_BUFFER_IO); start_ccb->ccb_h.ccb_bp = bp; bp = bioq_first(&softc->bio_queue); xpt_action(start_ccb); @@ -1860,92 +1851,86 @@ { struct sa_softc *softc; struct ccb_scsiio *csio; + struct bio *bp; + int error; softc = (struct sa_softc *)periph->softc; csio = &done_ccb->csio; - switch (CCB_Type(csio)) { - case SA_CCB_BUFFER_IO: - { - struct bio *bp; - int error; - softc->dsreg = MTIO_DSREG_REST; - bp = (struct bio *)done_ccb->ccb_h.ccb_bp; - error = 0; - if ((done_ccb->ccb_h.status & CAM_STATUS_MASK) != CAM_REQ_CMP) { - if ((error = saerror(done_ccb, 0, 0)) == ERESTART) { - /* - * A retry was scheduled, so just return. - */ - return; - } + softc->dsreg = MTIO_DSREG_REST; + bp = (struct bio *)done_ccb->ccb_h.ccb_bp; + error = 0; + if ((done_ccb->ccb_h.status & CAM_STATUS_MASK) != CAM_REQ_CMP) { + if ((error = saerror(done_ccb, 0, 0)) == ERESTART) { + /* + * A retry was scheduled, so just return. + */ + return; } + } - if (error == EIO) { + if (error == EIO) { - /* - * Catastrophic error. Mark the tape as frozen - * (we no longer know tape position). - * - * Return all queued I/O with EIO, and unfreeze - * our queue so that future transactions that - * attempt to fix this problem can get to the - * device. - * - */ + /* + * Catastrophic error. Mark the tape as frozen + * (we no longer know tape position). + * + * Return all queued I/O with EIO, and unfreeze + * our queue so that future transactions that + * attempt to fix this problem can get to the + * device. + * + */ - softc->flags |= SA_FLAG_TAPE_FROZEN; - bioq_flush(&softc->bio_queue, NULL, EIO); + softc->flags |= SA_FLAG_TAPE_FROZEN; + bioq_flush(&softc->bio_queue, NULL, EIO); + } + if (error != 0) { + bp->bio_resid = bp->bio_bcount; + bp->bio_error = error; + bp->bio_flags |= BIO_ERROR; + /* + * In the error case, position is updated in saerror. + */ + } else { + bp->bio_resid = csio->resid; + bp->bio_error = 0; + if (csio->resid != 0) { + bp->bio_flags |= BIO_ERROR; } - if (error != 0) { - bp->bio_resid = bp->bio_bcount; - bp->bio_error = error; - bp->bio_flags |= BIO_ERROR; - /* - * In the error case, position is updated in saerror. - */ - } else { - bp->bio_resid = csio->resid; - bp->bio_error = 0; - if (csio->resid != 0) { - bp->bio_flags |= BIO_ERROR; - } - if (bp->bio_cmd == BIO_WRITE) { - softc->flags |= SA_FLAG_TAPE_WRITTEN; - softc->filemarks = 0; - } - if (!(csio->ccb_h.ccb_pflags & SA_POSITION_UPDATED) && - (softc->blkno != (daddr_t) -1)) { - if ((softc->flags & SA_FLAG_FIXED) != 0) { - u_int32_t l; - if (softc->blk_shift != 0) { - l = bp->bio_bcount >> - softc->blk_shift; - } else { - l = bp->bio_bcount / - softc->media_blksize; - } - softc->blkno += (daddr_t) l; + if (bp->bio_cmd == BIO_WRITE) { + softc->flags |= SA_FLAG_TAPE_WRITTEN; + softc->filemarks = 0; + } + if (!(csio->ccb_h.ccb_pflags & SA_POSITION_UPDATED) && + (softc->blkno != (daddr_t) -1)) { + if ((softc->flags & SA_FLAG_FIXED) != 0) { + u_int32_t l; + if (softc->blk_shift != 0) { + l = bp->bio_bcount >> + softc->blk_shift; } else { - softc->blkno++; + l = bp->bio_bcount / + softc->media_blksize; } + softc->blkno += (daddr_t) l; + } else { + softc->blkno++; } } - /* - * If we had an error (immediate or pending), - * release the device queue now. - */ - if (error || (softc->flags & SA_FLAG_ERR_PENDING)) - cam_release_devq(done_ccb->ccb_h.path, 0, 0, 0, 0); - if (error || bp->bio_resid) { - CAM_DEBUG(periph->path, CAM_DEBUG_INFO, - ("error %d resid %ld count %ld\n", error, - bp->bio_resid, bp->bio_bcount)); - } - biofinish(bp, softc->device_stats, 0); - break; } + /* + * If we had an error (immediate or pending), + * release the device queue now. + */ + if (error || (softc->flags & SA_FLAG_ERR_PENDING)) + cam_release_devq(done_ccb->ccb_h.path, 0, 0, 0, 0); + if (error || bp->bio_resid) { + CAM_DEBUG(periph->path, CAM_DEBUG_INFO, + ("error %d resid %ld count %ld\n", error, + bp->bio_resid, bp->bio_bcount)); } + biofinish(bp, softc->device_stats, 0); xpt_release_ccb(done_ccb); } @@ -2498,7 +2483,8 @@ info /= softc->media_blksize; } } - if (CCB_Type(csio) == SA_CCB_BUFFER_IO) { + if (csio->cdb_io.cdb_bytes[0] == SA_READ || + csio->cdb_io.cdb_bytes[0] == SA_WRITE) { bcopy((caddr_t) sense, (caddr_t) &softc->last_io_sense, sizeof (struct scsi_sense_data)); bcopy(csio->cdb_io.cdb_bytes, softc->last_io_cdb, --RnlQjJ0d97Da+TV1-- From owner-freebsd-scsi@FreeBSD.ORG Thu Jul 31 20:17:45 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 462B9AF2; Thu, 31 Jul 2014 20:17:45 +0000 (UTC) Received: from uriah.heep.sax.de (uriah.heep.sax.de [213.240.137.9]) by mx1.freebsd.org (Postfix) with ESMTP id C0EE2220C; Thu, 31 Jul 2014 20:17:44 +0000 (UTC) Received: by uriah.heep.sax.de (Postfix, from userid 107) id ACF8A403; Thu, 31 Jul 2014 22:17:42 +0200 (CEST) Date: Thu, 31 Jul 2014 22:17:42 +0200 From: Joerg Wunsch To: freebsd-scsi@freebsd.org, "Kenneth D. Merry" Subject: Re: Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds Message-ID: <20140731201742.GA4358@uriah.heep.sax.de> Mail-Followup-To: Joerg Wunsch , freebsd-scsi@freebsd.org, "Kenneth D. Merry" References: <20140730060330.GA3272@uriah.heep.sax.de> <20140730153229.GA86368@nargothrond.kdm.org> <20140730191915.9B944267B@uriah.heep.sax.de> <20140730203315.0EED1295B@uriah.heep.sax.de> <20140730204200.4645729B8@uriah.heep.sax.de> <53D95F61.4080701@FreeBSD.org> <20140730215113.GA3564@uriah.heep.sax.de> <20140731035756.GA91452@nargothrond.kdm.org> <20140731060936.GB4095@uriah.heep.sax.de> <20140731091422.GA37239@uriah.heep.sax.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140731091422.GA37239@uriah.heep.sax.de> 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 X-GPG-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 User-Agent: Mutt/1.5.23 (2014-03-12) 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: Thu, 31 Jul 2014 20:17:45 -0000 As Joerg Wunsch wrote: > Next attempt: in saerror(), rather than basing the decision whether > this status report belongs to a read/write or control operation on > some CCB flag that needs to be set explicitly, base it on the actual > command that led to the status report (SA_READ or SA_WRITE > vs. anything else). A similar decision is already done in saerror(). Now, tested for real, too. I am content with that patch, and would be willing to commit it. Note that much of the changes there are whitespace changes only since I removed a switch/case statement where Alexander Motin only left a single case in, so a large block of code is unindented by one TAB now. Here's a typescript of handling a real Bacula tape with the suggested patch. Script started on Thu Jul 31 21:58:26 2014 root@uriah:/tmp # mt stat Mode Density Blocksize bpi Compression Current: 0x41:DLTapeIV(40GB) variable 98250 IDRC ---------available modes--------- 0: 0x41:DLTapeIV(40GB) variable 98250 IDRC 1: 0x41:DLTapeIV(40GB) variable 98250 IDRC 2: 0x41:DLTapeIV(40GB) variable 98250 IDRC 3: 0x41:DLTapeIV(40GB) variable 98250 IDRC --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 0 Record Number: 0 Residual Count 0 root@uriah:/tmp # mt fsf 32767 root@uriah:/tmp # mt stat Mode Density Blocksize bpi Compression Current: 0x41:DLTapeIV(40GB) variable 98250 IDRC ---------available modes--------- 0: 0x41:DLTapeIV(40GB) variable 98250 IDRC 1: 0x41:DLTapeIV(40GB) variable 98250 IDRC 2: 0x41:DLTapeIV(40GB) variable 98250 IDRC 3: 0x41:DLTapeIV(40GB) variable 98250 IDRC --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 49 Record Number: 0 Residual Count 0 root@uriah:/tmp # mt errstat Last I/O Residual: 0 Last I/O Command: 08 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 Last I/O Sense: F0 00 20 FF FF 24 00 16 00 00 00 01 00 00 00 00 00 00 80 08 B7 00 00 8B AB 00 96 30 C7 00 00 00 Last Control Residual: 0 Last Control Command: 11 01 00 7F FF 00 00 00 00 00 00 00 00 00 00 00 Last Control Sense: F0 00 08 00 00 7F CE 16 00 0A 19 B2 00 05 00 00 00 00 80 08 B7 00 00 8B AB 00 18 C7 BA 00 00 00 root@uriah:/tmp # mt rewind root@uriah:/tmp # exit exit Script done on Thu Jul 31 22:02:15 2014 -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi@FreeBSD.ORG Thu Jul 31 21:17:04 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A74A831A for ; Thu, 31 Jul 2014 21:17:04 +0000 (UTC) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B4CB28E2 for ; Thu, 31 Jul 2014 21:17:04 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.9/8.14.2) with ESMTP id s6VLH2v8098476; Thu, 31 Jul 2014 15:17:02 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.9/8.14.9/Submit) id s6VLH2ij098475; Thu, 31 Jul 2014 15:17:02 -0600 (MDT) (envelope-from ken) Date: Thu, 31 Jul 2014 15:17:02 -0600 From: "Kenneth D. Merry" To: Joerg Wunsch , freebsd-scsi@freebsd.org Subject: Re: Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds Message-ID: <20140731211702.GA98465@nargothrond.kdm.org> References: <20140730153229.GA86368@nargothrond.kdm.org> <20140730191915.9B944267B@uriah.heep.sax.de> <20140730203315.0EED1295B@uriah.heep.sax.de> <20140730204200.4645729B8@uriah.heep.sax.de> <53D95F61.4080701@FreeBSD.org> <20140730215113.GA3564@uriah.heep.sax.de> <20140731035756.GA91452@nargothrond.kdm.org> <20140731060936.GB4095@uriah.heep.sax.de> <20140731091422.GA37239@uriah.heep.sax.de> <20140731201742.GA4358@uriah.heep.sax.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140731201742.GA4358@uriah.heep.sax.de> User-Agent: Mutt/1.5.23 (2014-03-12) 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: Thu, 31 Jul 2014 21:17:04 -0000 On Thu, Jul 31, 2014 at 22:17:42 +0200, Joerg Wunsch wrote: > As Joerg Wunsch wrote: > > > Next attempt: in saerror(), rather than basing the decision whether > > this status report belongs to a read/write or control operation on > > some CCB flag that needs to be set explicitly, base it on the actual > > command that led to the status report (SA_READ or SA_WRITE > > vs. anything else). A similar decision is already done in saerror(). > > Now, tested for real, too. > > I am content with that patch, and would be willing to commit it. Okay, it looks good to me; go ahead and commit it. > Note that much of the changes there are whitespace changes only since > I removed a switch/case statement where Alexander Motin only left a > single case in, so a large block of code is unindented by one TAB now. > > Here's a typescript of handling a real Bacula tape with the suggested > patch. Great, thanks for tracking this down! Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 1 05:15:49 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDA63EB7 for ; Fri, 1 Aug 2014 05:15:48 +0000 (UTC) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6CAC22410 for ; Fri, 1 Aug 2014 05:15:47 +0000 (UTC) Received: from mail-qa0-f54.google.com ([209.85.216.54]) (using TLSv1) by exprod7ob128.postini.com ([64.18.6.12]) with SMTP ID DSNKU9sigiEjJmCssxe9hvyIjo46VhBFIGC3@postini.com; Thu, 31 Jul 2014 22:15:48 PDT Received: by mail-qa0-f54.google.com with SMTP id k15so3451529qaq.27 for ; Thu, 31 Jul 2014 22:15:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=9LFXvrCEPqBJUFPexoO7CkBKQ0nFOzFd0PjO3f8NgFU=; b=FTLOlyus1wCvBC4/tA3QWc5FsiX0gFJ8pq4bdF5Lrbq94Tc66B5xSBr4l5Noj8Txou xWLTKNxiAQgFdUt2xArPXM+YULA5LDJl2xlUn2BmQfPkn/L4A/5BfVlZ9y5j6V5UUiqd /fK60+9j+s7cwIwluV/uZ6ETuQnH0EOJH8Wh44FezIvj/x4+lpCJEGvXmyObOXNy/PDn hQi5guw5p2l/OaC+D5Ey+owgkUIrjykPVX0Ks1lNPNVOd0yFQGicB/nmv9oJ17r/6NHT y2b8gPpO8GIT5F7Uo1sfA3NQsmormYjb+WSZX5WF604n8pCyyHs7JECOTlE0BioJonKt acsQ== X-Gm-Message-State: ALoCoQk9I0UWBqAYdqK09bE4eCJNFE8QW3YnUfu197Pqv/kwmLxbA7Sf8tDIYIvMkIOGxrgPe9HlMIbVDsPTEWlAZqExhRkuhpugP1pbEkottVdkJpMv3bxB3x9oWeDsAXCq65JoLjC5WAdVrQP28ME8e/CH3RMq4Q== X-Received: by 10.224.53.137 with SMTP id m9mr4871847qag.66.1406870146301; Thu, 31 Jul 2014 22:15:46 -0700 (PDT) X-Received: by 10.224.53.137 with SMTP id m9mr4871832qag.66.1406870146163; Thu, 31 Jul 2014 22:15:46 -0700 (PDT) From: Sumit Saxena References: <559aba5a124ee1e32ddffb1380399e28@mail.gmail.com> <20140624130840.GK1560@funkthat.com> <6f92e2e229eaea86429826ce5085e495@mail.gmail.com> <20140710092108.GU45513@funkthat.com> c0e8d27445599f47adb6df0eb5465882@mail.gmail.com <0c7840168feaf80c91d4e9067d916998@mail.gmail.com> c3f72a4da049262aa68d61cf6ddab59b@mail.gmail.com In-Reply-To: c3f72a4da049262aa68d61cf6ddab59b@mail.gmail.com MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHrqZ/meEJEiDrDuvx3ccVdJK+lWgGJHJxVAm5QnooB5ICeqgK1uMXUmzCn14CADgaZEA== Date: Fri, 1 Aug 2014 10:45:45 +0530 Message-ID: Subject: RE: Kernel panic: message secondary GPT header is not in the last LBA To: John-Mark Gurney Content-Type: text/plain; charset=UTF-8 Cc: freebsd-scsi@freebsd.org, Kashyap Desai 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: Fri, 01 Aug 2014 05:15:49 -0000 >-----Original Message----- >From: Sumit Saxena [mailto:sumit.saxena@avagotech.com] >Sent: Wednesday, July 23, 2014 12:36 PM >To: 'John-Mark Gurney' >Cc: Kashyap Desai; 'freebsd-scsi@freebsd.org' >Subject: RE: Kernel panic: message secondary GPT header is not in the last >LBA > > > >>-----Original Message----- >>From: Sumit Saxena [mailto:sumit.saxena@avagotech.com] >>Sent: Wednesday, July 16, 2014 6:03 PM >>To: John-Mark Gurney >>Cc: Kashyap Desai >>Subject: RE: Kernel panic: message secondary GPT header is not in the >>last LBA >> >>>-----Original Message----- >>>From: Sumit Saxena [mailto:sumit.saxena@avagotech.com] >>>Sent: Monday, July 14, 2014 5:28 PM >>>To: 'John-Mark Gurney' >>>Subject: RE: Kernel panic: message secondary GPT header is not in the >>last LBA >>> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: John-Mark Gurney [mailto:jmg@funkthat.com] >>>>Sent: Thursday, July 10, 2014 2:51 PM >>>>To: Sumit Saxena >>>>Cc: freebsd-scsi@freebsd.org; Kashyap Desai >>>>Subject: Re: Kernel panic: message secondary GPT header is not in the >>>>last LBA >>>> >>>>Sumit Saxena wrote this message on Wed, Jul 09, 2014 at 16:09 +0530: >>>>> >-----Original Message----- >>>>> >From: John-Mark Gurney [mailto:jmg@funkthat.com] >>>>> >Sent: Tuesday, June 24, 2014 6:39 PM >>>>> >To: Sumit Saxena >>>>> >Cc: freebsd-scsi@freebsd.org; Kashyap Desai >>>>> >Subject: Re: Kernel panic: message secondary GPT header is not in >>>>> >the >>>>> last >>>>> >LBA >>>>> > >>>>> >Sumit Saxena wrote this message on Tue, Jun 24, 2014 at 18:27 +0530: >>>>> >> Hi All, >>>>> >> >>>>> >> >>>>> >> >>>>> >> While doing some testing on driver, I am facing kernel >>>>> >> panic inside GEOM module. I am using FreeBSD10.0 64bit, >>>>> >> installed on Virtual drive connected behind LSI MegaRAID SAS >>>>> >> 9361 controller and two >>>>> >> Enclosures- Dell MD1220 with total 39 drives are connected to >>>>> >> the controller. As I convert unconfigured drives(connected to >>>>> >> Enclosures) to JBOD(plain drive without any RAID configuration >>>>> >> exposed to OS), kernel panic is observed inside GEOM module with >>>>> >> below traces- >>>>> >> >>>>> >> >>>>> >> >>>>> >> =================================================== >>>>> >> >>>>> >> ses1: phy 0: protocols: Initiator( None ) Target( SSP ) >>>>> >> >>>>> >> ses1: phy 0: parent 50080e5223c0f03f addr 5000c5001afebe51 >>>>> >> >>>>> >> ses1: pass30,da26: Element descriptor: 'SLOT 20 ' >>>>> >> >>>>> >> ses1: pass30,da26: SAS Device Slot Element: 1 Phys at Slot 20, >>>>> >> Not All Phys >>>>> >> >>>>> >> ses1: phy 0: SAS device type 1 id 0 >>>>> >> >>>>> >> ses1: phy 0: protocols: Initiator( None ) Target( SSP ) >>>>> >> >>>>> >> ses1: phy 0: parent 50080e5223c0f03f addr 5000c5004cf152f1 >>>>> >> >>>>> >> ses1: pass37,da33: Element descriptor: 'SLOT 21 ' >>>>> >> >>>>> >> ses1: pass37,da33: SAS Device Slot Element: 1 Phys at Slot 21, >>>>> >> Not All Phys >>>>> >> >>>>> >> ses1: phy 0: SAS device type 1 id 0 >>>>> >> >>>>> >> ses1: phy 0: protocols: Initiator( None ) Target( SSP ) >>>>> >> >>>>> >> ses1: phy 0: parent 50080e5223c0f03f addr 5000c5001afd3659 >>>>> >> >>>>> >> ses1: pass21,da17: Element descriptor: 'SLOT 22 ' >>>>> >> >>>>> >> ses1: pass21,da17: SAS Device Slot Element: 1 Phys at Slot 22, >>>>> >> Not All Phys >>>>> >> >>>>> >> ses1: phy 0: SAS device type 1 id 0 >>>>> >> >>>>> >> ses1: phy 0: protocols: Initiator( None ) Target( SSP ) >>>>> >> >>>>> >> ses1: phy 0: parent 50080e5223c0f03f addr 5000cca00baf22c1 >>>>> >> >>>>> >> GEOM: da12: the secondary GPT header is not in the last LBA. >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> Fatal trap 18: integer divide fault while in kernel mode >>>>> >> >>>>> >> cpuid = 4; apic id = 10 >>>>> >> >>>>> >> instruction pointer = 0x20:0xffffffff80805045 >>>>> >> >>>>> >> stack pointer = 0x28:0xfffffe0c23ded9e0 >>>>> >> >>>>> >> frame pointer = 0x28:0xfffffe0c23deda30 >>>>> >> >>>>> >> code segment = base 0x0, limit 0xfffff, type 0x1b >>>>> >> >>>>> >> = DPL 0, pres 1, >>>>> >> long 1, >>>>> >> def32 0, gran 1 >>>>> >> >>>>> >> processor eflags = interrupt enabled, resume, IOPL = >>0 >>>>> >> >>>>> >> current process = 13 (g_event) >>>>> >> >>>>> >> trap number = 18 >>>>> >> >>>>> >> panic: integer divide fault >>>>> >> >>>>> >> cpuid = 4 >>>>> >> >>>>> >> KDB: stack backtrace: >>>>> >> >>>>> >> #0 0xffffffff808cb220 at kdb_backtrace+0x60 >>>>> >> >>>>> >> #1 0xffffffff80892d05 at panic+0x155 >>>>> >> >>>>> >> #2 0xffffffff80c71ae2 at trap_fatal+0x3a2 >>>>> >> >>>>> >> #3 0xffffffff80c7171f at trap+0x7bf >>>>> >> >>>>> >> #4 0xffffffff80c587e2 at calltrap+0x8 >>>>> >> >>>>> >> #5 0xffffffff80803574 at g_label_taste+0x3a4 >>>>> >> >>>>> >> #6 0xffffffff80802106 at g_new_provider_event+0xb6 >>>>> >> >>>>> >> #7 0xffffffff807fe1d6 at g_run_events+0x166 >>>>> >> >>>>> >> #8 0xffffffff80864dda at fork_exit+0x9a >>>>> >> >>>>> >> #9 0xffffffff80c58d1e at fork_trampoline+0xe >>>>> >> >>>>> >> Uptime: 4m48s >>>>> >> >>>>> >> kernel trap 12 with interrupts disabled >>>>> > >>>>> >Can you run w/ DDB enabled and get a dump? >>>>> > >>>>> >an integer divide makes me think of a divide by zero error... Are >>>>> >you >>>>> sure >>>>> >things like sector size are set properly? >>>>> >>>>> Sorry for delay in response, sector size and other disk parameters >>>>> are set properly(verified by "diskinfo"), same set of drives works >>well on >>>linux. >>>>> We are not able to collect dump, enabled DDB but dump Is not >>>>> getting collected. Partial dump is getting copied sometimes[seen >>>>> message on console while dumping]. >>>> >>>>Can you run: >>>>addr2line -e /boot/kernel/kernel.symbols 0xffffffff80803574 >>>> >>>>This should give us the line number that the panic is happening on, >>>>and help debug it.. >>>> >>>>Also, is this FreeBSD 10.0-R? or is there a patch level associated w/ >>>>it? Easiest way to figure out is to include uname -a in the email so >>>>we know exactly what kernel source you are using.. >> >>I am using releases FreeBSD 10.0, no patch on top of that. >>> >>>Thanks for your help. I am able to capture vmcore on kenel panic, but >>can't >>>share that over overmail(size is 386MB) and does not have any common >>>location to share vmcore with you. >>>Do you have any common location, where I can share vmcore. Meanwhile I >>>will also do some debugging from my end also. Any pointers from you >>>for debugging the vmcore will be highly appreciated, as I am keen to >>>learn FreebSD kernel debugging techniques. >>> I have attached core.txt for your reference. >> >>I have observed that the issue hits, if there are some drives with GPT >>partition are attached to the controller. > >Has anyone observed the same issue, when there are drives present in the >setup with GPT partitions? Gentle ping!! > >> >>> >>>> >>>>Thanks. >>>> >>>>-- >>>> John-Mark Gurney Voice: +1 415 225 5579 >>>> >>>> "All that I will do, has been done, All that I have, has not." From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 1 17:31:03 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D61BCEC7 for ; Fri, 1 Aug 2014 17:31:03 +0000 (UTC) Received: from uriah.heep.sax.de (uriah.heep.sax.de [IPv6:2a01:170:1047::9]) by mx1.freebsd.org (Postfix) with ESMTP id 928062CAD for ; Fri, 1 Aug 2014 17:31:03 +0000 (UTC) Received: by uriah.heep.sax.de (Postfix, from userid 107) id D833028CB; Fri, 1 Aug 2014 19:31:01 +0200 (CEST) Mime-Version: 1.0 Sender: j@uriah.heep.sax.de X-Newsreader: knews 1.0b.1 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) 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: <20140730153229.GA86368@nargothrond.kdm.org> <20140730191915.9B944267B@uriah.heep.sax.de> <20140730203315.0EED1295B@uriah.heep.sax.de> <20140730204200.4645729B8@uriah.heep.sax.de> <53D95F61.4080701@FreeBSD.org> <20140730215113.GA3564@uriah.heep.sax.de> <20140731035756.GA91452@nargothrond.kdm.org> <20140731060936.GB4095@uriah.heep.sax.de> <20140731091422.GA37239@uriah.heep.sax.de> <20140731201742.GA4358@uriah.heep.sax.de> <20140731211702.GA98465@nargothrond.kdm.org> In-Reply-To: <20140731211702.GA98465@nargothrond.kdm.org> 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: <20140801173101.D833028CB@uriah.heep.sax.de> Date: Fri, 1 Aug 2014 19:31:01 +0200 (CEST) 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: Fri, 01 Aug 2014 17:31:03 -0000 "Kenneth D. Merry" wrote: >> I am content with that patch, and would be willing to commit it. > > Okay, it looks good to me; go ahead and commit it. Committed, thanks for the review! -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 1 21:08:32 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 D64EFB3C for ; Fri, 1 Aug 2014 21:08:32 +0000 (UTC) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9AD402764 for ; Fri, 1 Aug 2014 21:08:32 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.9/8.14.2) with ESMTP id s71L8P48007687; Fri, 1 Aug 2014 15:08:25 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.9/8.14.9/Submit) id s71L8PnQ007686; Fri, 1 Aug 2014 15:08:25 -0600 (MDT) (envelope-from ken) Date: Fri, 1 Aug 2014 15:08:25 -0600 From: "Kenneth D. Merry" To: Joerg Wunsch Subject: Re: Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds Message-ID: <20140801210825.GA7676@nargothrond.kdm.org> References: <20140730203315.0EED1295B@uriah.heep.sax.de> <20140730204200.4645729B8@uriah.heep.sax.de> <53D95F61.4080701@FreeBSD.org> <20140730215113.GA3564@uriah.heep.sax.de> <20140731035756.GA91452@nargothrond.kdm.org> <20140731060936.GB4095@uriah.heep.sax.de> <20140731091422.GA37239@uriah.heep.sax.de> <20140731201742.GA4358@uriah.heep.sax.de> <20140731211702.GA98465@nargothrond.kdm.org> <20140801173101.D833028CB@uriah.heep.sax.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140801173101.D833028CB@uriah.heep.sax.de> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-scsi@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: Fri, 01 Aug 2014 21:08:32 -0000 On Fri, Aug 01, 2014 at 19:31:01 +0200, Joerg Wunsch wrote: > "Kenneth D. Merry" wrote: > > >> I am content with that patch, and would be willing to commit it. > > > > Okay, it looks good to me; go ahead and commit it. > > Committed, thanks for the review! Thanks for tracking down the problem and providing a fix! Ken -- Kenneth Merry ken@FreeBSD.ORG