From owner-freebsd-stable@freebsd.org Sun Oct 11 07:13:21 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3B05A1193D for ; Sun, 11 Oct 2015 07:13:21 +0000 (UTC) (envelope-from ck@cksoft.de) Received: from mx1.cksoft.de (mx1.cksoft.de [IPv6:2001:67c:24f8:1::25:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.cksoft.de", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7CC35C52; Sun, 11 Oct 2015 07:13:21 +0000 (UTC) (envelope-from ck@cksoft.de) Received: from m.cksoft.de (unknown [IPv6:2a01:170:1110:8001::25:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.cksoft.de (Postfix) with ESMTPSA id 548E31E9EB2; Sun, 11 Oct 2015 09:13:17 +0200 (CEST) Received: from amavis.cksoft.de (unknown [IPv6:2a01:170:1110:8001::25:a1]) by m.cksoft.de (Postfix) with ESMTP id E06A162FA4; Sun, 11 Oct 2015 09:11:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from m.cksoft.de ([192.168.64.93]) by amavis.cksoft.de (amavis.cksoft.de [192.168.64.94]) (amavisd-new, port 10041) with ESMTP id sEO5CmXS-k-3; Sun, 11 Oct 2015 09:11:45 +0200 (CEST) Received: from noc1.cksoft.de (noc1.cksoft.de [IPv6:2a01:170:1110:8001::53:1]) by m.cksoft.de (Postfix) with ESMTP id 0AA8362F88; Sun, 11 Oct 2015 09:11:45 +0200 (CEST) Received: by noc1.cksoft.de (Postfix, from userid 1000) id E8F8613BDB; Sun, 11 Oct 2015 09:13:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by noc1.cksoft.de (Postfix) with ESMTP id B95A413B9F; Sun, 11 Oct 2015 09:13:15 +0200 (CEST) Date: Sun, 11 Oct 2015 09:13:15 +0200 (CEST) From: Christian Kratzer To: Rick Macklem cc: John Baldwin , freebsd-stable@freebsd.org Subject: Re: smbfs crashes since approx. 10.1-RELEASE In-Reply-To: <358885214.31305796.1444518367048.JavaMail.zimbra@uoguelph.ca> Message-ID: References: <2148690.gx9M0ZzrG1@ralph.baldwin.cx> <3563189.eDHDcCgW5L@ralph.baldwin.cx> <358885214.31305796.1444518367048.JavaMail.zimbra@uoguelph.ca> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) X-Spammer-Kill-Ratio: 75% MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2015 07:13:21 -0000 Hi Rick, On Sat, 10 Oct 2015, Rick Macklem wrote: > Hi again, > > Attached is a semantically equivalent patch to the one I posted a few > minutes ago, but I think this one is more readable. > > Please let me know if you get it tested, rick I have patched the 10-stable kernel on the box. Judging from the previous crash frequency the issue should be fixed if the box stays up 2-3 days. Thanks a lot! Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ From owner-freebsd-stable@freebsd.org Sun Oct 11 08:57:45 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2E28C9D3001 for ; Sun, 11 Oct 2015 08:57:45 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from mbob.nabble.com (mbob.nabble.com [162.253.133.15]) by mx1.freebsd.org (Postfix) with ESMTP id 1D78FC4C for ; Sun, 11 Oct 2015 08:57:44 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from msam.nabble.com (unknown [162.253.133.85]) by mbob.nabble.com (Postfix) with ESMTP id 532301768CDD for ; Sun, 11 Oct 2015 01:49:50 -0700 (PDT) Date: Sun, 11 Oct 2015 01:57:37 -0700 (MST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1444553857046-6044272.post@n5.nabble.com> Subject: STABLE clang planned update MFC path (3.4.1 STABLE, 3.7.0 CURRENT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2015 08:57:45 -0000 Hello. As of now, I have- FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 on FreeBSD 10.2-STABLE #0 r289058, I wouldn't have taken notice, if mesa related things didn't recently wish for llvm36 available; digging in CURRENT, I've saw that MFC of 3.5.0 was planed after only a one month wait, that obviously didn't happen, however as we are now 3 versions behind, is there any official plan of it? -- View this message in context: http://freebsd.1045724.n5.nabble.com/STABLE-clang-planned-update-MFC-path-3-4-1-STABLE-3-7-0-CURRENT-tp6044272.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@freebsd.org Sun Oct 11 12:05:35 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5570599A261 for ; Sun, 11 Oct 2015 12:05:35 +0000 (UTC) (envelope-from pkubaj@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 38345CC7 for ; Sun, 11 Oct 2015 12:05:34 +0000 (UTC) (envelope-from pkubaj@riseup.net) Received: from piha.riseup.net (unknown [10.0.1.162]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 0D544C1F91; Sun, 11 Oct 2015 05:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1444565134; bh=4xzHCnFzbFagbRBHimv3GFj5108phlTfThI9Dg4bphE=; h=To:Cc:From:Subject:Date:From; b=Z5qP7ZqRLAMF4vphPKjO/5Lzt1meL999mYpeeoslWm1Bitx120AsK/8+ffCnXPxBH AfxE3ZgNgYfs788fhazzL3ZhFe37+1yi4QMKtlmmmqHotvjZFKnWpMzsFPerOVpFLl BRFjJ/J3iKrnFdmhbtudxzquCgAZhWc6ygTvzXLg= Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: pkubaj) with ESMTPSA id 498D514000E To: freebsd-stable@freebsd.org Cc: jakub.lach@mailplus.pl From: Piotr Kubaj Subject: Re: STABLE clang planned update MFC path (3.4.1 STABLE, 3.7.0, CURRENT) Message-ID: <561A508B.1060408@riseup.net> Date: Sun, 11 Oct 2015 14:05:31 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uLi03eU1K7OxXLGwnqGNCsearhJHWDxf9" X-Virus-Scanned: clamav-milter 0.98.7 at mx1.riseup.net X-Virus-Status: Clean X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2015 12:05:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uLi03eU1K7OxXLGwnqGNCsearhJHWDxf9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable AFAIK if there had been such plans, they were dropped long ago. The reasoning it can't be done (at least for now) is that versions 3.5.0+ require C++11-capable stack and that would break upgrades from 9-STABLE (if the user still uses GCC, as is by default). So, LLVM in stable/10 will probably be upgraded when stable/9 goes EOL. --uLi03eU1K7OxXLGwnqGNCsearhJHWDxf9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWGlCLAAoJEC9nKukRsfY+feoQAMX97qtwynFCvsCUEmizVTT7 6I8ixexh16+r4Top8t0z1wZRaZAEvMQKxiVuMxXAzDllhlvO12674GuuIygKNWEz AwwnyfFholToNKgoBikVDyrJ4HqK654/2Sp4U/KlbcydiETKEvEvU4WvSSMizqIp pBQPSKsGT0AnwDKNCNPlPG76uFyiISsS1WTK+lvHWrwUcVzT1htO/Dx9bMsrJ1i0 DBfd/TdsOlc4EB5IMP97TGF+H7LA9X7kiAoB4rBFTqB28Wj69Wo/7xzadnbB5nnz XCBC/xx+qeFnrNbHfEHSUV81VXNHQ12yv0eItKiCPDJ5OVm1iKHRmz9erwma0GGk t0Bkm1tDBWFxRt8M16HL8+anbSVVn5Ve4u4qzyzdU+Az8pvWPWi5gACcdZh6iSJQ bYfnsiExm5goj6yB4d/l3kcKa0fz/FmF/HTzkYBnp5wgHJ2Mrla8Eu5Z3rhLAc5T 3U0ELMRoZD3Gn7zlHeQO87MyF8QOKXSghE6pOxC6roZxXEDXJvMUPCBfmG+u1Bfl 3ySOWMM5TEhKAOvTsFVTzEynY2qihEuD188bgNyQsaSVLL2/qKfqMxUE+6d+MI0I DNngttaEfeGJhoivyEDp/fy3PjwxGdbMaKrm9AnsQ2qv1pM+Ca1Yyy/3JHaVAdIW vP2Ie6o1ViuiVnNaPdzk =FnM3 -----END PGP SIGNATURE----- --uLi03eU1K7OxXLGwnqGNCsearhJHWDxf9-- From owner-freebsd-stable@freebsd.org Sun Oct 11 17:27:06 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1AED9D2EDF for ; Sun, 11 Oct 2015 17:27:06 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8491CBB7 for ; Sun, 11 Oct 2015 17:27:06 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::9403:ea0b:fbc7:5e71] (unknown [IPv6:2001:7b8:3a7:0:9403:ea0b:fbc7:5e71]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 49FD8342C0; Sun, 11 Oct 2015 19:27:03 +0200 (CEST) Subject: Re: STABLE clang planned update MFC path (3.4.1 STABLE, 3.7.0, CURRENT) Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) Content-Type: multipart/signed; boundary="Apple-Mail=_2C580982-8DC5-4B29-BA6E-C7C32A9580E7"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 From: Dimitry Andric In-Reply-To: <561A508B.1060408@riseup.net> Date: Sun, 11 Oct 2015 19:26:54 +0200 Cc: freebsd-stable@freebsd.org, jakub.lach@mailplus.pl Message-Id: <9AC8D4B2-2817-4B4C-BB5C-AADB401A01D4@FreeBSD.org> References: <561A508B.1060408@riseup.net> To: Piotr Kubaj X-Mailer: Apple Mail (2.3094) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2015 17:27:06 -0000 --Apple-Mail=_2C580982-8DC5-4B29-BA6E-C7C32A9580E7 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 11 Oct 2015, at 14:05, Piotr Kubaj wrote: > > AFAIK if there had been such plans, they were dropped long ago. The > reasoning it can't be done (at least for now) is that versions 3.5.0+ > require C++11-capable stack and that would break upgrades from 9-STABLE > (if the user still uses GCC, as is by default). So, LLVM in stable/10 > will probably be upgraded when stable/9 goes EOL. If stable/10 had clang 3.5 or higher, you could still upgrade from stable/9. It would only require you to do the upgrade in two steps: * Rebuild and reinstall your stable/9 world using WITH_CLANG, WITH_CLANG_IS_CC, and WITH_LIBCPLUSPLUS. This will install clang 3.4.1 and libc++, and make clang the default compiler. * Checkout stable/10 (or even head), and build/install it in the regular fashion. I am personally not against merging newer llvm/clang versions into stable/10. But the "silent agreement" has always been that you could upgrade easily from the latest stable/X to stable/X+1, and the above two-step process breaks that, or at least makes it more complicated. Last but not least, note that this would only apply to the architectures that *can* actually build clang 3.4.1 and libc++ on stable/9. This is currently limited to x86, little-endian arm and powerpc (64 bit, I'm unsure about 32 bit). -Dimitry --Apple-Mail=_2C580982-8DC5-4B29-BA6E-C7C32A9580E7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.28 iEYEARECAAYFAlYam+YACgkQsF6jCi4glqOJBwCgj5UMrt8nC7XA8UWfpQvLmIQe SesAoN2xG7degCYryXx6+1tVSTwz5gOC =cEFY -----END PGP SIGNATURE----- --Apple-Mail=_2C580982-8DC5-4B29-BA6E-C7C32A9580E7-- From owner-freebsd-stable@freebsd.org Mon Oct 12 03:05:48 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F35AA119F0 for ; Mon, 12 Oct 2015 03:05:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-2.reflexion.net [208.70.210.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C4CA113DB for ; Mon, 12 Oct 2015 03:05:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21095 invoked from network); 12 Oct 2015 03:05:46 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 12 Oct 2015 03:05:46 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.70.2) with SMTP; Sun, 11 Oct 2015 23:05:46 -0400 (EDT) Received: (qmail 2850 invoked from network); 12 Oct 2015 03:05:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Oct 2015 03:05:46 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.108] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 8F71B1C43A3; Sun, 11 Oct 2015 20:05:39 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: STABLE clang planned update MFC path (3.4.1 STABLE, 3.7.0, CURRENT) vs. powerpc64 Date: Sun, 11 Oct 2015 20:05:44 -0700 Message-Id: <7ABB859E-8321-48F7-885C-6667243C1388@dsl-only.net> Cc: FreeBSD PowerPC ML To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 03:05:48 -0000 On 2014-Oct-11 Dimitry Andric wrote: > On 11 Oct 2015, at 14:05, Piotr Kubaj > wrote: > > > > AFAIK if there had been such plans, they were dropped long ago. The > > reasoning it can't be done (at least for now) is that versions = 3.5.0+ > > require C++11-capable stack and that would break upgrades from = 9-STABLE > > (if the user still uses GCC, as is by default). So, LLVM in = stable/10 > > will probably be upgraded when stable/9 goes EOL. >=20 >=20 > If stable/10 had clang 3.5 or higher, you could still upgrade from > stable/9. It would only require you to do the upgrade in two steps: >=20 > * Rebuild and reinstall your stable/9 world using WITH_CLANG, > WITH_CLANG_IS_CC, and WITH_LIBCPLUSPLUS. This will install clang > 3.4.1 and libc++, and make clang the default compiler. > * Checkout stable/10 (or even head), and build/install it in the = regular > fashion. >=20 > I am personally not against merging newer llvm/clang versions into > stable/10. But the "silent agreement" has always been that you could > upgrade easily from the latest stable/X to stable/X+1, and the above > two-step process breaks that, or at least makes it more complicated. >=20 > Last but not least, note that this would only apply to the = architectures > that *can* actually build clang 3.4.1 and libc++ on stable/9. This is > currently limited to x86, little-endian arm and powerpc (64 bit, I'm > unsure about 32 bit). >=20 > -Dimitry lib/csu/powerpc64/Makefile in head has updates and comments (2015-Feb-05 = or so) about "powerpc64 csu needs to be built by gcc, so enforce that". = It is tied to clang not supporting -mlongcall and "testing shows a clang = linked with a [#] clang-built csu segfaults". The forcing of gcc use in = head looks like: CC:=3D gcc COMPILER_TYPE:=3D gcc which is not in stable/10's variant. stable/10 has a lib/csu/powerpc64/Makefile that does not force gcc but = still has: CFLAGS+=3D -I${.CURDIR}/../common \ -I${.CURDIR}/../../libc/include \ -mlongcall and so has -mlongcall in use on the command lines. Unless -mlongcall = support used to be in place for clang and was later removed, a = rebuilding of FreeBSD 9 or 10 that includes a lib/csu/powerpc64/ rebuild = likely fails to build under WITH_CLANG_IS_CC. I'm not sure about going all the way back to FreeBSD 9 but this suggests = that clang was for some time --and recently has been-- insufficient on = its own for reliable(?) powerpc64 builds (2015-Feb-05). It may be best = to consider powerpc64 omitted from the "clang 3.4.1 and libc++" list in = that last paragraph given the "upgrade easily" context intended. (If there is an easy powerpc64 upgrade then I'd like to see notes about = it: Other contexts might be able to use similar techniques. I started my = explorations with 10.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Mon Oct 12 03:43:08 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8621EA11453 for ; Mon, 12 Oct 2015 03:43:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-2.reflexion.net [208.70.210.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48D83ACD for ; Mon, 12 Oct 2015 03:43:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11416 invoked from network); 12 Oct 2015 03:43:06 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 12 Oct 2015 03:43:06 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.70.2) with SMTP; Sun, 11 Oct 2015 23:43:06 -0400 (EDT) Received: (qmail 18210 invoked from network); 12 Oct 2015 03:43:05 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Oct 2015 03:43:05 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.108] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 65ED71C43E4; Sun, 11 Oct 2015 20:42:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: STABLE clang planned update MFC path (3.4.1 STABLE, 3.7.0, CURRENT) vs. powerpc64 From: Mark Millard In-Reply-To: <7ABB859E-8321-48F7-885C-6667243C1388@dsl-only.net> Date: Sun, 11 Oct 2015 20:43:04 -0700 Cc: FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <7ABB859E-8321-48F7-885C-6667243C1388@dsl-only.net> To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 03:43:08 -0000 I had written (2015-Oct-11): > I'm not sure about going all the way back to FreeBSD 9 but this = suggests that clang was for some time --and recently has been-- = insufficient on its own for reliable(?) powerpc64 builds (2015-Feb-05). = It may be best to consider powerpc64 omitted from the "clang 3.4.1 and = libc++" list in that last paragraph given the "upgrade easily" context = intended. But looking at stable/9 I see that -mlongcall is not in use in CFLAGS. I would guess that stable/9 depended on code happening to be close = enough together and it failed in other contexts. ("The" problems seem to = move around.) I'll note that the 2012-Mar-13 stable/10 addition of = -mlongcall was explained by (nwhitehorn's -r232932): > Adding -mlongcall > to crt1 flags causes the compiler to emit explicit TOC load = instructions > for all function calls, including _fini(). The reason for this being important was listed as: > Work around a binutils bug on powerpc64 where the TOC would not be > properly reloaded when calling _fini() in large binaries with multiple > TOC sections (e.g. GCC), leading to a segmentation fault. I'm still not sure that the stable/9 to stable/10 update would be = reliably clean for powerpc64, despite -mlongcall not being used at that = stage. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Oct-11, at 8:05 PM, Mark Millard wrote: > On 2014-Oct-11 Dimitry Andric wrote: >=20 >> On 11 Oct 2015, at 14:05, Piotr Kubaj >> wrote: >>>=20 >>> AFAIK if there had been such plans, they were dropped long ago. The >>> reasoning it can't be done (at least for now) is that versions = 3.5.0+ >>> require C++11-capable stack and that would break upgrades from = 9-STABLE >>> (if the user still uses GCC, as is by default). So, LLVM in = stable/10 >>> will probably be upgraded when stable/9 goes EOL. >>=20 >>=20 >> If stable/10 had clang 3.5 or higher, you could still upgrade from >> stable/9. It would only require you to do the upgrade in two steps: >>=20 >> * Rebuild and reinstall your stable/9 world using WITH_CLANG, >> WITH_CLANG_IS_CC, and WITH_LIBCPLUSPLUS. This will install clang >> 3.4.1 and libc++, and make clang the default compiler. >> * Checkout stable/10 (or even head), and build/install it in the = regular >> fashion. >>=20 >> I am personally not against merging newer llvm/clang versions into >> stable/10. But the "silent agreement" has always been that you could >> upgrade easily from the latest stable/X to stable/X+1, and the above >> two-step process breaks that, or at least makes it more complicated. >>=20 >> Last but not least, note that this would only apply to the = architectures >> that *can* actually build clang 3.4.1 and libc++ on stable/9. This = is >> currently limited to x86, little-endian arm and powerpc (64 bit, I'm >> unsure about 32 bit). >>=20 >> -Dimitry >=20 > lib/csu/powerpc64/Makefile in head has updates and comments = (2015-Feb-05 or so) about "powerpc64 csu needs to be built by gcc, so = enforce that". It is tied to clang not supporting -mlongcall and = "testing shows a clang linked with a [#] clang-built csu segfaults". The = forcing of gcc use in head looks like: >=20 > CC:=3D gcc > COMPILER_TYPE:=3D gcc >=20 > which is not in stable/10's variant. >=20 > stable/10 has a lib/csu/powerpc64/Makefile that does not force gcc but = still has: >=20 > CFLAGS+=3D -I${.CURDIR}/../common \ > -I${.CURDIR}/../../libc/include \ > -mlongcall >=20 > and so has -mlongcall in use on the command lines. Unless -mlongcall = support used to be in place for clang and was later removed, a = rebuilding of FreeBSD 9 or 10 that includes a lib/csu/powerpc64/ rebuild = likely fails to build under WITH_CLANG_IS_CC. >=20 > I'm not sure about going all the way back to FreeBSD 9 but this = suggests that clang was for some time --and recently has been-- = insufficient on its own for reliable(?) powerpc64 builds (2015-Feb-05). = It may be best to consider powerpc64 omitted from the "clang 3.4.1 and = libc++" list in that last paragraph given the "upgrade easily" context = intended. >=20 > (If there is an easy powerpc64 upgrade then I'd like to see notes = about it: Other contexts might be able to use similar techniques. I = started my explorations with 10.) >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Mon Oct 12 07:57:45 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97826A11100 for ; Mon, 12 Oct 2015 07:57:45 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from mx1.cksoft.de (mx1.cksoft.de [IPv6:2001:67c:24f8:1::25:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.cksoft.de", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 546B9A68; Mon, 12 Oct 2015 07:57:45 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from m.cksoft.de (m.cksoft.de [212.17.240.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.cksoft.de (Postfix) with ESMTPSA id 9B8191E9EB4; Mon, 12 Oct 2015 09:57:40 +0200 (CEST) Received: from amavis.cksoft.de (unknown [IPv6:2a01:170:1110:8001::25:a1]) by m.cksoft.de (Postfix) with ESMTP id 89E19631D0; Mon, 12 Oct 2015 09:56:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from m.cksoft.de ([IPv6:2a01:170:1110:8001::25:1]) by amavis.cksoft.de (amavis.cksoft.de [IPv6:2a01:170:1110:8001::25:a1]) (amavisd-new, port 10041) with ESMTP id X9toD7sXTRpT; Mon, 12 Oct 2015 09:56:07 +0200 (CEST) Received: from noc1.cksoft.de (noc1.cksoft.de [IPv6:2a01:170:1110:8001::53:1]) by m.cksoft.de (Postfix) with ESMTP id F343162FA4; Mon, 12 Oct 2015 09:56:06 +0200 (CEST) Received: by noc1.cksoft.de (Postfix, from userid 1000) id 727F113BEE; Mon, 12 Oct 2015 09:57:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by noc1.cksoft.de (Postfix) with ESMTP id 6B53713BCA; Mon, 12 Oct 2015 09:57:38 +0200 (CEST) Date: Mon, 12 Oct 2015 09:57:38 +0200 (CEST) From: Christian Kratzer X-X-Sender: ck@noc1.cksoft.de Reply-To: Christian Kratzer To: Rick Macklem cc: John Baldwin , freebsd-stable@freebsd.org Subject: Re: smbfs crashes since approx. 10.1-RELEASE In-Reply-To: <358885214.31305796.1444518367048.JavaMail.zimbra@uoguelph.ca> Message-ID: References: <2148690.gx9M0ZzrG1@ralph.baldwin.cx> <3563189.eDHDcCgW5L@ralph.baldwin.cx> <358885214.31305796.1444518367048.JavaMail.zimbra@uoguelph.ca> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) X-Spammer-Kill-Ratio: 75% MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 07:57:45 -0000 Hi Rick, On Sat, 10 Oct 2015, Rick Macklem wrote: > Hi again, > > Attached is a semantically equivalent patch to the one I posted a few > minutes ago, but I think this one is more readable. > > Please let me know if you get it tested, rick the box crashed again tonight with your patch applied. Here's the new crashinfo: panic: Assertion mtx_unowned(m) failed at /usr/src/sys/kern/kern_mutex.c:955 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: Assertion mtx_unowned(m) failed at /usr/src/sys/kern/kern_mutex.c:955 cpuid = 2 KDB: stack backtrace: #0 0xffffffff80975bb0 at kdb_backtrace+0x60 #1 0xffffffff8093baa6 at vpanic+0x126 #2 0xffffffff8093b979 at kassert_panic+0x139 #3 0xffffffff80921c47 at _mtx_destroy+0x77 #4 0xffffffff81a1c114 at smb_iod_destroy+0xc4 #5 0xffffffff81a12eea at smb_vc_free+0x1a #6 0xffffffff81a13e24 at sdp_trydestroy+0xb4 #7 0xffffffff81a1cb36 at smbfs_unmount+0xd6 #8 0xffffffff809d9e84 at dounmount+0x524 #9 0xffffffff809d9936 at sys_unmount+0x3c6 #10 0xffffffff80d42235 at amd64_syscall+0x265 #11 0xffffffff80d25cfb at Xfast_syscall+0xfb Uptime: 1d21h59m0s Dumping 191 out of 999 MB:..9%..17%..26%..34%..42%..51%..67%..76%..84%..92% Here are the stackframes with line numbers: (kgdb) frame 0 #0 __curthread () at ./machine/pcpu.h:219 219 __asm("movq %%gs:%1,%0" : "=r" (td) (kgdb) frame 1 #1 doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:263 263 dumptid = curthread->td_tid; (kgdb) frame 2 #2 0xffffffff8093b5f2 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:451 451 doadump(TRUE); (kgdb) frame 3 #3 0xffffffff8093bae5 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:758 758 kern_reboot(bootopt); (kgdb) frame 4 #4 0xffffffff8093b979 in kassert_panic (fmt=0xffffffff80e931ef "Assertion %s failed at %s:%d") at /usr/src/sys/kern/kern_shutdown.c:646 646 vpanic(fmt, ap); (kgdb) frame 5 #5 0xffffffff80921c47 in _mtx_destroy (c=0xfffff80002db5490) at /usr/src/sys/kern/kern_mutex.c:955 955 MPASS(mtx_unowned(m)); (kgdb) frame 6 #6 0xffffffff81a1c174 in smb_iod_destroy (iod=0xfffff80002db5400) at /usr/src/sys/modules/smbfs/../../netsmb/smb_iod.c:733 733 smb_sl_destroy(&iod->iod_evlock); (kgdb) frame 7 #7 0xffffffff81a12eea in smb_vc_free (cp=0xfffff80002933000) at /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:499 499 smb_iod_destroy(vcp->vc_iod); (kgdb) frame 8 #8 0xffffffff81a13e24 in sdp_trydestroy (sdp=0xfffff80002904140) at /usr/src/sys/modules/smbfs/../../netsmb/smb_dev.c:166 166 smb_vc_rele(vcp, scred); (kgdb) frame 9 #9 0xffffffff81a1cb96 in smbfs_unmount (mp=0xfffff80015226000, mntflags=) at /usr/src/sys/modules/smbfs/../../fs/smbfs/smbfs_vfsops.c:297 297 sdp_trydestroy(dev); (kgdb) frame 10 #10 0xffffffff809d9e84 in dounmount (mp=0xfffff80015226000, flags=134217728, td=0xfffff800151b0940) at /usr/src/sys/kern/vfs_mount.c:1313 1313 error = VFS_UNMOUNT(mp, flags); (kgdb) Let me know if you need anything else from the stackframes. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ From owner-freebsd-stable@freebsd.org Mon Oct 12 08:10:05 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FFFAA117F4 for ; Mon, 12 Oct 2015 08:10:05 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from mx1.cksoft.de (mx1.cksoft.de [IPv6:2001:67c:24f8:1::25:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.cksoft.de", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CD140106D; Mon, 12 Oct 2015 08:10:04 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from m.cksoft.de (unknown [IPv6:2a01:170:1110:8001::25:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.cksoft.de (Postfix) with ESMTPSA id 03BC41E9E6E; Mon, 12 Oct 2015 10:10:02 +0200 (CEST) Received: from amavis.cksoft.de (unknown [IPv6:2a01:170:1110:8001::25:a1]) by m.cksoft.de (Postfix) with ESMTP id 08201631D0; Mon, 12 Oct 2015 10:08:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from m.cksoft.de ([IPv6:2a01:170:1110:8001::25:1]) by amavis.cksoft.de (amavis.cksoft.de [IPv6:2a01:170:1110:8001::25:a1]) (amavisd-new, port 10041) with ESMTP id VcU_bAgcqqrv; Mon, 12 Oct 2015 10:08:26 +0200 (CEST) Received: from noc1.cksoft.de (noc1.cksoft.de [IPv6:2a01:170:1110:8001::53:1]) by m.cksoft.de (Postfix) with ESMTP id 7E4AD62FA4; Mon, 12 Oct 2015 10:08:26 +0200 (CEST) Received: by noc1.cksoft.de (Postfix, from userid 1000) id EBC2913BEE; Mon, 12 Oct 2015 10:09:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by noc1.cksoft.de (Postfix) with ESMTP id DDF6813BCA; Mon, 12 Oct 2015 10:09:57 +0200 (CEST) Date: Mon, 12 Oct 2015 10:09:57 +0200 (CEST) From: Christian Kratzer X-X-Sender: ck@noc1.cksoft.de Reply-To: Christian Kratzer To: Rick Macklem cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: smbfs crashes since approx. 10.1-RELEASE In-Reply-To: Message-ID: References: <2148690.gx9M0ZzrG1@ralph.baldwin.cx> <3563189.eDHDcCgW5L@ralph.baldwin.cx> <358885214.31305796.1444518367048.JavaMail.zimbra@uoguelph.ca> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) X-Spammer-Kill-Ratio: 75% MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 08:10:05 -0000 Hi Rick, there was also a second more recent crash in /var/crash Mon Oct 12 03:01:16 CEST 2015 FreeBSD noc3.cksoft.de 10.2-STABLE FreeBSD 10.2-STABLE #2 r288980M: Sun Oct 11 08:37:40 CEST 2015 ck@noc3.cksoft.de:/usr/obj/usr/src/sys/NOC amd64 panic: Assertion mtx_unowned(m) failed at /usr/src/sys/kern/kern_mutex.c:955 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: Assertion mtx_unowned(m) failed at /usr/src/sys/kern/kern_mutex.c:955 cpuid = 3 KDB: stack backtrace: #0 0xffffffff80975bb0 at kdb_backtrace+0x60 #1 0xffffffff8093baa6 at vpanic+0x126 #2 0xffffffff8093b979 at kassert_panic+0x139 #3 0xffffffff80921c47 at _mtx_destroy+0x77 #4 0xffffffff81a1c174 at smb_iod_destroy+0xc4 #5 0xffffffff81a12eea at smb_vc_free+0x1a #6 0xffffffff81a13e24 at sdp_trydestroy+0xb4 #7 0xffffffff81a1cb96 at smbfs_unmount+0xd6 #8 0xffffffff809d9e84 at dounmount+0x524 #9 0xffffffff809d9936 at sys_unmount+0x3c6 #10 0xffffffff80d42235 at amd64_syscall+0x265 #11 0xffffffff80d25cfb at Xfast_syscall+0xfb Uptime: 8h44m10s Dumping 102 out of 999 MB:..16%..32%..47%..63%..78%..94% Reading symbols from /boot/kernel/smbfs.ko.symbols...done. Loaded symbols for /boot/kernel/smbfs.ko.symbols Reading symbols from /boot/kernel/libiconv.ko.symbols...done. Loaded symbols for /boot/kernel/libiconv.ko.symbols Reading symbols from /boot/kernel/libmchain.ko.symbols...done. Loaded symbols for /boot/kernel/libmchain.ko.symbols #0 doadump (textdump=) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:219 #1 0xffffffff8093b5f2 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:451 #2 0xffffffff8093bae5 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:758 #3 0xffffffff8093b979 in kassert_panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:646 #4 0xffffffff80921c47 in _mtx_destroy (c=0xfffff80002db5490) at /usr/src/sys/kern/kern_mutex.c:955 #5 0xffffffff81a1c174 in smb_iod_destroy (iod=0xfffff80002db5400) at /usr/src/sys/modules/smbfs/../../netsmb/smb_iod.c:733 #6 0xffffffff81a12eea in smb_vc_free (cp=0xfffff80002933000) at /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:499 #7 0xffffffff81a13e24 in sdp_trydestroy (sdp=0xfffff80002904140) at /usr/src/sys/modules/smbfs/../../netsmb/smb_dev.c:166 #8 0xffffffff81a1cb96 in smbfs_unmount (mp=0xfffff80015226000, mntflags=) at /usr/src/sys/modules/smbfs/../../fs/smbfs/smbfs_vfsops.c:297 #9 0xffffffff809d9e84 in dounmount (mp=0xfffff80015226000, flags=134217728, td=0xfffff800151b0940) at /usr/src/sys/kern/vfs_mount.c:1313 #10 0xffffffff809d9936 in sys_unmount (td=0xfffff800151b0940, uap=0xfffffe003d643b80) at /usr/src/sys/kern/vfs_mount.c:1205 #11 0xffffffff80d42235 in amd64_syscall (td=0xfffff800151b0940, traced=0) at subr_syscall.c:134 #12 0xffffffff80d25cfb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:396 #13 0x000000080089190a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) Greetings Christian On Mon, 12 Oct 2015, Christian Kratzer wrote: > Hi Rick, > > On Sat, 10 Oct 2015, Rick Macklem wrote: > >> Hi again, >> >> Attached is a semantically equivalent patch to the one I posted a few >> minutes ago, but I think this one is more readable. >> >> Please let me know if you get it tested, rick > > the box crashed again tonight with your patch applied. Here's the new > crashinfo: > > panic: Assertion mtx_unowned(m) failed at > /usr/src/sys/kern/kern_mutex.c:955 > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > panic: Assertion mtx_unowned(m) failed at > /usr/src/sys/kern/kern_mutex.c:955 > cpuid = 2 > KDB: stack backtrace: > #0 0xffffffff80975bb0 at kdb_backtrace+0x60 > #1 0xffffffff8093baa6 at vpanic+0x126 > #2 0xffffffff8093b979 at kassert_panic+0x139 > #3 0xffffffff80921c47 at _mtx_destroy+0x77 > #4 0xffffffff81a1c114 at smb_iod_destroy+0xc4 > #5 0xffffffff81a12eea at smb_vc_free+0x1a > #6 0xffffffff81a13e24 at sdp_trydestroy+0xb4 > #7 0xffffffff81a1cb36 at smbfs_unmount+0xd6 > #8 0xffffffff809d9e84 at dounmount+0x524 > #9 0xffffffff809d9936 at sys_unmount+0x3c6 > #10 0xffffffff80d42235 at amd64_syscall+0x265 > #11 0xffffffff80d25cfb at Xfast_syscall+0xfb > Uptime: 1d21h59m0s > Dumping 191 out of 999 > MB:..9%..17%..26%..34%..42%..51%..67%..76%..84%..92% > > Here are the stackframes with line numbers: > > (kgdb) frame 0 > #0 __curthread () at ./machine/pcpu.h:219 > 219 __asm("movq %%gs:%1,%0" : "=r" (td) > (kgdb) frame 1 > #1 doadump (textdump=) at > /usr/src/sys/kern/kern_shutdown.c:263 > 263 dumptid = curthread->td_tid; > (kgdb) frame 2 > #2 0xffffffff8093b5f2 in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:451 > 451 doadump(TRUE); > (kgdb) frame 3 > #3 0xffffffff8093bae5 in vpanic (fmt=, ap= out>) at /usr/src/sys/kern/kern_shutdown.c:758 > 758 kern_reboot(bootopt); > (kgdb) frame 4 > #4 0xffffffff8093b979 in kassert_panic (fmt=0xffffffff80e931ef > "Assertion %s failed at %s:%d") at /usr/src/sys/kern/kern_shutdown.c:646 > 646 vpanic(fmt, ap); > (kgdb) frame 5 > #5 0xffffffff80921c47 in _mtx_destroy (c=0xfffff80002db5490) at > /usr/src/sys/kern/kern_mutex.c:955 > 955 MPASS(mtx_unowned(m)); > (kgdb) frame 6 > #6 0xffffffff81a1c174 in smb_iod_destroy (iod=0xfffff80002db5400) at > /usr/src/sys/modules/smbfs/../../netsmb/smb_iod.c:733 > 733 smb_sl_destroy(&iod->iod_evlock); > (kgdb) frame 7 > #7 0xffffffff81a12eea in smb_vc_free (cp=0xfffff80002933000) at > /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:499 > 499 smb_iod_destroy(vcp->vc_iod); > (kgdb) frame 8 > #8 0xffffffff81a13e24 in sdp_trydestroy (sdp=0xfffff80002904140) at > /usr/src/sys/modules/smbfs/../../netsmb/smb_dev.c:166 > 166 smb_vc_rele(vcp, scred); > (kgdb) frame 9 > #9 0xffffffff81a1cb96 in smbfs_unmount (mp=0xfffff80015226000, > mntflags=) at > /usr/src/sys/modules/smbfs/../../fs/smbfs/smbfs_vfsops.c:297 > 297 sdp_trydestroy(dev); > (kgdb) frame 10 > #10 0xffffffff809d9e84 in dounmount (mp=0xfffff80015226000, > flags=134217728, td=0xfffff800151b0940) at /usr/src/sys/kern/vfs_mount.c:1313 > 1313 error = VFS_UNMOUNT(mp, flags); > (kgdb) > > Let me know if you need anything else from the stackframes. > > > Greetings > Christian > > > -- Christian Kratzer CK Software GmbH Email: ck@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ From owner-freebsd-stable@freebsd.org Mon Oct 12 11:46:24 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EC38A0F519 for ; Mon, 12 Oct 2015 11:46:24 +0000 (UTC) (envelope-from marko.cupac@mimar.rs) Received: from smtp.mimar.rs (smtp.mimar.rs [193.53.106.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5171E1603 for ; Mon, 12 Oct 2015 11:46:23 +0000 (UTC) (envelope-from marko.cupac@mimar.rs) Received: from vscan.mimar.rs (vscan.mimar.rs [193.53.106.134]) by smtp.mimar.rs (Postfix) with ESMTP id 8F32689AE7 for ; Mon, 12 Oct 2015 13:46:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mimar.rs; h= content-transfer-encoding:content-type:content-type:mime-version :x-mailer:organization:message-id:subject:subject:from:from:date :date:received:received; s=mimar-0901; t=1444650374; x= 1446464775; bh=6UOlF8ZXDR5oz4Ayny9xi8Ap3GCWmuTtr7BWu7ByB0I=; b=N qhUFgOY6eYsbG1rm9LAKKhsVK1gFP7S8Q2ZfyAmvTI2HvtmLhybK2UhBlTtizK1r Ei4Uu7uSUk59SAwCDM3fIdcJSL2K24X8ySErtVaBsRReLaCC5ORKt8h25rpE0NKK vsx0Vl0HoMEJS+TiIESvsq4btrT3XtweYZdxCf302Y= X-Virus-Scanned: amavisd-new at mimar.rs Received: from smtp.mimar.rs ([193.53.106.135]) by vscan.mimar.rs (vscan.mimar.rs [193.53.106.134]) (amavisd-new, port 10026) with ESMTP id XICiMavHz3YN for ; Mon, 12 Oct 2015 13:46:14 +0200 (CEST) Received: from efreet.kappastar.com (nat-nat.kappastar.com [193.53.106.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marko.cupac@mimar.rs) by smtp.mimar.rs (Postfix) with ESMTPSA id DCEBB898D7 for ; Mon, 12 Oct 2015 13:46:14 +0200 (CEST) Date: Mon, 12 Oct 2015 13:46:14 +0200 From: Marko =?UTF-8?B?Q3VwYcSH?= To: freebsd-stable@freebsd.org Subject: help with partitioning - huge stripesize Message-ID: <20151012134614.0a95076b@efreet.kappastar.com> Organization: mimar X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 11:46:24 -0000 Hi, I've got HP ProLiant DL320g5p server with HP Smart Array E200 RAID controller and 4X300Gb SAS disks. I'd like to use it for hosting jails on ZFS, but no matter how I create zpool, I always get a warning about non-native block size: block size: 8192B configured, 1048576B native I know it is optimal for ZFS to have direct access to disks, but HP Smart Array E200 apparently does not support JBOD mode. I tried to configure both single RAID-5 logical volume and four RAID-0 logical volumes, in both cases diskinfo gives me the following: 512 # sectorsize 299966445568 # mediasize in bytes (279G) 585871964 # mediasize in sectors 1048576 # stripesize 643072 # stripeoffset 71798 # Cylinders according to firmware. 255 # Heads according to firmware. 32 # Sectors according to firmware. PA6C90R9SXK07P # Disk ident. With hardware I have, is it better to create single RAID-5 logical volume in HP Smart Array E200 and let ZFS think it deals with single physical drive, or four RAID-0 logical volumes and let ZFS think it deals with four physical drives? Can I just ignore warning about non-native block size? If not, how can I make it go away? Thank you in advance, --=20 Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupa=C4=87 https://www.mimar.rs/ From owner-freebsd-stable@freebsd.org Mon Oct 12 12:17:05 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54E7FA11415 for ; Mon, 12 Oct 2015 12:17:05 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EAC819CF for ; Mon, 12 Oct 2015 12:17:04 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by wicgb1 with SMTP id gb1so47986974wic.1 for ; Mon, 12 Oct 2015 05:16:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=cQrhnW81OdKFDAjaLuCTmQGtepx7iWde1kJY/jHdfDE=; b=A9RnRXhvMNuzoY1iQP2A+j50fP5hVzKsw1eiC7cMPYmk/idYE6PA7aNAh2qEs5Jrac dFnJAXxg2w133b6fwqwWCP2wkFxRykaLs32VKzBPbNCNC5bTd6qj9B6qBU/s84KUMG0M xcEew2AW+u9zu0IqGxrXrnmox5UCoYygaqnGqjj+pInI2A+MiEb/MLVYUdc3PB0OV4vp hww27HvimHaHUXYd3KU+UR1HFfDc30oGiUQ2gxsqAG5r/9SOBadOoUC9qrn2KuCIrY2M Ft05sYd3YAepWo8ZbVK81J2sdAbjZE2xeAi3VrY/Yf8hD22Gmqx0+S/+QVS7eqDM1pxl g0bQ== X-Gm-Message-State: ALoCoQk649wvpMRMZoFtj6xb7p45SaJ1VA73m7jSqqaJQIEql7o8ep+Aw6Kp7xgmwEUui88AQ1dL X-Received: by 10.180.102.169 with SMTP id fp9mr15201315wib.29.1444652217482; Mon, 12 Oct 2015 05:16:57 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by smtp.gmail.com with ESMTPSA id gc14sm10292209wic.12.2015.10.12.05.16.56 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Oct 2015 05:16:56 -0700 (PDT) Subject: Re: help with partitioning - huge stripesize To: freebsd-stable@freebsd.org References: <20151012134614.0a95076b@efreet.kappastar.com> From: Steven Hartland Message-ID: <561BA4BB.6030507@multiplay.co.uk> Date: Mon, 12 Oct 2015 13:16:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151012134614.0a95076b@efreet.kappastar.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 12:17:05 -0000 As you say using RAID for ZFS is a bad idea, so ideally change the hardware. If not see if your RAID controller has a stripe size option to help or just ignore the warning, its just a warning as it will be non-optimal performance. On 12/10/2015 12:46, Marko Cupać wrote: > Hi, > > I've got HP ProLiant DL320g5p server with HP Smart Array E200 RAID > controller and 4X300Gb SAS disks. > > I'd like to use it for hosting jails on ZFS, but no matter how I create > zpool, I always get a warning about non-native block size: > > block size: 8192B configured, 1048576B native > > I know it is optimal for ZFS to have direct access to disks, but HP > Smart Array E200 apparently does not support JBOD mode. I tried to > configure both single RAID-5 logical volume and four RAID-0 > logical volumes, in both cases diskinfo gives me the following: > > 512 # sectorsize > 299966445568 # mediasize in bytes (279G) > 585871964 # mediasize in sectors > 1048576 # stripesize > 643072 # stripeoffset > 71798 # Cylinders according to firmware. > 255 # Heads according to firmware. > 32 # Sectors according to firmware. > PA6C90R9SXK07P # Disk ident. > > With hardware I have, is it better to create single RAID-5 logical > volume in HP Smart Array E200 and let ZFS think it deals with single > physical drive, or four RAID-0 logical volumes and let ZFS think it > deals with four physical drives? > > Can I just ignore warning about non-native block size? If not, how can > I make it go away? > > Thank you in advance, From owner-freebsd-stable@freebsd.org Mon Oct 12 12:32:47 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20EE9A119BD for ; Mon, 12 Oct 2015 12:32:47 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 8B00A15F5; Mon, 12 Oct 2015 12:32:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:1DnlFRYzMzvfcNtWwb1nMBP/LSx+4OfEezUN459isYplN5qZpcu5bnLW6fgltlLVR4KTs6sC0LqK9fC6EjBQqb+681k8M7V0HycfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aJBzzOEJPK/jvHcaK1oLsh7z0q8eYP1UArQH+SI0xBS3+lR/WuMgSjNkqAYcK4TyNnEF1ff9Lz3hjP1OZkkW0zM6x+Jl+73YY4Kp5pIZoGJ/3dKUgTLFeEC9ucyVsvJWq5lH/Sl6k5mEdSXkXmxwAIBLM8AP3RN+luSjSvelm3yeGe8H7G+MaQzOnup1qQxygrS4MNDo09SmDkMl5h6FfrReJuhtw3oPQeIHTP/MoLfCVRs8TWWcUBpUZbCdGGI7pKtJXV+c= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CTAgBNpxtW/61jaINVCIN6bga9fQENgVoXCoJyggo1SgKBahQBAQEBAQEBAYEJgh+CBwEBAQMBAQEBIAQnIAsFCQICAQgOCgICDRkCAhsMAQkmAgQIBwQBHASIBQgNqgqTTQEBAQEBAQEDAQEBAQEBAQEBARgEgR6FUYR+hCoMBAIBHDQHgmmBRQWHOYcFhxVAhRmFGYRASINykgKDbQIfAQFChB4iMweGXYEGAQEB X-IronPort-AV: E=Sophos;i="5.17,672,1437451200"; d="scan'208";a="244026934" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-annu.net.uoguelph.ca with ESMTP; 12 Oct 2015 08:32:38 -0400 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 7EA0215F55D; Mon, 12 Oct 2015 08:32:38 -0400 (EDT) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id qH2iENJUPRve; Mon, 12 Oct 2015 08:32:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 42CA115F565; Mon, 12 Oct 2015 08:32:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XhpcumsKmHs5; Mon, 12 Oct 2015 08:32:37 -0400 (EDT) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 2300F15F55D; Mon, 12 Oct 2015 08:32:37 -0400 (EDT) Date: Mon, 12 Oct 2015 08:32:36 -0400 (EDT) From: Rick Macklem To: Christian Kratzer Cc: freebsd-stable@freebsd.org, John Baldwin Message-ID: <2135054744.32546564.1444653156980.JavaMail.zimbra@uoguelph.ca> In-Reply-To: References: <2148690.gx9M0ZzrG1@ralph.baldwin.cx> <3563189.eDHDcCgW5L@ralph.baldwin.cx> <358885214.31305796.1444518367048.JavaMail.zimbra@uoguelph.ca> Subject: Re: smbfs crashes since approx. 10.1-RELEASE MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF34 (Win)/8.0.9_GA_6191) Thread-Topic: smbfs crashes since approx. 10.1-RELEASE Thread-Index: zbjHYEpvbXNqKVqi1WrwcfoRNLghjA== X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 12:32:47 -0000 Christian Kratzer wrote: > Hi Rick, > > there was also a second more recent crash in /var/crash > > Mon Oct 12 03:01:16 CEST 2015 > > FreeBSD noc3.cksoft.de 10.2-STABLE FreeBSD 10.2-STABLE #2 r288980M: Sun > Oct 11 08:37:40 CEST 2015 > ck@noc3.cksoft.de:/usr/obj/usr/src/sys/NOC amd64 > > panic: Assertion mtx_unowned(m) failed at > /usr/src/sys/kern/kern_mutex.c:955 > Oops, I screwed up. I should have looked at this panic assertion when you reported it before. Ok, so if I understand the assertion correctly, it means that another thread has the mutex locked. If this is correct, I'll have to take another look at the code and figure out how to wait for these other threads to finish with the mutexes. I do think the patch fixes the race I saw, but there must be other races in the code. I'll take another look, but if anyone else is conversant with netsmb, feel free to jump in, because it is all new to me. Unfortunately, I won't have any way to do testing for the next month or so, so any patches I do come up with will be "try this untested..". rick > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > panic: Assertion mtx_unowned(m) failed at > /usr/src/sys/kern/kern_mutex.c:955 > cpuid = 3 > KDB: stack backtrace: > #0 0xffffffff80975bb0 at kdb_backtrace+0x60 > #1 0xffffffff8093baa6 at vpanic+0x126 > #2 0xffffffff8093b979 at kassert_panic+0x139 > #3 0xffffffff80921c47 at _mtx_destroy+0x77 > #4 0xffffffff81a1c174 at smb_iod_destroy+0xc4 > #5 0xffffffff81a12eea at smb_vc_free+0x1a > #6 0xffffffff81a13e24 at sdp_trydestroy+0xb4 > #7 0xffffffff81a1cb96 at smbfs_unmount+0xd6 > #8 0xffffffff809d9e84 at dounmount+0x524 > #9 0xffffffff809d9936 at sys_unmount+0x3c6 > #10 0xffffffff80d42235 at amd64_syscall+0x265 > #11 0xffffffff80d25cfb at Xfast_syscall+0xfb > Uptime: 8h44m10s > Dumping 102 out of 999 MB:..16%..32%..47%..63%..78%..94% > > Reading symbols from /boot/kernel/smbfs.ko.symbols...done. > Loaded symbols for /boot/kernel/smbfs.ko.symbols > Reading symbols from /boot/kernel/libiconv.ko.symbols...done. > Loaded symbols for /boot/kernel/libiconv.ko.symbols > Reading symbols from /boot/kernel/libmchain.ko.symbols...done. > Loaded symbols for /boot/kernel/libmchain.ko.symbols > #0 doadump (textdump=) at pcpu.h:219 > 219 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=) at pcpu.h:219 > #1 0xffffffff8093b5f2 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:451 > #2 0xffffffff8093bae5 in vpanic (fmt=, > ap=) at /usr/src/sys/kern/kern_shutdown.c:758 > #3 0xffffffff8093b979 in kassert_panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:646 > #4 0xffffffff80921c47 in _mtx_destroy (c=0xfffff80002db5490) > at /usr/src/sys/kern/kern_mutex.c:955 > #5 0xffffffff81a1c174 in smb_iod_destroy (iod=0xfffff80002db5400) > at /usr/src/sys/modules/smbfs/../../netsmb/smb_iod.c:733 > #6 0xffffffff81a12eea in smb_vc_free (cp=0xfffff80002933000) > at /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:499 > #7 0xffffffff81a13e24 in sdp_trydestroy (sdp=0xfffff80002904140) > at /usr/src/sys/modules/smbfs/../../netsmb/smb_dev.c:166 > #8 0xffffffff81a1cb96 in smbfs_unmount (mp=0xfffff80015226000, > mntflags=) > at /usr/src/sys/modules/smbfs/../../fs/smbfs/smbfs_vfsops.c:297 > #9 0xffffffff809d9e84 in dounmount (mp=0xfffff80015226000, > flags=134217728, > td=0xfffff800151b0940) at /usr/src/sys/kern/vfs_mount.c:1313 > #10 0xffffffff809d9936 in sys_unmount (td=0xfffff800151b0940, > uap=0xfffffe003d643b80) at /usr/src/sys/kern/vfs_mount.c:1205 > #11 0xffffffff80d42235 in amd64_syscall (td=0xfffff800151b0940, > traced=0) > at subr_syscall.c:134 > #12 0xffffffff80d25cfb in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:396 > #13 0x000000080089190a in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > > > Greetings > Christian > > > > > > > > > > > On Mon, 12 Oct 2015, Christian Kratzer wrote: > > > Hi Rick, > > > > On Sat, 10 Oct 2015, Rick Macklem wrote: > > > >> Hi again, > >> > >> Attached is a semantically equivalent patch to the one I posted a few > >> minutes ago, but I think this one is more readable. > >> > >> Please let me know if you get it tested, rick > > > > the box crashed again tonight with your patch applied. Here's the new > > crashinfo: > > > > panic: Assertion mtx_unowned(m) failed at > > /usr/src/sys/kern/kern_mutex.c:955 > > > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you > > are > > welcome to change it and/or distribute copies of it under certain > > conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for > > details. > > This GDB was configured as "amd64-marcel-freebsd"... > > > > Unread portion of the kernel message buffer: > > panic: Assertion mtx_unowned(m) failed at > > /usr/src/sys/kern/kern_mutex.c:955 > > cpuid = 2 > > KDB: stack backtrace: > > #0 0xffffffff80975bb0 at kdb_backtrace+0x60 > > #1 0xffffffff8093baa6 at vpanic+0x126 > > #2 0xffffffff8093b979 at kassert_panic+0x139 > > #3 0xffffffff80921c47 at _mtx_destroy+0x77 > > #4 0xffffffff81a1c114 at smb_iod_destroy+0xc4 > > #5 0xffffffff81a12eea at smb_vc_free+0x1a > > #6 0xffffffff81a13e24 at sdp_trydestroy+0xb4 > > #7 0xffffffff81a1cb36 at smbfs_unmount+0xd6 > > #8 0xffffffff809d9e84 at dounmount+0x524 > > #9 0xffffffff809d9936 at sys_unmount+0x3c6 > > #10 0xffffffff80d42235 at amd64_syscall+0x265 > > #11 0xffffffff80d25cfb at Xfast_syscall+0xfb > > Uptime: 1d21h59m0s > > Dumping 191 out of 999 > > MB:..9%..17%..26%..34%..42%..51%..67%..76%..84%..92% > > > > Here are the stackframes with line numbers: > > > > (kgdb) frame 0 > > #0 __curthread () at ./machine/pcpu.h:219 > > 219 __asm("movq %%gs:%1,%0" : "=r" (td) > > (kgdb) frame 1 > > #1 doadump (textdump=) at > > /usr/src/sys/kern/kern_shutdown.c:263 > > 263 dumptid = curthread->td_tid; > > (kgdb) frame 2 > > #2 0xffffffff8093b5f2 in kern_reboot (howto=260) at > > /usr/src/sys/kern/kern_shutdown.c:451 > > 451 doadump(TRUE); > > (kgdb) frame 3 > > #3 0xffffffff8093bae5 in vpanic (fmt=, ap= > out>) at /usr/src/sys/kern/kern_shutdown.c:758 > > 758 kern_reboot(bootopt); > > (kgdb) frame 4 > > #4 0xffffffff8093b979 in kassert_panic (fmt=0xffffffff80e931ef > > "Assertion %s failed at %s:%d") at /usr/src/sys/kern/kern_shutdown.c:646 > > 646 vpanic(fmt, ap); > > (kgdb) frame 5 > > #5 0xffffffff80921c47 in _mtx_destroy (c=0xfffff80002db5490) at > > /usr/src/sys/kern/kern_mutex.c:955 > > 955 MPASS(mtx_unowned(m)); > > (kgdb) frame 6 > > #6 0xffffffff81a1c174 in smb_iod_destroy (iod=0xfffff80002db5400) at > > /usr/src/sys/modules/smbfs/../../netsmb/smb_iod.c:733 > > 733 smb_sl_destroy(&iod->iod_evlock); > > (kgdb) frame 7 > > #7 0xffffffff81a12eea in smb_vc_free (cp=0xfffff80002933000) at > > /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:499 > > 499 smb_iod_destroy(vcp->vc_iod); > > (kgdb) frame 8 > > #8 0xffffffff81a13e24 in sdp_trydestroy (sdp=0xfffff80002904140) at > > /usr/src/sys/modules/smbfs/../../netsmb/smb_dev.c:166 > > 166 smb_vc_rele(vcp, scred); > > (kgdb) frame 9 > > #9 0xffffffff81a1cb96 in smbfs_unmount (mp=0xfffff80015226000, > > mntflags=) at > > /usr/src/sys/modules/smbfs/../../fs/smbfs/smbfs_vfsops.c:297 > > 297 sdp_trydestroy(dev); > > (kgdb) frame 10 > > #10 0xffffffff809d9e84 in dounmount (mp=0xfffff80015226000, > > flags=134217728, td=0xfffff800151b0940) at > > /usr/src/sys/kern/vfs_mount.c:1313 > > 1313 error = VFS_UNMOUNT(mp, flags); > > (kgdb) > > > > Let me know if you need anything else from the stackframes. > > > > > > Greetings > > Christian > > > > > > > > -- > Christian Kratzer CK Software GmbH > Email: ck@cksoft.de Wildberger Weg 24/2 > Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden > Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart > Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer > Web: http://www.cksoft.de/ > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@freebsd.org Mon Oct 12 13:56:00 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46A5BA11EF9 for ; Mon, 12 Oct 2015 13:56:00 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from mx1.cksoft.de (mx1.cksoft.de [IPv6:2001:67c:24f8:1::25:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.cksoft.de", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D1FB263B; Mon, 12 Oct 2015 13:55:59 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from m.cksoft.de (unknown [IPv6:2a01:170:1110:8001::25:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.cksoft.de (Postfix) with ESMTPSA id 668261E9EB2; Mon, 12 Oct 2015 15:55:56 +0200 (CEST) Received: from amavis.cksoft.de (unknown [IPv6:2a01:170:1110:8001::25:a1]) by m.cksoft.de (Postfix) with ESMTP id 2361A631CF; Mon, 12 Oct 2015 15:54:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from m.cksoft.de ([IPv6:2a01:170:1110:8001::25:1]) by amavis.cksoft.de (amavis.cksoft.de [IPv6:2a01:170:1110:8001::25:a1]) (amavisd-new, port 10041) with ESMTP id HZvy3XqRLktK; Mon, 12 Oct 2015 15:54:22 +0200 (CEST) Received: from noc1.cksoft.de (noc1.cksoft.de [IPv6:2a01:170:1110:8001::53:1]) by m.cksoft.de (Postfix) with ESMTP id E5ACF62FA4; Mon, 12 Oct 2015 15:54:21 +0200 (CEST) Received: by noc1.cksoft.de (Postfix, from userid 1000) id 6FE3613BD3; Mon, 12 Oct 2015 15:55:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by noc1.cksoft.de (Postfix) with ESMTP id 6717613B4B; Mon, 12 Oct 2015 15:55:53 +0200 (CEST) Date: Mon, 12 Oct 2015 15:55:53 +0200 (CEST) From: Christian Kratzer X-X-Sender: ck@noc1.cksoft.de Reply-To: Christian Kratzer To: Rick Macklem cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: smbfs crashes since approx. 10.1-RELEASE In-Reply-To: <2135054744.32546564.1444653156980.JavaMail.zimbra@uoguelph.ca> Message-ID: References: <2148690.gx9M0ZzrG1@ralph.baldwin.cx> <3563189.eDHDcCgW5L@ralph.baldwin.cx> <358885214.31305796.1444518367048.JavaMail.zimbra@uoguelph.ca> <2135054744.32546564.1444653156980.JavaMail.zimbra@uoguelph.ca> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) X-Spammer-Kill-Ratio: 75% MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 13:56:00 -0000 Hi Rick, On Mon, 12 Oct 2015, Rick Macklem wrote: > Christian Kratzer wrote: >> Hi Rick, >> >> there was also a second more recent crash in /var/crash >> >> Mon Oct 12 03:01:16 CEST 2015 >> >> FreeBSD noc3.cksoft.de 10.2-STABLE FreeBSD 10.2-STABLE #2 r288980M: Sun >> Oct 11 08:37:40 CEST 2015 >> ck@noc3.cksoft.de:/usr/obj/usr/src/sys/NOC amd64 >> >> panic: Assertion mtx_unowned(m) failed at >> /usr/src/sys/kern/kern_mutex.c:955 >> > Oops, I screwed up. I should have looked at this panic assertion when you reported > it before. Ok, so if I understand the assertion correctly, it means that another > thread has the mutex locked. If this is correct, I'll have to take another look at > the code and figure out how to wait for these other threads to finish with the mutexes. > > I do think the patch fixes the race I saw, but there must be other races in the code. > > I'll take another look, but if anyone else is conversant with netsmb, feel free to > jump in, because it is all new to me. > > Unfortunately, I won't have any way to do testing for the next month or so, so any > patches I do come up with will be "try this untested..". thats no problem. Just keep the patches coming when you have time and tell me when to reset back to stable, current or whatever so we don't lose sync of the status. As it looks like that the race happens on unmount I could try putting a sleep 60 into the script that does the "mount && rsycn && umount" magic just before the umount. That would allow anything that it slow to go away to perhaps release the mutexes before the umount. Not a real fix of course but might help to verify what's going on. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ From owner-freebsd-stable@freebsd.org Mon Oct 12 18:47:59 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C95D8A12144 for ; Mon, 12 Oct 2015 18:47:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A0811BD1 for ; Mon, 12 Oct 2015 18:47:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by igcpe7 with SMTP id pe7so86970903igc.0 for ; Mon, 12 Oct 2015 11:47:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:content-type:subject:date:message-id :to:mime-version; bh=QeJqTMy3xsMnRShbb/qgntygLsokyyce+4pbncqwnZo=; b=muE18AAaJ2v/bLK+gW7vibRzGQqGbfuVwftirUfU8vd/rE1FXr0r45Msp2tlUR0bIy 0VWqJF/JaiyjvGSRCZ8vtp244Axw1QSv2aQ/T5djTQdowWFQ9IOhOHUWAhq/JQXtrS2Q JWLEjS1GZeSZ7w9XO01LeMtQUSYe/DK7Gs6blJfqy4ebrsW7bF65EIR/8Oe3joxMvdUc QJs+1ij8j6ozIdUCUfn/mQdSAmTNsGlrHO6Xzwsz5vdCZdMrQCyus78H8CDnOhSghYYa nGeWGXdCBBrm0MHOIrGXiY/gO58lVDYTMYe2LFuNqh1w7QvxmmAbHlwRShNfVKRlyR35 l+dA== X-Gm-Message-State: ALoCoQlxCnWPqvtoMpxpxKgoCBwDw3pbzh1eHSJkQr+IFHlnd123ewydOmx0edBh9WS71uWo0ymZ X-Received: by 10.50.30.101 with SMTP id r5mr14697990igh.35.1444675672873; Mon, 12 Oct 2015 11:47:52 -0700 (PDT) Received: from ?IPv6:2601:280:4900:3700:749d:fbb4:f079:870c? ([2601:280:4900:3700:749d:fbb4:f079:870c]) by smtp.gmail.com with ESMTPSA id 189sm7388881ioe.40.2015.10.12.11.47.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Oct 2015 11:47:51 -0700 (PDT) Sender: Warner Losh From: Warner Losh X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_A9A54F8C-F801-4E94-900F-695E03DB3C40"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: A quick poll Date: Mon, 12 Oct 2015 12:47:50 -0600 Message-Id: To: FreeBSD Current , FreeBSD Stable Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 18:48:00 -0000 --Apple-Mail=_A9A54F8C-F801-4E94-900F-695E03DB3C40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings, The topic of including /usr/local in the paths for compilers, linkers, = etc has come up again. I=E2=80=99ve started a poll to judge sentiment in = the community about what the default policy of FreeBSD should be in this = regard. This topic has been much debated in the past. Those against it generally = believe that it pollutes the namespace to include /usr/local/* by = default. The defaults should only include what we include in the system = to avoid accidents. Those for it say that it has become standard in = other projects and that makes it easier for people porting software to = FreeBSD as well as making it easier for users to use stuff they=E2=80=99ve= installed from ports. I make no judgement over which one is =E2=80=9Ccorrect=E2=80=9D since I = can understand the argument on both sides. So I=E2=80=99ve created this poll https://reviews.freebsd.org/V6 to gage = opinion of the project and its users. If I did things right, the poll is = open to everybody. The poll will be used as data, but I make no promises = about what will happen with this data. The poll will sat for 2 weeks, = and I=E2=80=99ll publish the results here. Warner --Apple-Mail=_A9A54F8C-F801-4E94-900F-695E03DB3C40 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWHABWAAoJEGwc0Sh9sBEAZs4QAJNDSjS2taRz/b0Kw/aAdKYC bQmB+N71aDGm6OFyHQZlHSbPyZWFA346RrqaKJagw+AMvcXZB258tMLW0NwTeko+ ZRTBmp5TlKOmboTHzwjueN67svK6IbtEcpWGHhkwFnjinQcaU3cCyOBzvAKme+fH Kcp3+lA6aoTtx0IeWYVGsRb9adz5OJVXUNNpncQTAhBPj5wTkp7Sihq4d0M8Z9YR LE1XnvbWCIivxDnTK/12GzgZQPyi5Oez5WBiuvZWTmx+f4opJ6eB7OISYkoavSAF Q9xaJpxbT8ZgbfJCt0rdBnOOaYwMqFNt191rbpBcSLRW+bjZaX3TTWNtFdZgapd5 Qm8OitggaUhnsBrgIcy/Php2JldG7aBQ6gCuPUokYx+UXYHO/H9NzD8T+PQwgJ44 iQJdI3kaeFnBlQzlXMOxF64h+ZZxE1quRFKcxHDq7jUeF7nySkxDTUeJ40DKZNUL SynEKaTWDIfanKwGPSiz9hG/rA79nqtA1xkbtUCypLqr+mNaY3rGUR9y5/xJar3K ofPrKMsFsltWNGC+MR9EupqgzMmaYkPszYLB2+ckpFba74h1y5j4R1DKAYtclbKe vvIG1gJJg7bTI277Akp84zD3QBePrnDlJ6GpMev05z30zW9Cl2D1fVcDW5oi0upC UOGH5GlN8oG8ThBi4P01 =cuFM -----END PGP SIGNATURE----- --Apple-Mail=_A9A54F8C-F801-4E94-900F-695E03DB3C40-- From owner-freebsd-stable@freebsd.org Tue Oct 13 02:47:42 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 762FDA10600 for ; Tue, 13 Oct 2015 02:47:42 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id F42091CDC; Tue, 13 Oct 2015 02:47:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:VaUYCh/6QOdEPv9uRHKM819IXTAuvvDOBiVQ1KB91O8cTK2v8tzYMVDF4r011RmSDdmdu6gP0bCN+4nbGkU+or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6anHS+4HYoFwnlMkItf6KuStKU3578jbrps7ToICx2xxOFKYtoKxu3qQiD/uI3uqBFbpgL9x3Sv3FTcP5Xz247bXianhL7+9vitMU7q3cYk7sb+sVBSaT3ebgjBfwdVWx+cjN92Mq+nhnZTBCT53IaGkYMmwZaDhKNuBr5dpzyqSz0qqxx1X/JE9fxSOUOWD+hp4JiQxzshSJPYyQ8+WrUjsF1pL9crw+sowR/hYXdNtLGfMFid7/QKItJDVFKWdxcAmkYWtux X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BTAwBFcBxW/61jaINVCIN6bga+Bw6BWhcKgnKCCjVKAoFwFAEBAQEBAQEBgQmCH4IHAQEBAwEBAQEgBCcgCwUJAgIBCA4KERkCAgIZDAEJJgIECAcEARwEiAUIDaxbk1sBAQEBAQEBAQEBAQEBAQEBAQEBGQSGb4R+hCoMBAIBGwEZGweCaYFFBYc6hwWHVYJOgkuFGYRASJV0g20CHwFDghEdgXAiMweFZIEGAQEB X-IronPort-AV: E=Sophos;i="5.17,676,1437451200"; d="scan'208";a="244150647" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-annu.net.uoguelph.ca with ESMTP; 12 Oct 2015 22:47:39 -0400 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 0B73E15F55D; Mon, 12 Oct 2015 22:47:40 -0400 (EDT) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id VmxkLXYEU6ON; Mon, 12 Oct 2015 22:47:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 16F7715F565; Mon, 12 Oct 2015 22:47:39 -0400 (EDT) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lgUcKKPbZeOv; Mon, 12 Oct 2015 22:47:38 -0400 (EDT) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id EA40915F55D; Mon, 12 Oct 2015 22:47:38 -0400 (EDT) Date: Mon, 12 Oct 2015 22:47:38 -0400 (EDT) From: Rick Macklem To: Christian Kratzer Cc: freebsd-stable@freebsd.org, John Baldwin Message-ID: <173739656.33429352.1444704458926.JavaMail.zimbra@uoguelph.ca> In-Reply-To: References: <3563189.eDHDcCgW5L@ralph.baldwin.cx> <358885214.31305796.1444518367048.JavaMail.zimbra@uoguelph.ca> <2135054744.32546564.1444653156980.JavaMail.zimbra@uoguelph.ca> Subject: Re: smbfs crashes since approx. 10.1-RELEASE MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_33429350_1097493246.1444704458924" X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF34 (Win)/8.0.9_GA_6191) Thread-Topic: smbfs crashes since approx. 10.1-RELEASE Thread-Index: labyDeG/iqIuDF9w9rT8eAtMqRd0/w== X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 02:47:42 -0000 ------=_Part_33429350_1097493246.1444704458924 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Christian Kratzer wrote: > Hi Rick, > > On Mon, 12 Oct 2015, Rick Macklem wrote: > > > Christian Kratzer wrote: > >> Hi Rick, > >> > >> there was also a second more recent crash in /var/crash > >> > >> Mon Oct 12 03:01:16 CEST 2015 > >> > >> FreeBSD noc3.cksoft.de 10.2-STABLE FreeBSD 10.2-STABLE #2 r288980M: > >> Sun > >> Oct 11 08:37:40 CEST 2015 > >> ck@noc3.cksoft.de:/usr/obj/usr/src/sys/NOC amd64 > >> > >> panic: Assertion mtx_unowned(m) failed at > >> /usr/src/sys/kern/kern_mutex.c:955 > >> > > Oops, I screwed up. I should have looked at this panic assertion when you > > reported > > it before. Ok, so if I understand the assertion correctly, it means that > > another > > thread has the mutex locked. If this is correct, I'll have to take another > > look at > > the code and figure out how to wait for these other threads to finish with > > the mutexes. > > > > I do think the patch fixes the race I saw, but there must be other races in > > the code. > > > > I'll take another look, but if anyone else is conversant with netsmb, feel > > free to > > jump in, because it is all new to me. > > > > Unfortunately, I won't have any way to do testing for the next month or so, > > so any > > patches I do come up with will be "try this untested..". > > thats no problem. > > Just keep the patches coming when you have time and tell me when to reset > back to stable, > current or whatever so we don't lose sync of the status. > Well, you can try the attached one instead of the previous ones (ie. against stable). It just delays destroying the mutexes until the iod thread is exiting. I can't quite see why the previous patches wouldn't fix it, but this one leaves smb_iod_main() unchanged, so it is a simpler patch and doesn't affect semantics except for a slight delay in destroying the mutexes. > As it looks like that the race happens on unmount I could try putting a sleep > 60 into the > script that does the "mount && rsycn && umount" magic just before the umount. > That would > allow anything that it slow to go away to perhaps release the mutexes before > the umount. > If it still crashes with this patch, it might be worth a try. Or, if this patch still crashes, you could just delete the 3 lines that the patch moves, so the mutexes are never destroyed. This would result in a leak, but it would tell us if destroying these mutexes is the problem. Thanks for your willingness to test these, rick > Not a real fix of course but might help to verify what's going on. > > Greetings > Christian > > > -- > Christian Kratzer CK Software GmbH > Email: ck@cksoft.de Wildberger Weg 24/2 > Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden > Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart > Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer > Web: http://www.cksoft.de/ > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > ------=_Part_33429350_1097493246.1444704458924 Content-Type: text/x-patch; name=smbiod2.patch Content-Disposition: attachment; filename=smbiod2.patch Content-Transfer-Encoding: base64 LS0tIHNtYl9pb2QuYy5vcmlnCTIwMTUtMTAtMTAgMTg6NTM6MzQuMDAwMDAwMDAwIC0wNDAwCisr KyBzbWJfaW9kLmMJMjAxNS0xMC0xMiAyMDozMDowMC4wMDAwMDAwMDAgLTA0MDAKQEAgLTY1OSw2 ICs2NTksMTEgQEAgc21iX2lvZF90aHJlYWQodm9pZCAqYXJnKQogCQkJYnJlYWs7CiAJCXRzbGVl cCgmaW9kLT5pb2RfZmxhZ3MsIFBXQUlULCAiOTBpZGxlIiwgaW9kLT5pb2Rfc2xlZXB0aW1vKTsK IAl9CisKKwkvKiBXZSBjYW4gbm93IHNhZmVseSBkZXN0cm95IHRoZSBtdXRleGVzIGFuZCBmcmVl IHRoZSBpb2Qgc3RydWN0dXJlLiAqLworCXNtYl9zbF9kZXN0cm95KCZpb2QtPmlvZF9ycWxvY2sp OworCXNtYl9zbF9kZXN0cm95KCZpb2QtPmlvZF9ldmxvY2spOworCWZyZWUoaW9kLCBNX1NNQklP RCk7CiAJbXR4X3VubG9jaygmR2lhbnQpOwogCWtwcm9jX2V4aXQoMCk7CiB9CkBAIC02OTUsOSAr NzAwLDYgQEAgaW50CiBzbWJfaW9kX2Rlc3Ryb3koc3RydWN0IHNtYmlvZCAqaW9kKQogewogCXNt Yl9pb2RfcmVxdWVzdChpb2QsIFNNQklPRF9FVl9TSFVURE9XTiB8IFNNQklPRF9FVl9TWU5DLCBO VUxMKTsKLQlzbWJfc2xfZGVzdHJveSgmaW9kLT5pb2RfcnFsb2NrKTsKLQlzbWJfc2xfZGVzdHJv eSgmaW9kLT5pb2RfZXZsb2NrKTsKLQlmcmVlKGlvZCwgTV9TTUJJT0QpOwogCXJldHVybiAwOwog fQogCg== ------=_Part_33429350_1097493246.1444704458924-- From owner-freebsd-stable@freebsd.org Tue Oct 13 07:28:59 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8EDF9A125A1 for ; Tue, 13 Oct 2015 07:28:59 +0000 (UTC) (envelope-from maurizio.vairani@cloverinformatica.it) Received: from host202-129-static.10-188-b.business.telecomitalia.it (host202-129-static.10-188-b.business.telecomitalia.it [188.10.129.202]) by mx1.freebsd.org (Postfix) with ESMTP id 4739C9AB for ; Tue, 13 Oct 2015 07:28:58 +0000 (UTC) (envelope-from maurizio.vairani@cloverinformatica.it) Received: from [192.168.0.60] (unknown [192.168.0.60]) by host202-129-static.10-188-b.business.telecomitalia.it (Postfix) with ESMTP id 93664122E49; Tue, 13 Oct 2015 09:20:19 +0200 (CEST) Subject: Re: help with partitioning - huge stripesize To: =?UTF-8?Q?Marko_Cupa=c4=87?= , freebsd-stable@freebsd.org References: <20151012134614.0a95076b@efreet.kappastar.com> From: Maurizio Vairani Message-ID: <561CB0B3.2090008@cloverinformatica.it> Date: Tue, 13 Oct 2015 09:20:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151012134614.0a95076b@efreet.kappastar.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 07:28:59 -0000 Il 12/10/2015 13:46, Marko Cupać ha scritto: > Hi, > > I've got HP ProLiant DL320g5p server with HP Smart Array E200 RAID > controller and 4X300Gb SAS disks. > > I'd like to use it for hosting jails on ZFS, but no matter how I create > zpool, I always get a warning about non-native block size: > > block size: 8192B configured, 1048576B native > > I know it is optimal for ZFS to have direct access to disks, but HP > Smart Array E200 apparently does not support JBOD mode. I tried to > configure both single RAID-5 logical volume and four RAID-0 > logical volumes, in both cases diskinfo gives me the following: > > 512 # sectorsize > 299966445568 # mediasize in bytes (279G) > 585871964 # mediasize in sectors > 1048576 # stripesize > 643072 # stripeoffset > 71798 # Cylinders according to firmware. > 255 # Heads according to firmware. > 32 # Sectors according to firmware. > PA6C90R9SXK07P # Disk ident. > > With hardware I have, is it better to create single RAID-5 logical > volume in HP Smart Array E200 and let ZFS think it deals with single > physical drive, or four RAID-0 logical volumes and let ZFS think it > deals with four physical drives? > > Can I just ignore warning about non-native block size? If not, how can > I make it go away? > > Thank you in advance, Hi, in my HP ProLiant Microserver Gen8, via BIOS, is possible to disable the Dynamic HP Smart Array B120i RAID Support and enable the SATA AHCI Support. ZFS works as expected and the block size is correct. Regards, Maurizio From owner-freebsd-stable@freebsd.org Tue Oct 13 08:16:52 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47CCAA116F0 for ; Tue, 13 Oct 2015 08:16:52 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from mx1.cksoft.de (mx1.cksoft.de [IPv6:2001:67c:24f8:1::25:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.cksoft.de", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 017D3AAC; Tue, 13 Oct 2015 08:16:52 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from m.cksoft.de (unknown [IPv6:2a01:170:1110:8001::25:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.cksoft.de (Postfix) with ESMTPSA id 27F101E9EB2; Tue, 13 Oct 2015 10:16:48 +0200 (CEST) Received: from amavis.cksoft.de (unknown [IPv6:2a01:170:1110:8001::25:a1]) by m.cksoft.de (Postfix) with ESMTP id A155363348; Tue, 13 Oct 2015 10:15:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from m.cksoft.de ([192.168.64.93]) by amavis.cksoft.de (amavis.cksoft.de [192.168.64.94]) (amavisd-new, port 10041) with ESMTP id QjGpJDNrc3-2; Tue, 13 Oct 2015 10:15:15 +0200 (CEST) Received: from noc1.cksoft.de (noc1.cksoft.de [IPv6:2a01:170:1110:8001::53:1]) by m.cksoft.de (Postfix) with ESMTP id BD82463347; Tue, 13 Oct 2015 10:15:14 +0200 (CEST) Received: by noc1.cksoft.de (Postfix, from userid 1000) id C110B13BEC; Tue, 13 Oct 2015 10:16:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by noc1.cksoft.de (Postfix) with ESMTP id BABBB13B2E; Tue, 13 Oct 2015 10:16:46 +0200 (CEST) Date: Tue, 13 Oct 2015 10:16:46 +0200 (CEST) From: Christian Kratzer X-X-Sender: ck@noc1.cksoft.de Reply-To: Christian Kratzer To: Rick Macklem cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: smbfs crashes since approx. 10.1-RELEASE In-Reply-To: <173739656.33429352.1444704458926.JavaMail.zimbra@uoguelph.ca> Message-ID: References: <3563189.eDHDcCgW5L@ralph.baldwin.cx> <358885214.31305796.1444518367048.JavaMail.zimbra@uoguelph.ca> <2135054744.32546564.1444653156980.JavaMail.zimbra@uoguelph.ca> <173739656.33429352.1444704458926.JavaMail.zimbra@uoguelph.ca> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) X-Spammer-Kill-Ratio: 75% MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 08:16:52 -0000 Hi Rick, On Mon, 12 Oct 2015, Rick Macklem wrote: > Well, you can try the attached one instead of the previous ones (ie. against stable). > It just delays destroying the mutexes until the iod thread is exiting. > > I can't quite see why the previous patches wouldn't fix it, but this one leaves > smb_iod_main() unchanged, so it is a simpler patch and doesn't affect semantics > except for a slight delay in destroying the mutexes. patch applied this morning against plain 10-stable with wittness enabled ... >> As it looks like that the race happens on unmount I could try putting a sleep >> 60 into the >> script that does the "mount && rsycn && umount" magic just before the umount. >> That would >> allow anything that it slow to go away to perhaps release the mutexes before >> the umount. >> > If it still crashes with this patch, it might be worth a try. I had a sleep 60 before the umount over night and it did not crash. Could have been to short a wait though. I have removed the sleep 60 in order to give your patch a good testing > Or, if this patch still crashes, you could just delete the 3 lines that the > patch moves, so the mutexes are never destroyed. This would result in a leak, > but it would tell us if destroying these mutexes is the problem. Good point. > Thanks for your willingness to test these, rick No problem. Thanks to you for wrapping your head around this. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ From owner-freebsd-stable@freebsd.org Tue Oct 13 09:19:03 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF85AA113D8; Tue, 13 Oct 2015 09:19:03 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay101.isp.belgacom.be (mailrelay101.isp.belgacom.be [195.238.20.128]) by mx1.freebsd.org (Postfix) with ESMTP id 25220F68; Tue, 13 Oct 2015 09:19:02 +0000 (UTC) (envelope-from tijl@freebsd.org) X-Belgacom-Dynamic: yes X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=on0vsgdz1NEtXcMZlQwg/MwbIQQ3jhei9UjQb9HCs8o= c=1 sm=2 a=7Qk2ozbKAAAA:8 a=6I5d2MoRAAAA:8 a=b3cQk7Ea5mLVsm062zIA:9 a=QEXdDO2ut3YA:10 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2ATJgBoyxxW/zhosVtdgyZUXw+/dx2CdoIKfwKBPT0QAQEBAQEBAYEKQQEEAYNgAQEEIzMjEAsYAgIFIQICDyoeBgESFIgeAax2k1wBAQEBAQEBAwEBAQEBAQEXBIEiilGEWjMHgmmBRQEElhaFGYJwhQlimy44K4IRHYFWPDOCc4E6gkQBAQE Received: from 56.104-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.104.56]) by relay.skynet.be with ESMTP; 13 Oct 2015 11:17:48 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.15.2/8.15.2) with ESMTP id t9D9HbX6001998; Tue, 13 Oct 2015 11:17:38 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Tue, 13 Oct 2015 11:17:37 +0200 From: Tijl Coosemans To: FreeBSD Current , FreeBSD Stable Subject: Re: A quick poll Message-ID: <20151013111737.7f3f7029@kalimero.tijl.coosemans.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 09:19:03 -0000 On Mon, 12 Oct 2015 12:47:50 -0600 Warner Losh wrote: > The topic of including /usr/local in the paths for compilers, linkers, > etc has come up again. I=E2=80=99ve started a poll to judge sentiment in = the > community about what the default policy of FreeBSD should be in this > regard. >=20 > This topic has been much debated in the past. Those against it generally > believe that it pollutes the namespace to include /usr/local/* by > default. The defaults should only include what we include in the system > to avoid accidents. Those for it say that it has become standard in > other projects and that makes it easier for people porting software to > FreeBSD as well as making it easier for users to use stuff they=E2=80=99ve > installed from ports. >=20 > I make no judgement over which one is =E2=80=9Ccorrect=E2=80=9D since I c= an understand > the argument on both sides. >=20 > So I=E2=80=99ve created this poll https://reviews.freebsd.org/V6 to gage = opinion > of the project and its users. If I did things right, the poll is open to > everybody. The poll will be used as data, but I make no promises about > what will happen with this data. The poll will sat for 2 weeks, and I=E2= =80=99ll > publish the results here. The current situation is bit messed up. The base system compiler and the Clang/LLVM ports don't search /usr/local, but lang/gcc* does. It searches /usr/local/include (actually PREFIX/include) *before* /usr/include: % cpp49 -v < /dev/null ... #include <...> search starts here: /usr/local/lib/gcc49/gcc/i386-portbld-freebsd11.0/4.9.3/include /usr/local/include /usr/local/lib/gcc49/gcc/i386-portbld-freebsd11.0/4.9.3/include-fixed /usr/include And ld from devel/binutils (used by lang/gcc*) searches /usr/local/lib *after* /usr/lib: % grep SEARCH /usr/local/i386-portbld-freebsd11.0/lib/ldscripts/elf_i386_fb= sd.x SEARCH_DIR("=3D/usr/local/i386-portbld-freebsd11.0/lib"); SEARCH_DIR("=3D/lib"); SEARCH_DIR("=3D/usr/lib"); SEARCH_DIR("=3D/usr/local/lib"); So whatever is decided, at least make all compilers/linkers consistent and let them search directories in the same order. From owner-freebsd-stable@freebsd.org Wed Oct 14 13:53:12 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC5FDA13BD9 for ; Wed, 14 Oct 2015 13:53:12 +0000 (UTC) (envelope-from frank@zzattack.org) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4740F13DB for ; Wed, 14 Oct 2015 13:53:11 +0000 (UTC) (envelope-from frank@zzattack.org) Received: by wieq12 with SMTP id q12so84503614wie.1 for ; Wed, 14 Oct 2015 06:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zzattack.org; s=google; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=bbbwAGqdrM0EXyWkRYL/z/f4sUFT8jAX5kfiEnErOPM=; b=k1GEOer0WUtL1T9Cqdvr2oIi1OsGOQCQ9Sq/oHTMErmdTeo8yrObSxYWzUfwE5YRCI 7cwwtiRYBpBW7JQvSMiBXqydHxv4VzSJSUbM2lNmJwwn0Ad3Bjs184iyrmHw8niq3ASC 60zs9olJuHTVYZTzSUuZpG1ipml0+yUuZ9ucw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=bbbwAGqdrM0EXyWkRYL/z/f4sUFT8jAX5kfiEnErOPM=; b=UKwzNGZZr0oGt8cNG6Tlkv62pWrZpKKlgoL5aICWNL9dXTMPI4C1l3fwDoQa4X1a45 F7UvC0h8smYl3EpbjjrkSVAvCI/lNiad460QhNi7QvbGoDFqTb3EhbDtEr92FVJyCB0t uLHA01UiN/YrLdUiI01x5iwngDDKUziOt2ZYFO/nQLSUn+5pVbLM+GmBVD4Xh+p97lXh lSJhNJ+q5INNOT/cM8cAX3NAYJrio/VLw0fboFNI7XcIi8P6g5LyyBXoVNDdC8VNPzhN Y7nzlYH4KIwlxvBk67I0klU6HVE1BsM3RHoGiBVQVFoqflw3h0+ZNoRXms9dP+84gzMI /taQ== X-Gm-Message-State: ALoCoQlYBmBlQuASLdvq4DLHu8NsPc7tcpD1owzSkwP5SS8blI5+8V+pjR0Df+Yefc0x/Buyz0uT X-Received: by 10.180.9.74 with SMTP id x10mr4472656wia.61.1444830765799; Wed, 14 Oct 2015 06:52:45 -0700 (PDT) Received: from [10.31.45.20] (38-106-201-31.ftth.glasoperator.nl. [31.201.106.38]) by smtp.googlemail.com with ESMTPSA id x7sm19406781wia.10.2015.10.14.06.52.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2015 06:52:45 -0700 (PDT) To: freebsd-stable@freebsd.org From: Frank Razenberg Subject: 10.2-STABLE amd64 panic: page fault while in kernel mode Message-ID: <561E5E2F.90404@zzattack.org> Date: Wed, 14 Oct 2015 15:52:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 13:53:12 -0000 After upgrading from 9.2 to 10.1 I first started noticing panics. They occurred roughly weekly and since this storage machine isn't frequently used I didn't look into it much further. After updating for 10.2-STABLE the panics have gone from weekly to daily. The machine has 32GB of non-registered ECC DDR3-1066 RAM. There's also a 10-disk raidz2 pool. I've ran memtest86+ for 72 hours straight with no errors. Crash dumps all feature the following: Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 12 fault virtual address = 0x1d1c0bec0 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff804fda65 stack pointer = 0x28:0xfffffe0698f21870 frame pointer = 0x28:0xfffffe0698f218d0 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 = 6106 (pickup) trap number = 12 panic: page fault cpuid = 2 (kgdb) bt #0 doadump (textdump=) at pcpu.h:219 #1 0xffffffff8053ce32 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:455 #2 0xffffffff8053d215 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:762 #3 0xffffffff8053d0a3 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:691 #4 0xffffffff807755db in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:851 #5 0xffffffff807758dd in trap_pfault (frame=0xfffffe0698dbc7c0, usermode=) at /usr/src/sys/amd64/amd64/trap.c:674 #6 0xffffffff80774f7a in trap (frame=0xfffffe0698dbc7c0) at /usr/src/sys/amd64/amd64/trap.c:440 #7 0xffffffff8075b0f2 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 #8 0xffffffff804fda65 in kqueue_close (fp=0xfffff803e4967190, td=0xfffff80014b094a0) at /usr/src/sys/kern/kern_event.c:1750 #9 0xffffffff804f25f9 in _fdrop (fp=0xfffff803e4967190, td=0xfffff802b5d2a000) at file.h:343 #10 0xffffffff804f4e9e in closef (fp=, td=) at /usr/src/sys/kern/kern_descrip.c:2338 #11 0xffffffff804f4ab9 in fdescfree (td=0xfffff80014b094a0) at /usr/src/sys/kern/kern_descrip.c:2106 #12 0xffffffff805013a9 in exit1 (td=0xfffff80014b094a0, rv=) at /usr/src/sys/kern/kern_exit.c:369 #13 0xffffffff80500e3e in sys_sys_exit (td=0xfffffe000782e060, uap=) at /usr/src/sys/kern/kern_exit.c:179 #14 0xffffffff80775efd in amd64_syscall (td=0xfffff80014b094a0, traced=0) at subr_syscall.c:134 #15 0xffffffff8075b3db in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:396 #16 0x000000080120335a in ?? () Most of the dumps list 'pickup' as current process. All of them have 'kqueue_close' in the backtrace. I'm not sure what the next step in diagnosing the issue is. Any pointers would be greatly appreciated. -Frank From owner-freebsd-stable@freebsd.org Wed Oct 14 14:42:24 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8EAFDA1396E for ; Wed, 14 Oct 2015 14:42:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1CE11231 for ; Wed, 14 Oct 2015 14:42:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t9EEgIP2002165 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 14 Oct 2015 17:42:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t9EEgIP2002165 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t9EEgHTW002164; Wed, 14 Oct 2015 17:42:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 14 Oct 2015 17:42:17 +0300 From: Konstantin Belousov To: Frank Razenberg Cc: freebsd-stable@freebsd.org Subject: Re: 10.2-STABLE amd64 panic: page fault while in kernel mode Message-ID: <20151014144217.GV2257@kib.kiev.ua> References: <561E5E2F.90404@zzattack.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <561E5E2F.90404@zzattack.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 14:42:24 -0000 On Wed, Oct 14, 2015 at 03:52:47PM +0200, Frank Razenberg wrote: > After upgrading from 9.2 to 10.1 I first started noticing panics. They > occurred roughly weekly and since this storage machine isn't frequently > used I didn't look into it much further. After updating for 10.2-STABLE > the panics have gone from weekly to daily. > The machine has 32GB of non-registered ECC DDR3-1066 RAM. There's also a > 10-disk raidz2 pool. I've ran memtest86+ for 72 hours straight with no > errors. > > Crash dumps all feature the following: > > Fatal trap 12: page fault while in kernel mode > cpuid = 2; apic id = 12 > fault virtual address = 0x1d1c0bec0 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff804fda65 > stack pointer = 0x28:0xfffffe0698f21870 > frame pointer = 0x28:0xfffffe0698f218d0 > 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 = 6106 (pickup) > trap number = 12 > panic: page fault > cpuid = 2 > > > (kgdb) bt > #0 doadump (textdump=) at pcpu.h:219 > #1 0xffffffff8053ce32 in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:455 > #2 0xffffffff8053d215 in vpanic (fmt=, ap= optimized out>) at /usr/src/sys/kern/kern_shutdown.c:762 > #3 0xffffffff8053d0a3 in panic (fmt=0x0) at > /usr/src/sys/kern/kern_shutdown.c:691 > #4 0xffffffff807755db in trap_fatal (frame=, > eva=) at /usr/src/sys/amd64/amd64/trap.c:851 > #5 0xffffffff807758dd in trap_pfault (frame=0xfffffe0698dbc7c0, > usermode=) at /usr/src/sys/amd64/amd64/trap.c:674 > #6 0xffffffff80774f7a in trap (frame=0xfffffe0698dbc7c0) at > /usr/src/sys/amd64/amd64/trap.c:440 > #7 0xffffffff8075b0f2 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:236 > #8 0xffffffff804fda65 in kqueue_close (fp=0xfffff803e4967190, > td=0xfffff80014b094a0) at /usr/src/sys/kern/kern_event.c:1750 > #9 0xffffffff804f25f9 in _fdrop (fp=0xfffff803e4967190, > td=0xfffff802b5d2a000) at file.h:343 > #10 0xffffffff804f4e9e in closef (fp=, td= optimized out>) at /usr/src/sys/kern/kern_descrip.c:2338 > #11 0xffffffff804f4ab9 in fdescfree (td=0xfffff80014b094a0) at > /usr/src/sys/kern/kern_descrip.c:2106 > #12 0xffffffff805013a9 in exit1 (td=0xfffff80014b094a0, rv= optimized out>) at /usr/src/sys/kern/kern_exit.c:369 > #13 0xffffffff80500e3e in sys_sys_exit (td=0xfffffe000782e060, > uap=) at /usr/src/sys/kern/kern_exit.c:179 > #14 0xffffffff80775efd in amd64_syscall (td=0xfffff80014b094a0, > traced=0) at subr_syscall.c:134 > #15 0xffffffff8075b3db in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:396 > #16 0x000000080120335a in ?? () > > Most of the dumps list 'pickup' as current process. All of them have > 'kqueue_close' in the backtrace. > I'm not sure what the next step in diagnosing the issue is. Any pointers > would be greatly appreciated. What is exact revision of the checkout you run, where the panic above occurs ? Please load the kernel.debug + vmcore into kgdb, go to frame 8, and do p *kq p *kn p i p kq->kq_knlist[i].slh_first p *(kq->kq_knlist[i].slh_first) From owner-freebsd-stable@freebsd.org Wed Oct 14 16:10:37 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C8A3A135EC for ; Wed, 14 Oct 2015 16:10:37 +0000 (UTC) (envelope-from frank@zzattack.org) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 97E2C1D55 for ; Wed, 14 Oct 2015 16:10:36 +0000 (UTC) (envelope-from frank@zzattack.org) Received: by wicgb1 with SMTP id gb1so136103635wic.1 for ; Wed, 14 Oct 2015 09:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zzattack.org; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=xkrRnK9KLQFae5oYRZ3S3hfh2pvO1m1gmJfujuQKCg8=; b=nkIWFtl/liw8K/ZJi/VkC/5pHL8+6ktAndYyruo93YjIsV0nvSYS/u1WSZIKEzCXpI r0Xxzy81//1aDqvY+VoTIXboVfB7P5x/iPjoYHO+y6ZrjsmZXiG/xfRHCVtQ9/XsGXqw uEwBjf0O3e5CR1MA9fTmUzSNn2q3241JfCfKA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=xkrRnK9KLQFae5oYRZ3S3hfh2pvO1m1gmJfujuQKCg8=; b=evZH+JL7gUlx/GnplXB0iprBPl/vErOd26mqZSzB+T0Oa92yP4OItU4ebyfHUDc/we hrJZWlxCwVommiOcz97kHCKbjyrSxNoyaY9WN0pVeKZvTbpau7iXoqIblI5eNJ3G1jXf 5D92qMxUGS7ee3NV14hKrmMwWOjDe9w8Wbum89JEv1R3ZI+HdPiFkHiXFthYHCrj8/xV 3KxQby2aYqpPtyyCIcA1zGtMXRMpg76oz7DipfPR29TA+jm8/WRgLQum1EhXUuUYrH8u W1RtCuWAnH5PiXQYVh7IpKiWIhShoKWXiys1ahoztCCtFqq0Rio+mYud/werFhzqIyOK kReQ== X-Gm-Message-State: ALoCoQmuq+QynfITjLR1KaJuYkRMpCWc7wVMrgMI1CF4AvMaox8g887M832mJILsEMsbfCbNJC0L X-Received: by 10.194.114.133 with SMTP id jg5mr4898316wjb.98.1444839032791; Wed, 14 Oct 2015 09:10:32 -0700 (PDT) Received: from [10.31.45.20] (38-106-201-31.ftth.glasoperator.nl. [31.201.106.38]) by smtp.googlemail.com with ESMTPSA id o10sm7723068wia.4.2015.10.14.09.10.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Oct 2015 09:10:31 -0700 (PDT) Subject: Re: 10.2-STABLE amd64 panic: page fault while in kernel mode To: Konstantin Belousov , freebsd-stable@freebsd.org References: <561E5E2F.90404@zzattack.org> <20151014144217.GV2257@kib.kiev.ua> From: Frank Razenberg Message-ID: <561E7E7A.1080600@zzattack.org> Date: Wed, 14 Oct 2015 18:10:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151014144217.GV2257@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 16:10:37 -0000 Thanks for looking into this. On 10/14/2015 4:42 PM, Konstantin Belousov wrote: > On Wed, Oct 14, 2015 at 03:52:47PM +0200, Frank Razenberg wrote: >> After upgrading from 9.2 to 10.1 I first started noticing panics. They >> occurred roughly weekly and since this storage machine isn't frequently >> used I didn't look into it much further. After updating for 10.2-STABLE >> the panics have gone from weekly to daily. >> The machine has 32GB of non-registered ECC DDR3-1066 RAM. There's also a >> 10-disk raidz2 pool. I've ran memtest86+ for 72 hours straight with no >> errors. >> >> Crash dumps all feature the following: >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 2; apic id = 12 >> fault virtual address = 0x1d1c0bec0 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff804fda65 >> stack pointer = 0x28:0xfffffe0698f21870 >> frame pointer = 0x28:0xfffffe0698f218d0 >> 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 = 6106 (pickup) >> trap number = 12 >> panic: page fault >> cpuid = 2 >> >> >> (kgdb) bt >> #0 doadump (textdump=) at pcpu.h:219 >> #1 0xffffffff8053ce32 in kern_reboot (howto=260) at >> /usr/src/sys/kern/kern_shutdown.c:455 >> #2 0xffffffff8053d215 in vpanic (fmt=, ap=> optimized out>) at /usr/src/sys/kern/kern_shutdown.c:762 >> #3 0xffffffff8053d0a3 in panic (fmt=0x0) at >> /usr/src/sys/kern/kern_shutdown.c:691 >> #4 0xffffffff807755db in trap_fatal (frame=, >> eva=) at /usr/src/sys/amd64/amd64/trap.c:851 >> #5 0xffffffff807758dd in trap_pfault (frame=0xfffffe0698dbc7c0, >> usermode=) at /usr/src/sys/amd64/amd64/trap.c:674 >> #6 0xffffffff80774f7a in trap (frame=0xfffffe0698dbc7c0) at >> /usr/src/sys/amd64/amd64/trap.c:440 >> #7 0xffffffff8075b0f2 in calltrap () at >> /usr/src/sys/amd64/amd64/exception.S:236 >> #8 0xffffffff804fda65 in kqueue_close (fp=0xfffff803e4967190, >> td=0xfffff80014b094a0) at /usr/src/sys/kern/kern_event.c:1750 >> #9 0xffffffff804f25f9 in _fdrop (fp=0xfffff803e4967190, >> td=0xfffff802b5d2a000) at file.h:343 >> #10 0xffffffff804f4e9e in closef (fp=, td=> optimized out>) at /usr/src/sys/kern/kern_descrip.c:2338 >> #11 0xffffffff804f4ab9 in fdescfree (td=0xfffff80014b094a0) at >> /usr/src/sys/kern/kern_descrip.c:2106 >> #12 0xffffffff805013a9 in exit1 (td=0xfffff80014b094a0, rv=> optimized out>) at /usr/src/sys/kern/kern_exit.c:369 >> #13 0xffffffff80500e3e in sys_sys_exit (td=0xfffffe000782e060, >> uap=) at /usr/src/sys/kern/kern_exit.c:179 >> #14 0xffffffff80775efd in amd64_syscall (td=0xfffff80014b094a0, >> traced=0) at subr_syscall.c:134 >> #15 0xffffffff8075b3db in Xfast_syscall () at >> /usr/src/sys/amd64/amd64/exception.S:396 >> #16 0x000000080120335a in ?? () >> >> Most of the dumps list 'pickup' as current process. All of them have >> 'kqueue_close' in the backtrace. >> I'm not sure what the next step in diagnosing the issue is. Any pointers >> would be greatly appreciated. > What is exact revision of the checkout you run, where the panic above > occurs ? Not entirely sure. Can I still find out if I've updated my source tree since? It's not in uname -a, but matching the dates it should be around ~289032. Want me to update to HEAD and do the steps below on that instead? > > Please load the kernel.debug + vmcore into kgdb, go to frame 8, and do > p *kq > p *kn > p i > p kq->kq_knlist[i].slh_first > p *(kq->kq_knlist[i].slh_first) #8 0xffffffff804fda65 in kqueue_close (fp=0xfffff801dd94b1e0, td=0xfffff80015bbc000) at /usr/src/sys/kern/kern_event.c:1750 1750 kn->kn_fop->f_detach(kn); (kgdb) p *kq $1 = {kq_lock = {lock_object = {lo_name = 0xffffffff80829725 "kqueue", lo_flags = 21168128, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, kq_refcnt = 1, kq_list = { tqe_next = 0xfffff8015f29fc00, tqe_prev = 0xfffff8000c749860}, kq_head = {tqh_first = 0x0, tqh_last = 0xfffff801dd33a038}, kq_count = 0, kq_sel = {si_tdlist = {tqh_first = 0x0, tqh_last = 0x0}, si_note = {kl_list = {slh_first = 0x0}, kl_lock = 0xffffffff804fc560 , kl_unlock = 0xffffffff804fc5a0 , kl_assert_locked = 0xffffffff804fc5e0 , kl_assert_unlocked = 0xffffffff804fc5f0 , kl_lockarg = 0xfffff801dd33a000}, si_mtx = 0x0}, kq_sigio = 0x0, kq_fdp = 0xfffff8000c749800, kq_state = 16, kq_knlistsize = 256, kq_knlist = 0xfffff8000c7a8800, kq_knhashmask = 0, kq_knhash = 0x0, kq_task = { ta_link = {stqe_next = 0x0}, ta_pending = 0, ta_priority = 0, ta_func = 0xffffffff804faeb0 , ta_context = 0xfffff801dd33a000}} (kgdb) p *kn No symbol "kn" in current context. (kgdb) p i No symbol "i" in current context. From owner-freebsd-stable@freebsd.org Wed Oct 14 21:25:59 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02AFDA15B72 for ; Wed, 14 Oct 2015 21:25:59 +0000 (UTC) (envelope-from lists@searchy.net) Received: from j006.host001.searchy.nl (j006.host001.searchy.nl [79.143.214.199]) by mx1.freebsd.org (Postfix) with ESMTP id BFF1B1259 for ; Wed, 14 Oct 2015 21:25:58 +0000 (UTC) (envelope-from lists@searchy.net) Received: from [192.168.5.21] (5418453B.cm-5-1b.dynamic.ziggo.nl [84.24.69.59]) (Authenticated sender: ppi@j006.host001.searchy.nl) by j006.host001.searchy.nl (Postfix) with ESMTPSA id 064891E8C07 for ; Wed, 14 Oct 2015 21:16:28 +0000 (UTC) Message-ID: <561EC629.30106@searchy.net> Date: Wed, 14 Oct 2015 23:16:25 +0200 From: "Frank de Bot (lists)" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Firefox/34.0 SeaMonkey/2.31 MIME-Version: 1.0 To: FreeBSD Stable Subject: Reloading iscsi target, iscsi initiator panics Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 21:25:59 -0000 Hello, I have a FreeBSD 10.2 server running as iSCSI target. Another FreeBSD 10.2 is an initiator and has several targets used. When I add a target and reload its config with 'service ctld reload', the FreeBSD initiator server panics. It's reproducable (I have a coredump, but I think it's clear what the problem is) How can I have the target reloads it config, without all initiators crashing? Right before the crash the iscsi session drops and reinits Regards, Frank de Bot Related dmesg from the initiator: Oct 14 20:59:49 host004 kernel: (da0:iscsi1:0:0:0): WRITE(10). CDB: 2a 00 00 29 93 c0 00 00 08 00 Oct 14 20:59:49 host004 kernel: (da0:iscsi1:0:0:0): CAM status: SCSI Status Error Oct 14 20:59:49 host004 kernel: (da0:iscsi1:0:0:0): SCSI status: Check Condition Oct 14 20:59:49 host004 kernel: (da0:iscsi1:0:0:0): SCSI sense: UNIT ATTENTION asc:3f,e (Reported LUNs data has changed) Oct 14 20:59:49 host004 kernel: (da0:iscsi1:0:0:0): Retrying command (per sense data) Oct 14 20:59:49 host004 kernel: da0 at iscsi1 bus 0 scbus7 target 0 lun 0 Oct 14 20:59:49 host004 kernel: da0: s/n MYSERIAL 2 detached Oct 14 20:59:49 host004 kernel: (da0:iscsi1:0:0:0): Periph destroyed Oct 14 20:59:49 host004 kernel: da0 at iscsi1 bus 0 scbus7 target 0 lun 0 Oct 14 20:59:49 host004 kernel: da0: Fixed Direct Access SPC-4 SCSI device Oct 14 20:59:49 host004 kernel: da0: Serial Number MYSERIAL 2 Oct 14 20:59:49 host004 kernel: da0: 150.000MB/s transfers Oct 14 20:59:49 host004 kernel: da0: Command Queueing enabled Oct 14 20:59:49 host004 kernel: da0: 20480MB (5242880 4096 byte sectors: 255H 63S/T 326C) From owner-freebsd-stable@freebsd.org Wed Oct 14 22:57:07 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE9BFA15069 for ; Wed, 14 Oct 2015 22:57:07 +0000 (UTC) (envelope-from bad_hdd@list.ru) Received: from fallback2.mail.ru (fallback2.mail.ru [94.100.179.22]) by mx1.freebsd.org (Postfix) with ESMTP id 93BA3FB for ; Wed, 14 Oct 2015 22:57:06 +0000 (UTC) (envelope-from bad_hdd@list.ru) Received: from f123.i.mail.ru (f123.i.mail.ru [94.100.178.187]) by fallback2.mail.ru (mPOP.Fallback_MX) with ESMTP id 6D72010023C37 for ; Thu, 15 Oct 2015 01:57:00 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=list.ru; s=mail; h=Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:To:From; bh=pFWM8VlXs1l77Jo0uVZwjNgfKc39EmFwvTncqV0QPHI=; b=SnME3iyJarontAlmFkaOQ26FcHIOI3eL65ZgFnTlLMrg+sTnTE60iBRuT+ZT1IZKUR65PldFyfoWvBzzy3zh8U3Y2i/dWgjXnb5CasQMFu/N4nW18dMt5jNK4vaHopl3l4F4WdJXaqBt3V1UyrKAoy2xFwSUZRNzEXYJD1DCopc=; Received: from [5.228.103.234] (ident=mail) by f123.i.mail.ru with local (envelope-from ) id 1ZmUyG-0007sH-BM for freebsd-stable@freebsd.org; Thu, 15 Oct 2015 01:56:32 +0300 Received: from [5.228.103.234] by e.mail.ru with HTTP; Thu, 15 Oct 2015 01:56:32 +0300 From: =?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JTQvtC70LHQvdC40L0=?= To: freebsd-stable@freebsd.org Subject: =?UTF-8?B?VGhlcmUgaXMgbm8gbmVlZCBhbnkgUkFJRCBmb3IgWkZT?= MIME-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 X-Originating-IP: [5.228.103.234] Date: Thu, 15 Oct 2015 01:56:32 +0300 Reply-To: =?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JTQvtC70LHQvdC40L0=?= X-Priority: 3 (Normal) Message-ID: <1444863392.589868985@f123.i.mail.ru> X-Mras: Ok X-Spam: undefined Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 22:57:08 -0000 IEJlY2F1c2UgdGhlIG9wdGltYWwgd2F5IG9mIFpGUyBmdW5jdGlvbmluZyBpcyB0byBwcm92aWRl IHN0cmFpZ2h0IGhhcmR3YXJlIGFjY2VzcyBha2EgSkJPRC4gTWFrZSBzdXJlIHlvdXIgY29udHJv bGxlciBpcyBwYXNzaW5nIGJ5IFNNQVJUIGNvbnRyb2wgY29tbWFuZCBzZXQgaWUgeW91IGNhbiBv YnNlcnZlIFNNQVJUIHN0YXR1cyBvZiB5b3VyIGhhZCBkcml2ZXMuCgoKLS0gCkRpbWl0cnkgRG9s Ym5pbgo= From owner-freebsd-stable@freebsd.org Thu Oct 15 11:34:33 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63A8AA120B2 for ; Thu, 15 Oct 2015 11:34:33 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EECC78D5 for ; Thu, 15 Oct 2015 11:34:32 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by wicgb1 with SMTP id gb1so23993376wic.1 for ; Thu, 15 Oct 2015 04:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=dJrV8JbOS0iFnIuFrFmAVrBPdy/WjnuPyjQG5iNuZ3A=; b=f2xLdbCQaZmyWOumQ+h7l0ue3zAFhMny4V2+/ZOOTKmQtkqcPblP1Bg5z99ZSLsV+0 a6KIBsnQPHUc9JnLnoRoJLZW4365TskH/gGxbbls2xcWzherdDprYz8s8Dbcki7NNCcZ EvvDfNBdQXjoc+9RCSl1d/UPwFBcY3M/ZRjvcXSXI38gStj71sDLluVD3b3RfQUAnaF6 h2b40fkpOo5OwOde0qX3wJxxLbToP7KWNssqTJssasOqxU2GEQb34RvjPAY4DIsu8tdS zz6O5rRK0F5fhswjv1hlS2Jy86Vx+hr5scQ8kHlX33TJHepvJdQnWtEIII/jsOi+Zdse W6DQ== X-Received: by 10.180.103.199 with SMTP id fy7mr10016384wib.85.1444908870762; Thu, 15 Oct 2015 04:34:30 -0700 (PDT) Received: from brick.home (abvf228.neoplus.adsl.tpnet.pl. [83.8.203.228]) by smtp.gmail.com with ESMTPSA id p7sm15936102wjf.26.2015.10.15.04.34.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Oct 2015 04:34:30 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Thu, 15 Oct 2015 13:34:28 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: "Frank de Bot (lists)" Cc: FreeBSD Stable Subject: Re: Reloading iscsi target, iscsi initiator panics Message-ID: <20151015113428.GA3741@brick.home> Mail-Followup-To: "Frank de Bot (lists)" , FreeBSD Stable References: <561EC629.30106@searchy.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <561EC629.30106@searchy.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 11:34:33 -0000 On 1014T2316, Frank de Bot (lists) wrote: > Hello, > > I have a FreeBSD 10.2 server running as iSCSI target. Another FreeBSD > 10.2 is an initiator and has several targets used. > > When I add a target and reload its config with 'service ctld reload', > the FreeBSD initiator server panics. It's reproducable (I have a > coredump, but I think it's clear what the problem is) How easy it is to reproduce, eg. does it happen about every time? Could you paste the backtrace? From owner-freebsd-stable@freebsd.org Thu Oct 15 18:05:46 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D105A1573D for ; Thu, 15 Oct 2015 18:05:46 +0000 (UTC) (envelope-from lists@searchy.net) Received: from j006.host001.searchy.nl (j006.host001.searchy.nl [79.143.214.199]) by mx1.freebsd.org (Postfix) with ESMTP id EA8C311DE; Thu, 15 Oct 2015 18:05:45 +0000 (UTC) (envelope-from lists@searchy.net) Received: from [192.168.5.21] (5418453B.cm-5-1b.dynamic.ziggo.nl [84.24.69.59]) (Authenticated sender: ppi@j006.host001.searchy.nl) by j006.host001.searchy.nl (Postfix) with ESMTPSA id DB7221E8C07; Thu, 15 Oct 2015 18:05:41 +0000 (UTC) Message-ID: <561FEAF5.8080607@searchy.net> Date: Thu, 15 Oct 2015 20:05:41 +0200 From: "Frank de Bot (lists)" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Firefox/34.0 SeaMonkey/2.31 MIME-Version: 1.0 To: =?UTF-8?Q?Edward_Tomasz_Napiera=c5=82a?= , FreeBSD Stable Subject: Re: Reloading iscsi target, iscsi initiator panics References: <561EC629.30106@searchy.net> <20151015113428.GA3741@brick.home> In-Reply-To: <20151015113428.GA3741@brick.home> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 18:05:46 -0000 Edward Tomasz Napierała wrote: > On 1014T2316, Frank de Bot (lists) wrote: >> Hello, >> >> I have a FreeBSD 10.2 server running as iSCSI target. Another FreeBSD >> 10.2 is an initiator and has several targets used. >> >> When I add a target and reload its config with 'service ctld reload', >> the FreeBSD initiator server panics. It's reproducable (I have a >> coredump, but I think it's clear what the problem is) > > How easy it is to reproduce, eg. does it happen about every time? > Could you paste the backtrace? The first time I didn't understand what happened, the second time I could relate it directly to the reloading of ctld on the iSCSI, within moments the server paniced. I got 2 backtraces: First one: Fatal trap 12: page fault while in kernel mode cpuid = 1; softdep_deallocate_dependencies: got error 6 while accessing filesystem apic id = 01 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff808a86b5 stack pointer = 0x28:0xfffffe023b5f1200 frame pointer = 0x28:0xfffffe023b5f1260 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 = 42663 (php) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: #0 0xffffffff80984e30 at kdb_backtrace+0x60 #1 0xffffffff809489e6 at vpanic+0x126 #2 0xffffffff809488b3 at panic+0x43 #3 0xffffffff80d4aadb at trap_fatal+0x36b #4 0xffffffff80d4addd at trap_pfault+0x2ed #5 0xffffffff80d4a47a at trap+0x47a #6 0xffffffff80d307f2 at calltrap+0x8 #7 0xffffffff80b73208 at ffs_blkfree+0x168 #8 0xffffffff80b8c747 at handle_workitem_freefrag+0x127 #9 0xffffffff80b73e28 at ffs_reallocblks+0xc08 #10 0xffffffff80e74117 at VOP_REALLOCBLKS_APV+0xa7 #11 0xffffffff809da65b at cluster_write+0x3eb #12 0xffffffff80ba4dcb at ffs_write+0x45b #13 0xffffffff80e72495 at VOP_WRITE_APV+0x145 #14 0xffffffff809fc3f9 at vn_write+0x259 #15 0xffffffff809fc632 at vn_io_fault_doio+0x22 #16 0xffffffff809fa17c at vn_io_fault1+0x7c #17 0xffffffff809f864b at vn_io_fault+0x18b Uptime: 16d1h28m10s (da3:iscsi10:0:0:0): Synchronize cache failed Dumping 1154 out of 8163 MB:..2%..12%..21%..31%..41%..52%..61%..71%..81%..91% Second: Device resolver went missing before all of the data could be written to it; expect data loss. /dev: got error 6 while accessing filesystem panic: softdep_deallocate_dependencies: dangling deps cpuid = 0 KDB: stack backtrace: #0 0xffffffff80984e30 at kdb_backtrace+0x60 #1 0xffffffff809489e6 at vpanic+0x126 #2 0xffffffff809488b3 at panic+0x43 #3 0xffffffff80b866da at softdep_deallocate_dependencies+0x6a #4 0xffffffff809d1d95 at brelse+0x145 #5 0xffffffff809e9ee7 at flushbuflist+0x137 #6 0xffffffff809e9b5b at bufobj_invalbuf+0x1cb #7 0xffffffff809ec4be at vgonel+0x17e #8 0xffffffff809ec8ec at vgone+0x4c #9 0xffffffff8082b4e8 at devfs_delete+0x218 #10 0xffffffff8082b95c at devfs_populate_loop+0x1fc #11 0xffffffff8082b74a at devfs_populate+0x2a #12 0xffffffff8082fa6b at devfs_populate_vp+0x9b #13 0xffffffff808303bc at devfs_lookup+0x2c #14 0xffffffff80e71621 at VOP_LOOKUP_APV+0xa1 #15 0xffffffff809e0951 at lookup+0x5a1 #16 0xffffffff809e00b4 at namei+0x4d4 #17 0xffffffff809f9135 at vn_open_cred+0xd5 Uptime: 38m45s (da3:iscsi4:0:0:0): Synchronize cache failed (da4:iscsi5:0:0:0): Synchronize cache failed Dumping 815 out of 8163 MB:..2%..12%..22%..32%..42%..52%..61%..71%..81%..91% I've put the whole core.txt.%d files here (with my ip addresses and hostnames anonymized): - http://frankdebot.nl/tmp/core.txt.0 - http://frankdebot.nl/tmp/core.txt.1 > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@freebsd.org Thu Oct 15 20:12:19 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58E00A15AF5 for ; Thu, 15 Oct 2015 20:12:19 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CE7911457 for ; Thu, 15 Oct 2015 20:12:18 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by lffv3 with SMTP id v3so46463178lff.0 for ; Thu, 15 Oct 2015 13:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=Ekb2U2Bzl/V53m4MKK18V4Vl6c4E23Iwc4RtbStb9qo=; b=PxBRzgtAy1xM3rGZrOcVA7k3v2y8pPuK9nof/1C9o/8JznbeN9MXCdH0sMkU6mQrTI 9i9x2/KulsZ57KSAMJoGN5tfXVOmyZB/R14uGrh+X8wu1hA20grEZC1yPkGJxArNByuA t03FP3TKqUzsBLitDp8z5ln2YxkD2Lk+v1phQ8PPOHGkKVRGnpU97UItxDYF1ngzfzF9 f3R+9ciuNFHwpjvhqrumsU0MFhC6DHghiKFuR60XWmvVMYPIQ3WSPv3kdbBqO3fJdvSC SMwC8kcp8znaLVyvCn4Wrvf8gnmj8ESV1U+LCU/Z/GSlMghdX5JTFMyYKG3Ih6OOvH9T YOOw== X-Received: by 10.194.59.236 with SMTP id c12mr12748433wjr.23.1444939936518; Thu, 15 Oct 2015 13:12:16 -0700 (PDT) Received: from brick.home (abvf228.neoplus.adsl.tpnet.pl. [83.8.203.228]) by smtp.gmail.com with ESMTPSA id cc8sm18396235wjc.46.2015.10.15.13.12.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Oct 2015 13:12:15 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Thu, 15 Oct 2015 22:12:12 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: "Frank de Bot (lists)" Cc: FreeBSD Stable Subject: Re: Reloading iscsi target, iscsi initiator panics Message-ID: <20151015201212.GA4609@brick.home> Mail-Followup-To: "Frank de Bot (lists)" , FreeBSD Stable References: <561EC629.30106@searchy.net> <20151015113428.GA3741@brick.home> <561FEAF5.8080607@searchy.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <561FEAF5.8080607@searchy.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 20:12:19 -0000 On 1015T2005, Frank de Bot (lists) wrote: > Edward Tomasz Napierała wrote: > > On 1014T2316, Frank de Bot (lists) wrote: > >> Hello, > >> > >> I have a FreeBSD 10.2 server running as iSCSI target. Another FreeBSD > >> 10.2 is an initiator and has several targets used. > >> > >> When I add a target and reload its config with 'service ctld reload', > >> the FreeBSD initiator server panics. It's reproducable (I have a > >> coredump, but I think it's clear what the problem is) > > > > How easy it is to reproduce, eg. does it happen about every time? > > Could you paste the backtrace? > > The first time I didn't understand what happened, the second time I > could relate it directly to the reloading of ctld on the iSCSI, within > moments the server paniced. > > I got 2 backtraces: > > First one: > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; softdep_deallocate_dependencies: got error 6 while accessing This is the FFS on the initiator side panicing because the device it's on went away. The softupdates code can't handle that very well. I have no idea why the devices went away and then reappeared, as visible in the logs. What has the changed in the ctl.conf? Do you have any iscsi-related sysctls set on the initiator side? From owner-freebsd-stable@freebsd.org Fri Oct 16 07:13:24 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30A0AA166B2 for ; Fri, 16 Oct 2015 07:13:24 +0000 (UTC) (envelope-from lists@searchy.net) Received: from j006.host001.searchy.nl (j006.host001.searchy.nl [79.143.214.199]) by mx1.freebsd.org (Postfix) with ESMTP id ED7EA1C4B for ; Fri, 16 Oct 2015 07:13:23 +0000 (UTC) (envelope-from lists@searchy.net) Received: from [10.134.6.56] (sonic.concepts-ict.net [213.197.27.22]) (Authenticated sender: ppi@j006.host001.searchy.nl) by j006.host001.searchy.nl (Postfix) with ESMTPSA id 4EF151E8C07 for ; Fri, 16 Oct 2015 07:13:14 +0000 (UTC) Subject: Re: Reloading iscsi target, iscsi initiator panics To: FreeBSD Stable References: <561EC629.30106@searchy.net> <20151015113428.GA3741@brick.home> <561FEAF5.8080607@searchy.net> <20151015201212.GA4609@brick.home> From: Frank de Bot X-Enigmail-Draft-Status: N1110 Message-ID: <5620A389.5010901@searchy.net> Date: Fri, 16 Oct 2015 09:13:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:41.0) Gecko/20100101 Firefox/41.0 SeaMonkey/2.38 MIME-Version: 1.0 In-Reply-To: <20151015201212.GA4609@brick.home> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 07:13:24 -0000 Edward Tomasz Napierała wrote: > On 1015T2005, Frank de Bot (lists) wrote: >> Edward Tomasz Napierała wrote: >>> On 1014T2316, Frank de Bot (lists) wrote: >>>> Hello, >>>> >>>> I have a FreeBSD 10.2 server running as iSCSI target. Another FreeBSD >>>> 10.2 is an initiator and has several targets used. >>>> >>>> When I add a target and reload its config with 'service ctld reload', >>>> the FreeBSD initiator server panics. It's reproducable (I have a >>>> coredump, but I think it's clear what the problem is) >>> >>> How easy it is to reproduce, eg. does it happen about every time? >>> Could you paste the backtrace? >> >> The first time I didn't understand what happened, the second time I >> could relate it directly to the reloading of ctld on the iSCSI, within >> moments the server paniced. >> >> I got 2 backtraces: >> >> First one: >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 1; softdep_deallocate_dependencies: got error 6 while accessing > > This is the FFS on the initiator side panicing because the device it's > on went away. The softupdates code can't handle that very well. > > I have no idea why the devices went away and then reappeared, as visible > in the logs. What has the changed in the ctl.conf? Do you have any > iscsi-related sysctls set on the initiator side? > I've added a new target in the ctl.conf . On the linux server I also see a brief disconnect, but a reconnect is handled well. I haven't set any sysctl's related to iscsi My ctl.conf is (again anonymized): auth-group my-auth { chap "myiscsi" "verysecret" } portal-group pg0 { discovery-auth-group my-auth listen 10.13.37.2 } target iqn.2015-03.lan.my.nas:vmstorage-29 { auth-group my-auth portal-group pg0 lun 0 { path /tank/images/iscsi/vmstorage-29/vmstorage-29.img size 20484M blocksize 4096 option unmap on } } target iqn.2015-03.lan.my.nas:vmstorage-44 { auth-group my-auth portal-group pg0 lun 0 { path /tank/images/iscsi/vmstorage-44/vmstorage-44.img size 102404M blocksize 4096 option unmap on } } target iqn.2015-03.lan.my.nas:keyserver.my.nl { auth-group my-auth portal-group pg0 lun 0 { path /dev/zvol/tank/hosting_images/keyserver.my.nl blocksize 4096 option unmap on } } the vmstorage-44 is last added to the config > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@freebsd.org Fri Oct 16 10:26:06 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8EC019D2EFE for ; Fri, 16 Oct 2015 10:26:06 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from mx1.cksoft.de (mx1.cksoft.de [IPv6:2001:67c:24f8:1::25:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.cksoft.de", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48A582D2; Fri, 16 Oct 2015 10:26:06 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from m.cksoft.de (m.cksoft.de [212.17.240.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.cksoft.de (Postfix) with ESMTPSA id CADDD1E9EB2; Fri, 16 Oct 2015 12:26:02 +0200 (CEST) Received: from amavis.cksoft.de (unknown [IPv6:2a01:170:1110:8001::25:a1]) by m.cksoft.de (Postfix) with ESMTP id C5EDD631D0; Fri, 16 Oct 2015 12:24:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from m.cksoft.de ([IPv6:2a01:170:1110:8001::25:1]) by amavis.cksoft.de (amavis.cksoft.de [IPv6:2a01:170:1110:8001::25:a1]) (amavisd-new, port 10041) with ESMTP id usxzwL5KJQtT; Fri, 16 Oct 2015 12:24:27 +0200 (CEST) Received: from noc1.cksoft.de (noc1.cksoft.de [IPv6:2a01:170:1110:8001::53:1]) by m.cksoft.de (Postfix) with ESMTP id 27E9C62FA4; Fri, 16 Oct 2015 12:24:27 +0200 (CEST) Received: by noc1.cksoft.de (Postfix, from userid 1000) id A321713BB1; Fri, 16 Oct 2015 12:26:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by noc1.cksoft.de (Postfix) with ESMTP id 73D0C13B4B; Fri, 16 Oct 2015 12:26:00 +0200 (CEST) Date: Fri, 16 Oct 2015 12:26:00 +0200 (CEST) From: Christian Kratzer X-X-Sender: ck@noc1.cksoft.de Reply-To: Christian Kratzer To: Rick Macklem cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: smbfs crashes since approx. 10.1-RELEASE In-Reply-To: <173739656.33429352.1444704458926.JavaMail.zimbra@uoguelph.ca> Message-ID: References: <3563189.eDHDcCgW5L@ralph.baldwin.cx> <358885214.31305796.1444518367048.JavaMail.zimbra@uoguelph.ca> <2135054744.32546564.1444653156980.JavaMail.zimbra@uoguelph.ca> <173739656.33429352.1444704458926.JavaMail.zimbra@uoguelph.ca> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) X-Spammer-Kill-Ratio: 75% MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 10:26:06 -0000 Hi Rick, looks like your latest patch nailed the issue. The box has been up for 3 days: ck@noc3:~ % uptime 12:22PM up 3 days, 4:11, 1 user, load averages: 0.07, 0.10, 0.08 ck@noc3:~ % If it does not crash over the weekend this seems to be it: ck@noc3:/usr/src % svn diff sys/netsmb/smb_iod.c Index: sys/netsmb/smb_iod.c =================================================================== --- sys/netsmb/smb_iod.c (revision 289211) +++ sys/netsmb/smb_iod.c (working copy) @@ -659,6 +659,11 @@ break; tsleep(&iod->iod_flags, PWAIT, "90idle", iod->iod_sleeptimo); } + + /* We can now safely destroy the mutexes and free the iod structure. */ + smb_sl_destroy(&iod->iod_rqlock); + smb_sl_destroy(&iod->iod_evlock); + free(iod, M_SMBIOD); mtx_unlock(&Giant); kproc_exit(0); } @@ -695,9 +700,6 @@ smb_iod_destroy(struct smbiod *iod) { smb_iod_request(iod, SMBIOD_EV_SHUTDOWN | SMBIOD_EV_SYNC, NULL); - smb_sl_destroy(&iod->iod_rqlock); - smb_sl_destroy(&iod->iod_evlock); - free(iod, M_SMBIOD); return 0; } ck@noc3:/usr/src % Can you get this committed into current and later stable ? Greetings Christian On Mon, 12 Oct 2015, Rick Macklem wrote: > Christian Kratzer wrote: >> Hi Rick, >> >> On Mon, 12 Oct 2015, Rick Macklem wrote: >> >>> Christian Kratzer wrote: >>>> Hi Rick, >>>> >>>> there was also a second more recent crash in /var/crash >>>> >>>> Mon Oct 12 03:01:16 CEST 2015 >>>> >>>> FreeBSD noc3.cksoft.de 10.2-STABLE FreeBSD 10.2-STABLE #2 r288980M: >>>> Sun >>>> Oct 11 08:37:40 CEST 2015 >>>> ck@noc3.cksoft.de:/usr/obj/usr/src/sys/NOC amd64 >>>> >>>> panic: Assertion mtx_unowned(m) failed at >>>> /usr/src/sys/kern/kern_mutex.c:955 >>>> >>> Oops, I screwed up. I should have looked at this panic assertion when you >>> reported >>> it before. Ok, so if I understand the assertion correctly, it means that >>> another >>> thread has the mutex locked. If this is correct, I'll have to take another >>> look at >>> the code and figure out how to wait for these other threads to finish with >>> the mutexes. >>> >>> I do think the patch fixes the race I saw, but there must be other races in >>> the code. >>> >>> I'll take another look, but if anyone else is conversant with netsmb, feel >>> free to >>> jump in, because it is all new to me. >>> >>> Unfortunately, I won't have any way to do testing for the next month or so, >>> so any >>> patches I do come up with will be "try this untested..". >> >> thats no problem. >> >> Just keep the patches coming when you have time and tell me when to reset >> back to stable, >> current or whatever so we don't lose sync of the status. >> > Well, you can try the attached one instead of the previous ones (ie. against stable). > It just delays destroying the mutexes until the iod thread is exiting. > > I can't quite see why the previous patches wouldn't fix it, but this one leaves > smb_iod_main() unchanged, so it is a simpler patch and doesn't affect semantics > except for a slight delay in destroying the mutexes. > >> As it looks like that the race happens on unmount I could try putting a sleep >> 60 into the >> script that does the "mount && rsycn && umount" magic just before the umount. >> That would >> allow anything that it slow to go away to perhaps release the mutexes before >> the umount. >> > If it still crashes with this patch, it might be worth a try. > > Or, if this patch still crashes, you could just delete the 3 lines that the > patch moves, so the mutexes are never destroyed. This would result in a leak, > but it would tell us if destroying these mutexes is the problem. > > Thanks for your willingness to test these, rick > >> Not a real fix of course but might help to verify what's going on. >> >> Greetings >> Christian >> >> >> -- >> Christian Kratzer CK Software GmbH >> Email: ck@cksoft.de Wildberger Weg 24/2 >> Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden >> Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart >> Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer >> Web: http://www.cksoft.de/ >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > -- Christian Kratzer CK Software GmbH Email: ck@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ From owner-freebsd-stable@freebsd.org Fri Oct 16 12:11:51 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 64BC5A16517 for ; Fri, 16 Oct 2015 12:11:51 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id E13531D7A; Fri, 16 Oct 2015 12:11:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:r8cKHRQZGb1N0rIexSxlAXWPf9psv+yvbD5Q0YIujvd0So/mwa64YxeN2/xhgRfzUJnB7Loc0qyN4/ymCDVLvcjJmUtBWaIPfidNsd8RkQ0kDZzNImzAB9muURYHGt9fXkRu5XCxPBsdMs//Y1rPvi/6tmZKSV3BPAZ4bt74BpTVx5zukbvip9uCOk4U2nKUWvBbElaflU3prM4YgI9veO4a6yDihT92QdlQ3n5iPlmJnhzxtY+a9Z9n9DlM6bp6r5YTGY2zRakzTKRZATI6KCh1oZSz7ViQBTeIs1AcSGQNjhtBBUDm9hjmTJrr+n/xtcJ22zKdM9GwQb1iChq46KI+ch7ji28iPjU69GzSwphqiatQoxasojRixIHJbYWNNLx1d/WOLpshWWNdU5MJBGR6CYSmYt5KVrJZMA== X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DMAQBb6CBW/61jaINWCIN6bga9ZAENgVkXCoJDgnBKAoFtFAEBAQEBAQEBgQmCH4IHAQEBAwEBAQEgBCcgCwUJAgIBCA4KAgINGQICGwwBCSYCBAgHBAEcBIgFCA2vfJM0AQEBAQEBAQMBAQEBAQEBARoEgR6FVIR+hCoMBAIBHAEzB4JpgUUFhzqHBYdehRmFGoRASJYBg20CHwEBQoIRHYFxIjMHhFqBBgEBAQ X-IronPort-AV: E=Sophos;i="5.17,688,1437451200"; d="scan'208";a="242931190" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 16 Oct 2015 08:11:44 -0400 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id E8BB515F55D; Fri, 16 Oct 2015 08:11:43 -0400 (EDT) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id xPFiB4pWUp38; Fri, 16 Oct 2015 08:11:42 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id DD38015F565; Fri, 16 Oct 2015 08:11:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZNU5o8Rg-zcc; Fri, 16 Oct 2015 08:11:42 -0400 (EDT) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id BAD8715F55D; Fri, 16 Oct 2015 08:11:42 -0400 (EDT) Date: Fri, 16 Oct 2015 08:11:42 -0400 (EDT) From: Rick Macklem To: Christian Kratzer Cc: freebsd-stable@freebsd.org, John Baldwin Message-ID: <934327507.39134974.1444997502416.JavaMail.zimbra@uoguelph.ca> In-Reply-To: References: <358885214.31305796.1444518367048.JavaMail.zimbra@uoguelph.ca> <2135054744.32546564.1444653156980.JavaMail.zimbra@uoguelph.ca> <173739656.33429352.1444704458926.JavaMail.zimbra@uoguelph.ca> Subject: Re: smbfs crashes since approx. 10.1-RELEASE MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF34 (Win)/8.0.9_GA_6191) Thread-Topic: smbfs crashes since approx. 10.1-RELEASE Thread-Index: Lj8NllkZlbBEGIVWu6rRLqzpmELG3Q== X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 12:11:51 -0000 Christian Kratzer wrote: > Hi Rick, > > looks like your latest patch nailed the issue. The box has been up for 3 > days: > > ck@noc3:~ % uptime > 12:22PM up 3 days, 4:11, 1 user, load averages: 0.07, 0.10, 0.08 > ck@noc3:~ % > > If it does not crash over the weekend this seems to be it: > Sounds good. Although I wouldn't have thought it could happen in practice, I did spot how a race could still occur with the last patch. Since smb_iod_request() did the msleep() with PDROP, it could return any time after the wakeup(evp) and destroy the mutexes before the iod thread was done with them. Anyhow, if it fixes the problem, I guess we're happy. Btw, I think PR#172942 and 201912 may both be caused by the same problem. I've asked the people that reported these to test the patch. > > ck@noc3:/usr/src % svn diff sys/netsmb/smb_iod.c > Index: sys/netsmb/smb_iod.c > =================================================================== > --- sys/netsmb/smb_iod.c (revision 289211) > +++ sys/netsmb/smb_iod.c (working copy) > @@ -659,6 +659,11 @@ > break; > tsleep(&iod->iod_flags, PWAIT, "90idle", > iod->iod_sleeptimo); > } > + > + /* We can now safely destroy the mutexes and free the iod structure. > */ > + smb_sl_destroy(&iod->iod_rqlock); > + smb_sl_destroy(&iod->iod_evlock); > + free(iod, M_SMBIOD); > mtx_unlock(&Giant); > kproc_exit(0); > } > @@ -695,9 +700,6 @@ > smb_iod_destroy(struct smbiod *iod) > { > smb_iod_request(iod, SMBIOD_EV_SHUTDOWN | SMBIOD_EV_SYNC, NULL); > - smb_sl_destroy(&iod->iod_rqlock); > - smb_sl_destroy(&iod->iod_evlock); > - free(iod, M_SMBIOD); > return 0; > } > > ck@noc3:/usr/src % > > > Can you get this committed into current and later stable ? > I should be able to do this, although not until mid-Nov. I'd also like to hear from the folk that reported the PRs. John, maybe you could review this? Thanks for your help testing this, rick > Greetings > Christian > > > > On Mon, 12 Oct 2015, Rick Macklem wrote: > > > Christian Kratzer wrote: > >> Hi Rick, > >> > >> On Mon, 12 Oct 2015, Rick Macklem wrote: > >> > >>> Christian Kratzer wrote: > >>>> Hi Rick, > >>>> > >>>> there was also a second more recent crash in /var/crash > >>>> > >>>> Mon Oct 12 03:01:16 CEST 2015 > >>>> > >>>> FreeBSD noc3.cksoft.de 10.2-STABLE FreeBSD 10.2-STABLE #2 r288980M: > >>>> Sun > >>>> Oct 11 08:37:40 CEST 2015 > >>>> ck@noc3.cksoft.de:/usr/obj/usr/src/sys/NOC amd64 > >>>> > >>>> panic: Assertion mtx_unowned(m) failed at > >>>> /usr/src/sys/kern/kern_mutex.c:955 > >>>> > >>> Oops, I screwed up. I should have looked at this panic assertion when you > >>> reported > >>> it before. Ok, so if I understand the assertion correctly, it means that > >>> another > >>> thread has the mutex locked. If this is correct, I'll have to take > >>> another > >>> look at > >>> the code and figure out how to wait for these other threads to finish > >>> with > >>> the mutexes. > >>> > >>> I do think the patch fixes the race I saw, but there must be other races > >>> in > >>> the code. > >>> > >>> I'll take another look, but if anyone else is conversant with netsmb, > >>> feel > >>> free to > >>> jump in, because it is all new to me. > >>> > >>> Unfortunately, I won't have any way to do testing for the next month or > >>> so, > >>> so any > >>> patches I do come up with will be "try this untested..". > >> > >> thats no problem. > >> > >> Just keep the patches coming when you have time and tell me when to reset > >> back to stable, > >> current or whatever so we don't lose sync of the status. > >> > > Well, you can try the attached one instead of the previous ones (ie. > > against stable). > > It just delays destroying the mutexes until the iod thread is exiting. > > > > I can't quite see why the previous patches wouldn't fix it, but this one > > leaves > > smb_iod_main() unchanged, so it is a simpler patch and doesn't affect > > semantics > > except for a slight delay in destroying the mutexes. > > > >> As it looks like that the race happens on unmount I could try putting a > >> sleep > >> 60 into the > >> script that does the "mount && rsycn && umount" magic just before the > >> umount. > >> That would > >> allow anything that it slow to go away to perhaps release the mutexes > >> before > >> the umount. > >> > > If it still crashes with this patch, it might be worth a try. > > > > Or, if this patch still crashes, you could just delete the 3 lines that the > > patch moves, so the mutexes are never destroyed. This would result in a > > leak, > > but it would tell us if destroying these mutexes is the problem. > > > > Thanks for your willingness to test these, rick > > > >> Not a real fix of course but might help to verify what's going on. > >> > >> Greetings > >> Christian > >> > >> > >> -- > >> Christian Kratzer CK Software GmbH > >> Email: ck@cksoft.de Wildberger Weg 24/2 > >> Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden > >> Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart > >> Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer > >> Web: http://www.cksoft.de/ > >> _______________________________________________ > >> freebsd-stable@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > >> > > > > -- > Christian Kratzer CK Software GmbH > Email: ck@cksoft.de Wildberger Weg 24/2 > Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden > Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart > Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer > Web: http://www.cksoft.de/ > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@freebsd.org Sat Oct 17 15:30:17 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3395DA17FF0 for ; Sat, 17 Oct 2015 15:30:17 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 50AF09ED for ; Sat, 17 Oct 2015 15:30:15 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id t9HFTplc049340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 17 Oct 2015 17:29:56 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id t9HFTmRH030482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Oct 2015 17:29:48 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id t9HFTmfp063006; Sat, 17 Oct 2015 17:29:48 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id t9HFTmcE063005; Sat, 17 Oct 2015 17:29:48 +0200 (CEST) (envelope-from ticso) Date: Sat, 17 Oct 2015 17:29:48 +0200 From: Bernd Walter To: freebsd-stable@freebsd.org Cc: Bernd Walter Subject: mfi0: I/O error on MegaRAID SAS 9361-4i Message-ID: <20151017152947.GD56791@cicely7.cicely.de> Reply-To: ticso@cicely.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 17 Oct 2015 15:30:17 -0000 System ist running ZFS data pool on 12 disk JBOD using MegaRAID SAS 9361-4i controller. After some time it starts printing the following errors: Oct 16 22:26:46 hostname kernel: mfi0: I/O error, cmd=0xfffffe0001079c90, status=0x3c, scsi_status=0 Oct 16 22:26:46 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:46 hostname kernel: mfisyspd6: hard error cmd=write 410262844-410263362 Oct 16 22:26:49 hostname kernel: mfi0: I/O error, cmd=0xfffffe0001077188, status=0x3c, scsi_status=0 Oct 16 22:26:49 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:49 hostname kernel: mfisyspd5: hard error cmd=write 410267090-410267593 Oct 16 22:26:49 hostname kernel: mfi0: I/O error, cmd=0xfffffe00010780f0, status=0x3c, scsi_status=0 Oct 16 22:26:49 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:49 hostname kernel: mfisyspd6: hard error cmd=write 410267090-410267593 Oct 16 22:26:49 hostname kernel: mfi0: I/O error, cmd=0xfffffe00010778f8, status=0x3c, scsi_status=0 Oct 16 22:26:49 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:49 hostname kernel: mfisyspd7: hard error cmd=write 410267090-410267593 Oct 16 22:26:49 hostname kernel: Oct 16 22:26:49 hostname kernel: mfi0: I/O error, cmd=0xfffffe000107a048, status=0x3c, scsi_status=0 Oct 16 22:26:49 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:49 hostname kernel: mfisyspd7: hard error cmd=write 410267090-410267593 Oct 16 22:26:49 hostname kernel: mfi0: I/O error, cmd=0xfffffe0001078db0, status=0x3c, scsi_status=0 Oct 16 22:26:49 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:49 hostname kernel: mfisyspd6: hard error cmd=write 410267090-410267593 Oct 16 22:26:49 hostname kernel: mfi0: I/O error, cmd=0xfffffe00010784a8, status=0x3c, scsi_status=0 Oct 16 22:26:49 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:49 hostname kernel: mfisyspd5: hard error cmd=write 410267090-410267593 Oct 16 22:26:49 hostname kernel: mfi0: Oct 16 22:26:49 hostname kernel: I/O error, cmd=0xfffffe0001078750, status=0x3c, scsi_status=0 Oct 16 22:26:49 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:49 hostname kernel: mfisyspd10: hard error cmd=write 362223336-362223832 Oct 16 22:26:49 hostname kernel: mfi0: I/O error, cmd=0xfffffe0001076660, status=0x3c, scsi_status=0 Oct 16 22:26:49 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:49 hostname kernel: mfisyspd11: hard error cmd=write 362223336-362223831 Oct 16 22:26:49 hostname kernel: mfi0: I/O error, cmd=0xfffffe00010774b8, status=0x3c, scsi_status=0 Oct 16 22:26:49 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:49 hostname kernel: mfisyspd10: hard error cmd=write 362223336-362223832 Oct 16 22:26:49 hostname kernel: mfi0: I/O error, cmd=0xfffffe00010788e8, status=0x3c, scsi_status=0 Oct 16 22:26:49 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:49 hostname kernel: mfisyspd11: hard error cmd=write 362223336-362223831 Oct 16 22:26:59 hostname kernel: mfi0: I/O error, cmd=0xfffffe0001076f68, status=0x3c, scsi_status=0 Oct 16 22:26:59 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:59 hostname kernel: mfisyspd3: hard error cmd=write 295491976-295492474 Oct 16 22:26:59 hostname kernel: mfi0: I/O error, cmd=0xfffffe00010797c8, status=0x3c, scsi_status=0 Oct 16 22:26:59 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:59 hostname kernel: mfisyspd0: hard error cmd=write 295491977-295492475 [...] continues endless [...] Interruptload in MFI is high and gstat shows disk load, but there is no ZFS progress anymore. I can only log into the machine because / is running on UFS. After switching to mrsas things are different. I got the follogin messages: ses0: da0,pass1: Element descriptor: 'Slot00' ses0: da0,pass1: SAS Device Slot Element: 1 Phys at Slot 0 ses0: phy 0: SATA device ses0: phy 0: parent 5003048001abe0bf addr 5003048001abe080 ses0: da7,pass8: Element descriptor: 'Slot01' ses0: da7,pass8: SAS Device Slot Element: 1 Phys at Slot 1 ses0: phy 0: SATA device ses0: phy 0: parent 5003048001abe0bf addr 5003048001abe081 ses0: da1,pass2: Element descriptor: 'Slot02' ses0: da1,pass2: SAS Device Slot Element: 1 Phys at Slot 2 ses0: phy 0: SATA device ses0: phy 0: parent 5003048001abe0bf addr 5003048001abe082 ses0: da6,pass7: Element descriptor: 'Slot03' ses0: da6,pass7: SAS Device Slot Element: 1 Phys at Slot 3 ses0: phy 0: SATA device ses0: phy 0: parent 5003048001abe0bf addr 5003048001abe083 ses0: da3,pass4: Element descriptor: 'Slot04' ses0: da3,pass4: SAS Device Slot Element: 1 Phys at Slot 4 ses0: phy 0: SATA device ses0: phy 0: parent 5003048001abe0bf addr 5003048001abe084 ses0: da9,pass10: Element descriptor: 'Slot05' ses0: da9,pass10: SAS Device Slot Element: 1 Phys at Slot 5 ses0: phy 0: SATA device ses0: phy 0: parent 5003048001abe0bf addr 5003048001abe085 ses0: da2,pass3: Element descriptor: 'Slot06' ses0: da2,pass3: SAS Device Slot Element: 1 Phys at Slot 6 ses0: phy 0: SATA device ses0: phy 0: parent 5003048001abe0bf addr 5003048001abe086 ses0: da8,pass9: Element descriptor: 'Slot07' ses0: da8,pass9: SAS Device Slot Element: 1 Phys at Slot 7 ses0: phy 0: SATA device ses0: phy 0: parent 5003048001abe0bf addr 5003048001abe087 ses0: da5,pass6: Element descriptor: 'Slot08' ses0: da5,pass6: SAS Device Slot Element: 1 Phys at Slot 8 ses0: phy 0: SATA device ses0: phy 0: parent 5003048001abe0bf addr 5003048001abe088 ses0: da10,pass11: Element descriptor: 'Slot09' ses0: da10,pass11: SAS Device Slot Element: 1 Phys at Slot 9 ses0: phy 0: SATA device ses0: phy 0: parent 5003048001abe0bf addr 5003048001abe089 ses0: da4,pass5: Element descriptor: 'Slot10' ses0: da4,pass5: SAS Device Slot Element: 1 Phys at Slot 10 ses0: phy 0: SATA device ses0: phy 0: parent 5003048001abe0bf addr 5003048001abe08a ses0: da11,pass12: Element descriptor: 'Slot11' ses0: da11,pass12: SAS Device Slot Element: 1 Phys at Slot 11 ses0: phy 0: SATA device ses0: phy 0: parent 5003048001abe0bf addr 5003048001abe08b I have no idea what they mean and if they point to a real problem, but everything continues just normaly. I don't even know if those are the events that got the MFI driver into permanent troubles. ZFS is still happy with all the drives after those log messages. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.