From owner-freebsd-stable@FreeBSD.ORG Sat Oct 25 09:38:42 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79D0D7B0; Sat, 25 Oct 2014 09:38:42 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (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 04C6EC5D; Sat, 25 Oct 2014 09:38:41 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s9P9ccgg013571; Sat, 25 Oct 2014 11:38:38 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 35E993066; Sat, 25 Oct 2014 11:38:38 +0200 (CEST) Message-ID: <544B6F97.7010808@omnilan.de> Date: Sat, 25 Oct 2014 11:38:31 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Kenneth D. Merry" Subject: Re: sa(4) 9.2->10.1, nsa0.0: request ptr 0x803135040 is not on a page boundary; cannot split request References: <54494E92.5010007@omnilan.de> <20141024230725.GA50845@mithlond.kdm.org> In-Reply-To: <20141024230725.GA50845@mithlond.kdm.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig17D5E8A7EF21E5FDEBEBF205" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Sat, 25 Oct 2014 11:38:38 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 09:38:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig17D5E8A7EF21E5FDEBEBF205 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bez=FCglich Kenneth D. Merry's Nachricht vom 25.10.2014 01:07 (localtime= ): =85 >> When btape(8) starts to read the label, the _subject's error is report= ed_: >> *nsa0.0: request ptr 0x803135040 is not on a page boundary; cannot spl= it >> request* > What blocksize are you using with btape(8)? > > What kind of controller are you using? Hello and thanks a lot for your very avaluable explanations! had no block size set in the bacula(-sd) configuration. Btape(8) consults the same config file, so I thought it's probably bacula's default of 64512, but if I correctly understood your explanation later, it's more likely it's starting with kern.cam.sa.0.maxio, which doesn't work because of the non-page-aligned address!?! My LTO4 is connected via a mps(4), LSISAS2008. > The reason you get that error message is that the sa(4) driver goes thr= ough > physio(9) to get buffers from userland into the kernel. physio(9) reli= es > on the vmapbuf()/vunmapbuf() routines to map buffers in and out of the > kernel. > > vmapbuf() operates with a page granularity. The address to be mapped h= as > to start on a page boundary. It also uses kernel virtual address segme= nts > that are MAXPHYS in size. On x86 boxes at least, MAXPHYS is 128KB. So is it correct that kern.cam.sa.0.maxio =3D MAXPHYS? > So if you use a blocksize of 128KB, but pass in a pointer that doesn't > start on a page boundary, vmapbuf() will have to map 33 pages instead o= f > 32. In your case, it will have to start at page address 0x803135000, a= nd > will need 33 4KB pages, which is greater than 128KB. > > This behavior obviously isn't very user friendly.=20 > > If you want to avoid the problem, try setting your blocksize in Bacula = to > 4K less than what is reported in kern.cam.sa.0.maxio. If it's 131072, = then > set the blocksize to 126976. > > Another way to avoid the problem is to increase MAXPHYS. Increasing it= > beyond kern.cam.sa.0.cpi_maxio won't help anything. If you increase > it too much, you can run into other problems. > > That said, though, you can probably bump it to 512K without much worry.= > Put this in your kernel config file and recompile/reinstall your kernel= : > > options MAXPHYS=3D"(512*1024)" > options DFLTPHYS=3D"(512*1024)" > > The same thing applies, though -- you'll want to set your blocksize to = 1 > page less than kern.cam.sa.0.maxio, since Bacula isn't using page-align= ed > buffers. Ah, ok =96 =93unaligned buffers=94. I think I understood the reason for t= he message. That's enough for me for now; probably btape(8) attempts acessing the tape with kern.cam.sa.0.maxio, not bacula's default of 64512. What I haven't understood entirely is DFLTPHYS and the whole physio(9) chain down to the magnetic tape :-( But at least now I have an idea and your advise to increase DFLTPHYS, so I did that and will do some tests. I knew of that options before, but I didn't want to tune anything I can't estimate it's impact=85 Thanks a lot, -Harry --------------enig17D5E8A7EF21E5FDEBEBF205 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlRLb50ACgkQLDqVQ9VXb8inQwCgi8KogN2qPCZFLG1p/8ZxVmxE 33IAnibzVjZ0AQ/t/AXdl07tXIClikYs =xN/T -----END PGP SIGNATURE----- --------------enig17D5E8A7EF21E5FDEBEBF205--