From owner-freebsd-stable@FreeBSD.ORG Sun Sep 8 07:09:40 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 671A2A28 for ; Sun, 8 Sep 2013 07:09:40 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CB5662D9C for ; Sun, 8 Sep 2013 07:09:39 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id u14so3971321lbd.26 for ; Sun, 08 Sep 2013 00:09:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=d4z8b9XA2Emr3l9fOzXqR5yIZAiBTUJuNHIITejWfa4=; b=Rcem8fn2oeZQ9p26RyVUDjE0YcnMDaW/bTyYARpp2WOqZXsM/y9w2ipE0ziYeZ7tNU E8Rix9d3AOkHAYajkbYQs4qVXreGVr+nmUjQ7EvxqDgH8e0ws8Cr11XyVi/Kh4O7JD/h JWbQOZTffhZz1CPAcnxHmw1z1BFCCMJ+V/MOjdS3QNvG7IoHZNnlH0TjojtOMdFws18D 2U8HoX7pji7U2KHYjHl5jE/t/43zTu4Ev/udaRE3z2RBzRZDmKCKA30oAsH/6F7hJPRE tfFC+yn5/2hqbiNrDWUYRMWpDoK+tAeEwpR/5m/gGRiR8tVNeXsUX7FNw5bQYwGejP8f QKZg== X-Gm-Message-State: ALoCoQlJAEF08KlWxA3GaesgDlPaN+DWuN9KCqSIgbO+70CV4pOP5T7MiX1krihd/L5aMyImnvvO MIME-Version: 1.0 X-Received: by 10.112.168.3 with SMTP id zs3mr10897234lbb.2.1378624172147; Sun, 08 Sep 2013 00:09:32 -0700 (PDT) Sender: sobomax@sippysoft.com Received: by 10.114.230.66 with HTTP; Sun, 8 Sep 2013 00:09:32 -0700 (PDT) Date: Sun, 8 Sep 2013 00:09:32 -0700 X-Google-Sender-Auth: 6OZPOMIpnTA_r_aJ8oOJ0wuzn7w Message-ID: Subject: Troubles with dependencies (file -L is broken?) From: Maxim Sobolev To: stable@freebsd.org, ports@freebsd.org, portmgr@freebsd.org Content-Type: multipart/mixed; boundary=001a11c33fe60f554c04e5d9f408 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Sep 2013 07:09:40 -0000 --001a11c33fe60f554c04e5d9f408 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I am trying to portupgrade my subversion and it keeps trying to install databases/db42 over already installed version (same version), missing the shared library dependency. Adding some debug into bsd.port.mk, I see: =3D=3D=3D> subversion-1.8.3 depends on package: libtool>=3D2.4 - found set -x; set -e ; for i in libdb-4.2.so:/usr/ports/databases/db42; do lib=3D${i%%:*} ; dir=3D${i#*:} ; target=3D"install"; depends_args=3D"";= echo -n "=3D=3D=3D> subversion-1.8.3 depends on shared library: ${lib}" ; fou= nd=3D0 ; dirs=3D"/lib /usr/lib /usr/local/lib `/bin/cat /usr/local/libdata/ldconfig/* 2>/dev/null || : `" ; for libdir in $dirs; do test -f ${libdir}/${lib} || continue; if [ -x /usr/bin/file ]; then [ `file -b -L --mime-type ${libdir}/${lib}` =3D "application/x-sharedlib" ] |= | continue ; fi ; found=3D1 ; echo " - found"; done ; if [ ${found} -eq = 0 ]; then echo " - not found"; echo "=3D=3D=3D> Verifying for $lib in $d= ir"; if [ ! -d "$dir" ] ; then echo " =3D> No directory for $lib. Skipping.."; else if [ -n "" -o -n "" ]; then subpkgfile=3D`(cd $dir; ma= ke $depends_args -V PKGFILE)`; subpkgname=3D${subpkgfile%-*} ; subpkgname=3D${subpkgname##*/} ; if [ -r "${subpkgfile}" -a "$target" =3D "install" ]; then echo "=3D=3D=3D> Installing existing package ${subpkgfile}"; if [ -n "" -a ${subpkgname} =3D "pkg" ]; then [ -d /usr/ports/devel/subversion/work ] || /bin/mkdir -p /usr/ports/devel/subversion/work ; /usr/bin/tar xf ${subpkgfile} -C /usr/ports/devel/subversion/work -s ",/.*/,,g" "*/pkg-static" ; /usr/ports/devel/subversion/work/pkg-static add ${subpkgfile}; /bin/rm -f /usr/ports/devel/subversion/work/pkg-static; else /usr/sbin/pkg_add ${subpkgfile}; fi; elif [ -n "" -a "${target}" =3D "install" ]; then ech= o "=3D=3D=3D> subversion-1.8.3 depends on package: ${subpkgfile} - not foun= d"; echo "=3D=3D=3D> USE_PACKAGE_DEPENDS_ONLY set - will not build from sourc= e"; exit 1; else (cd $dir; make -DINSTALLS_DEPENDS $target $depends_args) ; fi; else (cd $dir; make -DINSTALLS_DEPENDS $target $depends_args) ; fi; echo "=3D=3D=3D> Returning to build of subversion-1.8.3"; fi ; fi ; do= ne + set -e + lib=3Dlibdb-4.2.so + dir=3D/usr/ports/databases/db42 + target=3Dinstall + depends_args=3D'' + echo -n '=3D=3D=3D> subversion-1.8.3 depends on shared library: libdb-4= .2.so' =3D=3D=3D> subversion-1.8.3 depends on shared library: libdb-4.2.so+ foun= d=3D0 + /bin/cat /usr/local/libdata/ldconfig/compat7x /usr/local/libdata/ldconfig/mysql /usr/local/libdata/ldconfig/portupgrade /usr/local/libdata/ldconfig/pth + dirs=3D'/lib /usr/lib /usr/local/lib /usr/local/lib/compat /usr/local/lib/mysql /usr/local/lib/compat/pkg /usr/local/lib/pth' + test -f /lib/libdb-4.2.so + continue + test -f /usr/lib/libdb-4.2.so + continue + test -f /usr/local/lib/libdb-4.2.so + [ -x /usr/bin/file ] + file -b -L --mime-type /usr/local/lib/libdb-4.2.so + [ inode/symlink =3D application/x-sharedlib ] + continue + test -f /usr/local/lib/compat/libdb-4.2.so + continue + test -f /usr/local/lib/mysql/libdb-4.2.so + continue + test -f /usr/local/lib/compat/pkg/libdb-4.2.so + continue + test -f /usr/local/lib/pth/libdb-4.2.so + continue + [ 0 -eq 0 ] + echo ' - not found' - not found + echo '=3D=3D=3D> Verifying for libdb-4.2.so in /usr/ports/databases/db= 42' =3D=3D=3D> Verifying for libdb-4.2.so in /usr/ports/databases/db42 So, file(1) call is the culprit here. Trying to reproduce in the console: [sobomax@pioneer ~]$ file -b -L --mime-type /usr/local/lib/libdb-4.2.so inode/symlink However: [sobomax@pioneer ~]$ hexdump -C /usr/local/lib/libdb-4.2.so | head -n 20 00000000 7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00 |.ELF............| 00000010 03 00 3e 00 01 00 00 00 d0 40 02 00 00 00 00 00 |..>.....=D0=BF@......| 00000020 40 00 00 00 00 00 00 00 b8 a6 0e 00 00 00 00 00 |@.......=E2=95=A6=D1=96......| 00000030 00 00 00 00 40 00 38 00 05 00 40 00 1d 00 1a 00 |....@.8...@ .....| 00000040 01 00 00 00 05 00 00 00 00 00 00 00 00 00 00 00 |................| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000060 dc 45 0e 00 00 00 00 00 dc 45 0e 00 00 00 00 00 |=D1=8DE......=D1=8DE......| 00000070 00 00 20 00 00 00 00 00 01 00 00 00 06 00 00 00 |.. .............| 00000080 00 50 0e 00 00 00 00 00 00 50 2e 00 00 00 00 00 |.P.......P......| 00000090 00 50 2e 00 00 00 00 00 fc 36 00 00 00 00 00 00 |.P......=D0=AD6......| 000000a0 d8 3a 00 00 00 00 00 00 00 00 20 00 00 00 00 00 |=D1=8C:.......= . .....| 000000b0 02 00 00 00 06 00 00 00 e8 54 0e 00 00 00 00 00 |........=D0=A5T......| 000000c0 e8 54 2e 00 00 00 00 00 e8 54 2e 00 00 00 00 00 |=D0=A5T......=D0=A5T......| 000000d0 a0 01 00 00 00 00 00 00 a0 01 00 00 00 00 00 00 |=E2=95=90.......=E2=95=90.......| 000000e0 08 00 00 00 00 00 00 00 50 e5 74 64 04 00 00 00 |........P=D0=95td....| 000000f0 5c 39 0d 00 00 00 00 00 5c 39 0d 00 00 00 00 00 |\9......\9......| 00000100 5c 39 0d 00 00 00 00 00 b4 34 00 00 00 00 00 00 |\9......=D0=844......| 00000110 b4 34 00 00 00 00 00 00 04 00 00 00 00 00 00 00 |=D0=844..............| The culprit is that /usr/local/lib/libdb-4.2.so is a symlink to another symlink to another symlink etc, so that my guess is that file(1) stops at the first one. The issue can be resolved by using realpath(1), attached patch fixes it for me. [sobomax@pioneer ~]$ realpath /usr/local/lib/libdb-4.2.so /usr/local/lib/db42/libdb-4.2.so.2 [sobomax@pioneer ~]$ file -b -L --mime-type /usr/local/lib/db42/libdb-4.2.so.2 application/x-sharedlib [sobomax@pioneer ~]$ ls -l /usr/local/lib/libdb-4.2.so lrwxr-xr-x 1 root wheel 14 7 =D1=81=D0=B5=D0=BD 21:43 /usr/local/lib/li= bdb-4.2.so -> libdb-4.2.so.2 I am not sure what's the process to get bsd.port.mk adjusted these days. Should I open a PR and assign it to portmgr? -Maxim --001a11c33fe60f554c04e5d9f408 Content-Type: application/octet-stream; name="bsd.port.mk.diff" Content-Disposition: attachment; filename="bsd.port.mk.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hlbx6h7j0 LS0tIGJzZC5wb3J0Lm1rCTIwMTMvMDkvMDggMDc6MDQ6MjIJMS4xCisrKyBic2QucG9ydC5tawky MDEzLzA5LzA4IDA3OjA2OjAyCkBAIC01MDQ5LDcgKzUwNDksOCBAQAogCQlmb3IgbGliZGlyIGlu ICQkZGlyczsgZG8gXAogCQkJdGVzdCAtZiAkJHtsaWJkaXJ9LyQke2xpYn0gfHwgY29udGludWU7 IFwKIAkJCWlmIFsgLXggL3Vzci9iaW4vZmlsZSBdOyB0aGVuIFwKLQkJCQlbIGBmaWxlIC1iIC1M IC0tbWltZS10eXBlICQke2xpYmRpcn0vJCR7bGlifWAgPSAiYXBwbGljYXRpb24veC1zaGFyZWRs aWIiIF0gfHwgY29udGludWUgOyBcCisJCQkJX0xJQl9GSUxFPWByZWFscGF0aCAkJHtsaWJkaXJ9 LyQke2xpYn1gOyBcCisJCQkJWyBgZmlsZSAtYiAtTCAtLW1pbWUtdHlwZSAkJHtfTElCX0ZJTEV9 YCA9ICJhcHBsaWNhdGlvbi94LXNoYXJlZGxpYiIgXSB8fCBjb250aW51ZSA7IFwKIAkJCWZpIDsg XAogCQkJZm91bmQ9MSA7IFwKIAkJCSR7RUNIT19NU0d9ICIgLSBmb3VuZCI7IFwK --001a11c33fe60f554c04e5d9f408-- From owner-freebsd-stable@FreeBSD.ORG Sun Sep 8 07:28:40 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 55313371 for ; Sun, 8 Sep 2013 07:28:40 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BBBC62ED8 for ; Sun, 8 Sep 2013 07:28:39 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id x18so3999318lbi.24 for ; Sun, 08 Sep 2013 00:28:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ew10/GkmT+FuMpBV6+qeOlSkpfEHUMgrOHnyJIoc21o=; b=TWp05rD3NEEoCu+t/BqTcSafWnrYzBQesDkCuunCyEQE/oJSyHX88FkQ2NWCssqr1e 5soei65mFmNROq3XlIYYH1ddbJYBtogWyeVVwqtvOrsTZyvqTL9oYSLo0zR48SqrjKA2 BxvuhkwtBiWq7E9e68fGc0E3vhWltHBslo4scb4+nEN3IEqaP6RkQ2QHdk2CgZpPGjgA ne6BiV+cTGfCkGjKQ0L6XZydnbGCy/S6kBb28DdGpehCXhqlxoSXsxNRWERoKmm8ye1s 2gddX0yWCC4gCTfGbcEEsxOLDcmR+iZWzFz4LKSBliYwpGvH9uRrPqWfRr+BlPx9eG8L dFdQ== X-Gm-Message-State: ALoCoQmZeMgFnYY1GTrYckGlUnaq6BFEhq8cSmeJAQvOfgqctC4/ZXK5ditg29x8RgVAZ9CY6HZ1 MIME-Version: 1.0 X-Received: by 10.152.8.115 with SMTP id q19mr10733542laa.16.1378625312397; Sun, 08 Sep 2013 00:28:32 -0700 (PDT) Received: by 10.114.230.66 with HTTP; Sun, 8 Sep 2013 00:28:32 -0700 (PDT) In-Reply-To: References: Date: Sun, 8 Sep 2013 00:28:32 -0700 Message-ID: Subject: Re: Troubles with dependencies (file -L is broken?) From: Maxim Sobolev To: stable@freebsd.org, ports@freebsd.org, portmgr@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Sep 2013 07:28:40 -0000 P.S. This is fresh 9.2-RC3 with /usr on ZFS. -Maxim On Sun, Sep 8, 2013 at 12:09 AM, Maxim Sobolev wrote: > Hi, > > I am trying to portupgrade my subversion and it keeps trying to install > databases/db42 over already installed version (same version), missing the > shared library dependency. > > Adding some debug into bsd.port.mk, I see: > > =3D=3D=3D> subversion-1.8.3 depends on package: libtool>=3D2.4 - found > set -x; set -e ; for i in libdb-4.2.so:/usr/ports/databases/db42; do > lib=3D${i%%:*} ; dir=3D${i#*:} ; target=3D"install"; depends_args=3D"= "; echo > -n "=3D=3D=3D> subversion-1.8.3 depends on shared library: ${lib}" ; f= ound=3D0 > ; dirs=3D"/lib /usr/lib /usr/local/lib `/bin/cat > /usr/local/libdata/ldconfig/* 2>/dev/null || : `" ; for libdir in $dirs; > do test -f ${libdir}/${lib} || continue; if [ -x /usr/bin/file ]; then = [ > `file -b -L --mime-type ${libdir}/${lib}` =3D "application/x-sharedlib" ]= || > continue ; fi ; found=3D1 ; echo " - found"; done ; if [ ${found} -e= q 0 > ]; then echo " - not found"; echo "=3D=3D=3D> Verifying for $lib in = $dir"; > if [ ! -d "$dir" ] ; then echo " =3D> No directory for $lib. > Skipping.."; else if [ -n "" -o -n "" ]; then subpkgfile=3D`(cd $dir; = make > $depends_args -V PKGFILE)`; subpkgname=3D${subpkgfile%-*} ; > subpkgname=3D${subpkgname##*/} ; if [ -r "${subpkgfile}" -a "$target" = =3D > "install" ]; then echo "=3D=3D=3D> Installing existing package > ${subpkgfile}"; if [ -n "" -a ${subpkgname} =3D "pkg" ]; then [ -d > /usr/ports/devel/subversion/work ] || /bin/mkdir -p > /usr/ports/devel/subversion/work ; /usr/bin/tar xf ${subpkgfile} -C > /usr/ports/devel/subversion/work -s ",/.*/,,g" "*/pkg-static" ; > /usr/ports/devel/subversion/work/pkg-static add ${subpkgfile}; /bin/rm -= f > /usr/ports/devel/subversion/work/pkg-static; else /usr/sbin/pkg_add > ${subpkgfile}; fi; elif [ -n "" -a "${target}" =3D "install" ]; then e= cho > "=3D=3D=3D> subversion-1.8.3 depends on package: ${subpkgfile} - not fo= und"; > echo "=3D=3D=3D> USE_PACKAGE_DEPENDS_ONLY set - will not build from sou= rce"; > exit 1; else (cd $dir; make -DINSTALLS_DEPENDS $target $depends_args) ; > fi; else (cd $dir; make -DINSTALLS_DEPENDS $target $depends_args) ; fi= ; > echo "=3D=3D=3D> Returning to build of subversion-1.8.3"; fi ; fi ; = done > + set -e > + lib=3Dlibdb-4.2.so > + dir=3D/usr/ports/databases/db42 > + target=3Dinstall > + depends_args=3D'' > + echo -n '=3D=3D=3D> subversion-1.8.3 depends on shared library: libdb= -4.2.so > ' > =3D=3D=3D> subversion-1.8.3 depends on shared library: libdb-4.2.so+ fo= und=3D0 > + /bin/cat /usr/local/libdata/ldconfig/compat7x > /usr/local/libdata/ldconfig/mysql /usr/local/libdata/ldconfig/portupgrade > /usr/local/libdata/ldconfig/pth > + dirs=3D'/lib /usr/lib /usr/local/lib /usr/local/lib/compat > /usr/local/lib/mysql > /usr/local/lib/compat/pkg > /usr/local/lib/pth' > + test -f /lib/libdb-4.2.so > + continue > + test -f /usr/lib/libdb-4.2.so > + continue > + test -f /usr/local/lib/libdb-4.2.so > + [ -x /usr/bin/file ] > + file -b -L --mime-type /usr/local/lib/libdb-4.2.so > + [ inode/symlink =3D application/x-sharedlib ] > + continue > + test -f /usr/local/lib/compat/libdb-4.2.so > + continue > + test -f /usr/local/lib/mysql/libdb-4.2.so > + continue > + test -f /usr/local/lib/compat/pkg/libdb-4.2.so > + continue > + test -f /usr/local/lib/pth/libdb-4.2.so > + continue > + [ 0 -eq 0 ] > + echo ' - not found' > - not found > + echo '=3D=3D=3D> Verifying for libdb-4.2.so in /usr/ports/databases/= db42' > =3D=3D=3D> Verifying for libdb-4.2.so in /usr/ports/databases/db42 > > So, file(1) call is the culprit here. Trying to reproduce in the console: > > [sobomax@pioneer ~]$ file -b -L --mime-type /usr/local/lib/libdb-4.2.so > inode/symlink > > However: > > [sobomax@pioneer ~]$ hexdump -C /usr/local/lib/libdb-4.2.so | head -n 20 > 00000000 7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00 > |.ELF............| > 00000010 03 00 3e 00 01 00 00 00 d0 40 02 00 00 00 00 00 > |..>.....=D0=BF@......| > 00000020 40 00 00 00 00 00 00 00 b8 a6 0e 00 00 00 00 00 > |@.......=E2=95=A6=D1=96......| > 00000030 00 00 00 00 40 00 38 00 05 00 40 00 1d 00 1a 00 |....@.8...@ > .....| > 00000040 01 00 00 00 05 00 00 00 00 00 00 00 00 00 00 00 > |................| > 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > 00000060 dc 45 0e 00 00 00 00 00 dc 45 0e 00 00 00 00 00 > |=D1=8DE......=D1=8DE......| > 00000070 00 00 20 00 00 00 00 00 01 00 00 00 06 00 00 00 |.. > .............| > 00000080 00 50 0e 00 00 00 00 00 00 50 2e 00 00 00 00 00 > |.P.......P......| > 00000090 00 50 2e 00 00 00 00 00 fc 36 00 00 00 00 00 00 > |.P......=D0=AD6......| > 000000a0 d8 3a 00 00 00 00 00 00 00 00 20 00 00 00 00 00 |=D1=8C:.....= ... > .....| > 000000b0 02 00 00 00 06 00 00 00 e8 54 0e 00 00 00 00 00 > |........=D0=A5T......| > 000000c0 e8 54 2e 00 00 00 00 00 e8 54 2e 00 00 00 00 00 > |=D0=A5T......=D0=A5T......| > 000000d0 a0 01 00 00 00 00 00 00 a0 01 00 00 00 00 00 00 > |=E2=95=90.......=E2=95=90.......| > 000000e0 08 00 00 00 00 00 00 00 50 e5 74 64 04 00 00 00 > |........P=D0=95td....| > 000000f0 5c 39 0d 00 00 00 00 00 5c 39 0d 00 00 00 00 00 > |\9......\9......| > 00000100 5c 39 0d 00 00 00 00 00 b4 34 00 00 00 00 00 00 > |\9......=D0=844......| > 00000110 b4 34 00 00 00 00 00 00 04 00 00 00 00 00 00 00 > |=D0=844..............| > > The culprit is that /usr/local/lib/libdb-4.2.so is a symlink to another > symlink to another symlink etc, so that my guess is that file(1) stops at > the first one. The issue can be resolved by using realpath(1), attached > patch fixes it for me. > > [sobomax@pioneer ~]$ realpath /usr/local/lib/libdb-4.2.so > /usr/local/lib/db42/libdb-4.2.so.2 > [sobomax@pioneer ~]$ file -b -L --mime-type > /usr/local/lib/db42/libdb-4.2.so.2 > application/x-sharedlib > [sobomax@pioneer ~]$ ls -l /usr/local/lib/libdb-4.2.so > lrwxr-xr-x 1 root wheel 14 7 =D1=81=D0=B5=D0=BD 21:43 /usr/local/lib/= libdb-4.2.so -> > libdb-4.2.so.2 > > I am not sure what's the process to get bsd.port.mk adjusted these days. > Should I open a PR and assign it to portmgr? > > -Maxim > > --=20 Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel (Canada): +1-778-783-0474 Tel (Toll-Free): +1-855-747-7779 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: sales@sippysoft.com Skype: SippySoft From owner-freebsd-stable@FreeBSD.ORG Sun Sep 8 10:01:27 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 746C567D for ; Sun, 8 Sep 2013 10:01:27 +0000 (UTC) (envelope-from rmcintosh@nitemare.net) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3887E254D for ; Sun, 8 Sep 2013 10:01:26 +0000 (UTC) Received: by mail-qe0-f54.google.com with SMTP id cy11so2630451qeb.13 for ; Sun, 08 Sep 2013 03:01:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=XuTKnWpxT3+6ap3xEu6pR5PCcfUDX38jym88nCaHrAg=; b=JrYUpVAnr7NMNyewanRSY/5r/UWkq6FHQF9WHDLsE+YJdsjjp4WvGRGW24T0kbsiIa heqVIMW1PruHZYqzVWtZ346RVcVT2QKk/E6TZrteK6xLd6qgGpDTDGVX+ZAJGZsaq1Im KN+rM6WZq5Bu11lRwO33G3kBXzkdj0oaAbwNT/PpDTfb8mrVWOdNy24t6pFNnPUTVdp4 UnkgaEIFIGCv4HvnHK681rZvZTLOI3CmUV0Ajb195jc4nM2bKqsymJLsoyFjgc9+JyuP qF/Ncgw4OTprp3Ss/jaC0DgT2HxKkmvlUXOKgFLp0iyNdd9Xb3z/t6Rlxd/x9VYym466 0fww== X-Gm-Message-State: ALoCoQlhy+cd7Uy6flcOHMrK8iRTfN9wu2KJbiyqeQHlTW/ZRZMlEf4ZAhcWyjO4KCJU4VbJbzvv MIME-Version: 1.0 X-Received: by 10.49.53.10 with SMTP id x10mr14022277qeo.46.1378634480242; Sun, 08 Sep 2013 03:01:20 -0700 (PDT) Received: by 10.49.60.10 with HTTP; Sun, 8 Sep 2013 03:01:20 -0700 (PDT) X-Originating-IP: [76.15.56.143] Date: Sun, 8 Sep 2013 06:01:20 -0400 Message-ID: Subject: Looking for driver help From: Ryan McIntosh To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Sep 2013 10:01:27 -0000 I sent an email out to freebsd-net without a response, soo this is my last attempt at getting any assistance here. I have a QLE3142-CU-CK (rebranded NetXen NX3-20GCU w/ NX3031 chipset) with no driver support in *BSD from anything I saw. I came across solaris's ntxn driver which seems to work appropriately but I have no use for solaris as a host o/s. Naturally I'll attempt at trying to get the driver to work myself, however I'm far from knowledgeable on the method to port a driver, but I won't say no to making it work after the response Qlogic gave me. Any insight/assistance/pointers would be helpful, including which mailing list might be best for this. Ryan From owner-freebsd-stable@FreeBSD.ORG Sun Sep 8 10:13:56 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C4BE5B8F for ; Sun, 8 Sep 2013 10:13:56 +0000 (UTC) (envelope-from info@serv3.energyefficencydr.biz) Received: from serv3.energyefficencydr.biz (serv3.energyefficencydr.biz [199.15.118.66]) by mx1.freebsd.org (Postfix) with ESMTP id B037A25F7 for ; Sun, 8 Sep 2013 10:13:56 +0000 (UTC) Received: from 150-135-19-23.10a.protectedgroup.com (31-137-234-173.fc.protectedgroup.com [173.234.137.31]) by serv3.energyefficencydr.biz (Postfix) with ESMTPA id 81D261D6D78 for ; Sun, 8 Sep 2013 06:06:37 -0400 (EDT) From: "Dennis Roberts" Subject: Solar Windows Webinar - US AIR FORCED APPROVED - See thru radiant barrier To: "stable" MIME-Version: 1.0 Organization: http://www.inflectorglobal.com Date: Sun, 8 Sep 2013 05:06:33 -0500 Message-Id: <20130908101356.C4BE5B8F@hub.freebsd.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Sep 2013 10:13:56 -0000 =EF=BB=BFA Billion Dollar Company just joined us from the middle east = - droberts43@sbcglobal.net What is an Inflector Window Insulator? http://www.youtube.com/watch?v=3D= 21DiKS5mt4k =20 =20 Energy Efficiency Done Right presents information on the In'Flector Se= e Through Radiant Barrier Window and Skylight Insulator and the Energy= Efficiency Industry. We will examine the growth of the energy efficie= ncy, conservation, energy independence, and carbon emmission industrie= s and explain opportunities to represent or purchase our Insulator pro= ducts. Register for a session now by clicking a date below: Tue, Sep 10, 2013 10:00 AM - 11:00 AM CDT Tue, Oct 15, 2013 10:00 AM - 11:00 AM CDT Once registered you will receive an email confirming your registration= with information you need to join the Webinar. System Requirements PC-based attendees Required: Windows=C2=AE 8, 7, Vista, XP or 2003 Server Mac=C2=AE-based attendees Required: Mac OS=C2=AE X 10.6 or newer Mobile attendees Required: iPhone=C2=AE, iPad=C2=AE, Android=E2=84=A2 phone or Android = tablet Unsubscribe by email Keith Roberts 10854 Lake Path San Antonio, TX 78217 Inflector Window Insulators - See Thru Radiant Barrier droberts43@sbcglobal.net This is an advetisement for a webinar! From owner-freebsd-stable@FreeBSD.ORG Sun Sep 8 11:04:00 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C5391842; Sun, 8 Sep 2013 11:04:00 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D92B7280F; Sun, 8 Sep 2013 11:03:59 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id q59so4338246wes.20 for ; Sun, 08 Sep 2013 04:03:58 -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:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=OfzKnw+ZXLFnMJ6LGxya211QBJy4856luclTo0+CGZk=; b=JhwjLtV+syttFYd9FkdLHtzlm4TGG/9uiBYeITslz6YVerHPSvqGUmA1KZedqFHgQ4 YvJR8ANjKzNn64r78/HkfDt+QyTN8nTyEdQqSktVWlbE3eTrBF4sqZjQm1TSqwmlMywP 6OS+nIDuEjAHCj1cXMa32C4nA7gOYbxkZO4UlXP0TWztwOsCX7uGH6CvSllfwSC715j5 yjys3gekukAhJBn19+0dTIuuHHvaJcsgXTCUo4QvP2+YNzq1QJGV0arjEtCa7mmIKydK /hmvGH7mytA4f8gLpzfm/kr+z8cPl3favF/VVYm8XXYe5ZaxEdNMCnWp/UVtpusPPJxS vyWg== X-Received: by 10.180.105.226 with SMTP id gp2mr4773257wib.6.1378638238323; Sun, 08 Sep 2013 04:03:58 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id a8sm9581395wie.6.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 08 Sep 2013 04:03:57 -0700 (PDT) Sender: Baptiste Daroussin Date: Sun, 8 Sep 2013 13:03:55 +0200 From: Baptiste Daroussin To: Maxim Sobolev Subject: Re: Troubles with dependencies (file -L is broken?) Message-ID: <20130908110354.GJ77141@ithaqua.etoilebsd.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fKov5AqTsvseSZ0Z" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ports@freebsd.org, stable@freebsd.org, portmgr@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Sep 2013 11:04:00 -0000 --fKov5AqTsvseSZ0Z Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 08, 2013 at 12:09:32AM -0700, Maxim Sobolev wrote: > Hi, >=20 > I am trying to portupgrade my subversion and it keeps trying to install > databases/db42 over already installed version (same version), missing the > shared library dependency. >=20 > Adding some debug into bsd.port.mk, I see: >=20 > =3D=3D=3D> subversion-1.8.3 depends on package: libtool>=3D2.4 - found > set -x; set -e ; for i in libdb-4.2.so:/usr/ports/databases/db42; do > lib=3D${i%%:*} ; dir=3D${i#*:} ; target=3D"install"; depends_args=3D"= "; echo > -n "=3D=3D=3D> subversion-1.8.3 depends on shared library: ${lib}" ; f= ound=3D0 > ; dirs=3D"/lib /usr/lib /usr/local/lib `/bin/cat > /usr/local/libdata/ldconfig/* 2>/dev/null || : `" ; for libdir in $dirs; > do test -f ${libdir}/${lib} || continue; if [ -x /usr/bin/file ]; then = [ > `file -b -L --mime-type ${libdir}/${lib}` =3D "application/x-sharedlib" ]= || > continue ; fi ; found=3D1 ; echo " - found"; done ; if [ ${found} -e= q 0 > ]; then echo " - not found"; echo "=3D=3D=3D> Verifying for $lib in = $dir"; > if [ ! -d "$dir" ] ; then echo " =3D> No directory for $lib. > Skipping.."; else if [ -n "" -o -n "" ]; then subpkgfile=3D`(cd $dir; = make > $depends_args -V PKGFILE)`; subpkgname=3D${subpkgfile%-*} ; > subpkgname=3D${subpkgname##*/} ; if [ -r "${subpkgfile}" -a "$target" =3D > "install" ]; then echo "=3D=3D=3D> Installing existing package > ${subpkgfile}"; if [ -n "" -a ${subpkgname} =3D "pkg" ]; then [ -d > /usr/ports/devel/subversion/work ] || /bin/mkdir -p > /usr/ports/devel/subversion/work ; /usr/bin/tar xf ${subpkgfile} -C > /usr/ports/devel/subversion/work -s ",/.*/,,g" "*/pkg-static" ; > /usr/ports/devel/subversion/work/pkg-static add ${subpkgfile}; /bin/rm -f > /usr/ports/devel/subversion/work/pkg-static; else /usr/sbin/pkg_add > ${subpkgfile}; fi; elif [ -n "" -a "${target}" =3D "install" ]; then e= cho > "=3D=3D=3D> subversion-1.8.3 depends on package: ${subpkgfile} - not fo= und"; > echo "=3D=3D=3D> USE_PACKAGE_DEPENDS_ONLY set - will not build from sou= rce"; > exit 1; else (cd $dir; make -DINSTALLS_DEPENDS $target $depends_args) ; > fi; else (cd $dir; make -DINSTALLS_DEPENDS $target $depends_args) ; fi; > echo "=3D=3D=3D> Returning to build of subversion-1.8.3"; fi ; fi ; = done > + set -e > + lib=3Dlibdb-4.2.so > + dir=3D/usr/ports/databases/db42 > + target=3Dinstall > + depends_args=3D'' > + echo -n '=3D=3D=3D> subversion-1.8.3 depends on shared library: libdb= -4.2.so' > =3D=3D=3D> subversion-1.8.3 depends on shared library: libdb-4.2.so+ fo= und=3D0 > + /bin/cat /usr/local/libdata/ldconfig/compat7x > /usr/local/libdata/ldconfig/mysql /usr/local/libdata/ldconfig/portupgrade > /usr/local/libdata/ldconfig/pth > + dirs=3D'/lib /usr/lib /usr/local/lib /usr/local/lib/compat > /usr/local/lib/mysql > /usr/local/lib/compat/pkg > /usr/local/lib/pth' > + test -f /lib/libdb-4.2.so > + continue > + test -f /usr/lib/libdb-4.2.so > + continue > + test -f /usr/local/lib/libdb-4.2.so > + [ -x /usr/bin/file ] > + file -b -L --mime-type /usr/local/lib/libdb-4.2.so > + [ inode/symlink =3D application/x-sharedlib ] > + continue > + test -f /usr/local/lib/compat/libdb-4.2.so > + continue > + test -f /usr/local/lib/mysql/libdb-4.2.so > + continue > + test -f /usr/local/lib/compat/pkg/libdb-4.2.so > + continue > + test -f /usr/local/lib/pth/libdb-4.2.so > + continue > + [ 0 -eq 0 ] > + echo ' - not found' > - not found > + echo '=3D=3D=3D> Verifying for libdb-4.2.so in /usr/ports/databases/= db42' > =3D=3D=3D> Verifying for libdb-4.2.so in /usr/ports/databases/db42 >=20 > So, file(1) call is the culprit here. Trying to reproduce in the console: >=20 > [sobomax@pioneer ~]$ file -b -L --mime-type /usr/local/lib/libdb-4.2.so > inode/symlink >=20 > However: >=20 > [sobomax@pioneer ~]$ hexdump -C /usr/local/lib/libdb-4.2.so | head -n 20 > 00000000 7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00 > |.ELF............| > 00000010 03 00 3e 00 01 00 00 00 d0 40 02 00 00 00 00 00 > |..>.....=D0=BF@......| > 00000020 40 00 00 00 00 00 00 00 b8 a6 0e 00 00 00 00 00 > |@.......=E2=95=A6=D1=96......| > 00000030 00 00 00 00 40 00 38 00 05 00 40 00 1d 00 1a 00 |....@.8...@ > .....| > 00000040 01 00 00 00 05 00 00 00 00 00 00 00 00 00 00 00 > |................| > 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > 00000060 dc 45 0e 00 00 00 00 00 dc 45 0e 00 00 00 00 00 > |=D1=8DE......=D1=8DE......| > 00000070 00 00 20 00 00 00 00 00 01 00 00 00 06 00 00 00 |.. > .............| > 00000080 00 50 0e 00 00 00 00 00 00 50 2e 00 00 00 00 00 > |.P.......P......| > 00000090 00 50 2e 00 00 00 00 00 fc 36 00 00 00 00 00 00 > |.P......=D0=AD6......| > 000000a0 d8 3a 00 00 00 00 00 00 00 00 20 00 00 00 00 00 |=D1=8C:.....= =2E.. > .....| > 000000b0 02 00 00 00 06 00 00 00 e8 54 0e 00 00 00 00 00 > |........=D0=A5T......| > 000000c0 e8 54 2e 00 00 00 00 00 e8 54 2e 00 00 00 00 00 > |=D0=A5T......=D0=A5T......| > 000000d0 a0 01 00 00 00 00 00 00 a0 01 00 00 00 00 00 00 > |=E2=95=90.......=E2=95=90.......| > 000000e0 08 00 00 00 00 00 00 00 50 e5 74 64 04 00 00 00 > |........P=D0=95td....| > 000000f0 5c 39 0d 00 00 00 00 00 5c 39 0d 00 00 00 00 00 > |\9......\9......| > 00000100 5c 39 0d 00 00 00 00 00 b4 34 00 00 00 00 00 00 > |\9......=D0=844......| > 00000110 b4 34 00 00 00 00 00 00 04 00 00 00 00 00 00 00 > |=D0=844..............| >=20 > The culprit is that /usr/local/lib/libdb-4.2.so is a symlink to another > symlink to another symlink etc, so that my guess is that file(1) stops at > the first one. The issue can be resolved by using realpath(1), attached > patch fixes it for me. >=20 > [sobomax@pioneer ~]$ realpath /usr/local/lib/libdb-4.2.so > /usr/local/lib/db42/libdb-4.2.so.2 > [sobomax@pioneer ~]$ file -b -L --mime-type > /usr/local/lib/db42/libdb-4.2.so.2 > application/x-sharedlib > [sobomax@pioneer ~]$ ls -l /usr/local/lib/libdb-4.2.so > lrwxr-xr-x 1 root wheel 14 7 =D1=81=D0=B5=D0=BD 21:43 /usr/local/lib/= libdb-4.2.so -> > libdb-4.2.so.2 >=20 > I am not sure what's the process to get bsd.port.mk adjusted these days. > Should I open a PR and assign it to portmgr? The problem is file -L is resolving only one level of symlinks. Yes that is usually still the process, but given I got time right now to te= st it, please just commit :) Approved by: portmgr (bapt) regards, Bapt --fKov5AqTsvseSZ0Z Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlIsWZoACgkQ8kTtMUmk6EwCzgCguoQ+/9s4AFMUjZ34ngi382vJ 8AgAn1bSOu3PD8qj00/wMPSjV5Oi3SeD =/IXW -----END PGP SIGNATURE----- --fKov5AqTsvseSZ0Z-- From owner-freebsd-stable@FreeBSD.ORG Sun Sep 8 15:37:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9ADBDE6A for ; Sun, 8 Sep 2013 15:37:24 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 8783E237C for ; Sun, 8 Sep 2013 15:37:24 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id BB7201A3C1C; Sun, 8 Sep 2013 08:37:15 -0700 (PDT) Message-ID: <522C99AA.7010008@mu.org> Date: Sun, 08 Sep 2013 08:37:14 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ryan McIntosh Subject: Re: Looking for driver help References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Sep 2013 15:37:24 -0000 On 9/8/13 3:01 AM, Ryan McIntosh wrote: > I sent an email out to freebsd-net without a response, soo this is my last > attempt at getting any assistance here. > > I have a QLE3142-CU-CK (rebranded NetXen NX3-20GCU w/ NX3031 chipset) with > no driver support in *BSD from anything I saw. I came across solaris's ntxn > driver which seems to work appropriately but I have no use for solaris as a > host o/s. Naturally I'll attempt at trying to get the driver to work > myself, however I'm far from knowledgeable on the method to port a driver, > but I won't say no to making it work after the response Qlogic gave me. Any > insight/assistance/pointers would be helpful, including which mailing list > might be best for this. > > Ryan > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > What version of FreeBSD are you using? FreeBSD 10 has drivers for several qlogic 10gb cards. It would help to see output of "pciconf -l" on this machine as well knowing what version you are using. -- Alfred Perlstein From owner-freebsd-stable@FreeBSD.ORG Sun Sep 8 18:52:46 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 79498A12 for ; Sun, 8 Sep 2013 18:52:46 +0000 (UTC) (envelope-from dmagda@ee.ryerson.ca) Received: from eccles.ee.ryerson.ca (eccles.ee.ryerson.ca [141.117.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D6B92B68 for ; Sun, 8 Sep 2013 18:52:45 +0000 (UTC) Received: from [172.16.2.5] (108-161-115-55.dsl.teksavvy.com [108.161.115.55] (may be forged)) (authenticated bits=0) by eccles.ee.ryerson.ca (8.14.4/8.14.4) with ESMTP id r88INgPq064397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 8 Sep 2013 14:23:42 -0400 (EDT) (envelope-from dmagda@ee.ryerson.ca) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: system backups (was: Package database) From: David Magda In-Reply-To: Date: Sun, 8 Sep 2013 14:23:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <766C432A-E956-40C4-BA9B-4A3B938A3074@ee.ryerson.ca> References: To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.1508) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Sep 2013 18:52:46 -0000 On Sep 6, 2013, at 12:23, Jim Ballantine wrote: > The backup in /var/backups was a copy of the current DB, so it was not > usable, however there was/is and older backup that was not corrupt. = So I restored > it into /var/db and then update that one. Which is nice reminder to everyone about the importance that fact that a = "proper" backup is a coherent copy of data on independent media. Ideally = one would coherent copies going back in time over various periods in = case earlier ones are corrupted. It's good that this worked out for the OP, but this raises a question in = my mind (as someone who works in IT): what things on FreeBSD are = considered "system files" that need to be regularly backed up? The simplest thing is to just backup all the files on every system, but = are there more critical files. Most people would include /etc and = user/personal data (e.g., /home) as important, but as we've learned in = this thread, there are other files that are important for a properly = working system. Is backing up all /var on the "critical" list? Only = /var/db or /var/backups? From owner-freebsd-stable@FreeBSD.ORG Sun Sep 8 19:40:42 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B76D57EA; Sun, 8 Sep 2013 19:40:42 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 708452D4D; Sun, 8 Sep 2013 19:40:42 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id tb18so5302478obb.16 for ; Sun, 08 Sep 2013 12:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Wrr75Os1a9dcKd9R4qc3Nb4PnIi2Mc51U59dfkHsTBw=; b=STqdC4zM3PO75dtGoov4HbEb1VMy9D3QrHMxXseBu7orOzq1s4lj8WYr/RppqgS1Ts 88cYE9lbH5lAqTw3VNH/KbyCHFvWtEOj0gxRliRMppuqomPg+YNw77Mp/KTwzZP3MbOy eN+ubu24BL3NGkRMdG522cQOsqc0ApmKjTISfMu495lD2emYGnl/3LQn7OOQyb2Zq0d9 /Zuj4wxmHr9naGEmKoyN9z2tohV8tuCBt5+q53QaavJP5jnGfspYULAG77+45RCQ4jX9 t5gwNTPsTjTYTbznq3yVp5jwXsbAc27PLyZ43JP6i3eiZWojT7QH8FgzbyduUhjpdpcb h9kA== MIME-Version: 1.0 X-Received: by 10.182.176.105 with SMTP id ch9mr9012077obc.40.1378669241714; Sun, 08 Sep 2013 12:40:41 -0700 (PDT) Received: by 10.182.22.161 with HTTP; Sun, 8 Sep 2013 12:40:41 -0700 (PDT) Date: Sun, 8 Sep 2013 21:40:41 +0200 Message-ID: Subject: 9.2-STABLE: supervisor read data, page not present From: Oliver Pinter To: stable@freebsd.org Content-Type: multipart/mixed; boundary=e89a8ff1bf9a6a4d5d04e5e47224 Cc: kib@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Sep 2013 19:40:42 -0000 --e89a8ff1bf9a6a4d5d04e5e47224 Content-Type: text/plain; charset=ISO-8859-1 Hi! I got this panic on recent 9-STABLE (amd64): 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: <118>Sep 8 20:22:34 pandora-d syslogd: exiting on signal 15 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x78 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80482a05 stack pointer = 0x28:0xffffff800024e7d0 frame pointer = 0x28:0xffffff800024e800 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 = 1 (init) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xffffffff804cd660 at kdb_backtrace+0x60 #1 0xffffffff8049797e at panic+0x1fe #2 0xffffffff8069e3da at trap_fatal+0x37a #3 0xffffffff8069e64b at trap_pfault+0x25b #4 0xffffffff8069dd74 at trap+0x454 #5 0xffffffff80688543 at calltrap+0x8 #6 0xffffffff8046893b at proc_reap+0x4bb #7 0xffffffff80468d51 at proc_to_reap+0x361 #8 0xffffffff80467ddb at kern_wait6+0x22b #9 0xffffffff804679b6 at sys_wait4+0x76 #10 0xffffffff8069eb9d at amd64_syscall+0x29d #11 0xffffffff8068882b at Xfast_syscall+0xfb Uptime: 34m20s Dumping 367 out of 4084 MB:..5%..14%..22%..31%..44%..53%..62%..75%..83%..92% This is fully reproducible. The HEAD stay on : commit aba57138f98f1a98e4b7c7c61511daefb0542524 Author: des Date: Sun Sep 8 10:04:26 2013 +0000 Make libldns and libssh private. Approved by: re (blanket) Notes: svn path=/head/; revision=255386 The panic first appeared on likely between august 8 and 17. When you need more info, the ping me. --e89a8ff1bf9a6a4d5d04e5e47224 Content-Type: application/octet-stream; name=STABLE Content-Disposition: attachment; filename=STABLE Content-Transfer-Encoding: base64 X-Attachment-Id: file1 IwojIEdFTkVSSUMgLS0gR2VuZXJpYyBrZXJuZWwgY29uZmlndXJhdGlvbiBmaWxlIGZvciBGcmVl QlNEL2FtZDY0CiMKIyBGb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiB0aGlzIGZpbGUsIHBsZWFzZSBy ZWFkIHRoZSBjb25maWcoNSkgbWFudWFsIHBhZ2UsCiMgYW5kL29yIHRoZSBoYW5kYm9vayBzZWN0 aW9uIG9uIEtlcm5lbCBDb25maWd1cmF0aW9uIEZpbGVzOgojCiMgICAgaHR0cDovL3d3dy5GcmVl QlNELm9yZy9kb2MvZW5fVVMuSVNPODg1OS0xL2Jvb2tzL2hhbmRib29rL2tlcm5lbGNvbmZpZy1j b25maWcuaHRtbAojCiMgVGhlIGhhbmRib29rIGlzIGFsc28gYXZhaWxhYmxlIGxvY2FsbHkgaW4g L3Vzci9zaGFyZS9kb2MvaGFuZGJvb2sKIyBpZiB5b3UndmUgaW5zdGFsbGVkIHRoZSBkb2MgZGlz dHJpYnV0aW9uLCBvdGhlcndpc2UgYWx3YXlzIHNlZSB0aGUKIyBGcmVlQlNEIFdvcmxkIFdpZGUg V2ViIHNlcnZlciAoaHR0cDovL3d3dy5GcmVlQlNELm9yZy8pIGZvciB0aGUKIyBsYXRlc3QgaW5m b3JtYXRpb24uCiMKIyBBbiBleGhhdXN0aXZlIGxpc3Qgb2Ygb3B0aW9ucyBhbmQgbW9yZSBkZXRh aWxlZCBleHBsYW5hdGlvbnMgb2YgdGhlCiMgZGV2aWNlIGxpbmVzIGlzIGFsc28gcHJlc2VudCBp biB0aGUgLi4vLi4vY29uZi9OT1RFUyBhbmQgTk9URVMgZmlsZXMuCiMgSWYgeW91IGFyZSBpbiBk b3VidCBhcyB0byB0aGUgcHVycG9zZSBvciBuZWNlc3NpdHkgb2YgYSBsaW5lLCBjaGVjayBmaXJz dAojIGluIE5PVEVTLgojCiMgJEZyZWVCU0Q6IHN0YWJsZS85L3N5cy9hbWQ2NC9jb25mL0dFTkVS SUMgMjQ1OTM5IDIwMTMtMDEtMjYgMDU6MjM6MTdaIGRlbHBoaWogJAoKY3B1CQlIQU1NRVIKaWRl bnQJCVNUQUJMRS1OUAoKbWFrZW9wdGlvbnMJREVCVUc9LWcJCSMgQnVpbGQga2VybmVsIHdpdGgg Z2RiKDEpIGRlYnVnIHN5bWJvbHMKCm9wdGlvbnMgCVNDSEVEX1VMRQkJIyBVTEUgc2NoZWR1bGVy Cm9wdGlvbnMJCUhaPTEwMApvcHRpb25zIAlJTkVUCQkJIyBJbnRlck5FVHdvcmtpbmcKb3B0aW9u cyAJSU5FVDYJCQkjIElQdjYgY29tbXVuaWNhdGlvbnMgcHJvdG9jb2xzCiNvcHRpb25zIAlTQ1RQ CQkJIyBTdHJlYW0gQ29udHJvbCBUcmFuc21pc3Npb24gUHJvdG9jb2wKb3B0aW9ucyAJRkZTCQkJ IyBCZXJrZWxleSBGYXN0IEZpbGVzeXN0ZW0Kb3B0aW9ucyAJU09GVFVQREFURVMJCSMgRW5hYmxl IEZGUyBzb2Z0IHVwZGF0ZXMgc3VwcG9ydApvcHRpb25zIAlVRlNfQUNMCQkJIyBTdXBwb3J0IGZv ciBhY2Nlc3MgY29udHJvbCBsaXN0cwpvcHRpb25zIAlVRlNfRElSSEFTSAkJIyBJbXByb3ZlIHBl cmZvcm1hbmNlIG9uIGJpZyBkaXJlY3RvcmllcwpvcHRpb25zIAlVRlNfR0pPVVJOQUwJCSMgRW5h YmxlIGdqb3VybmFsLWJhc2VkIFVGUyBqb3VybmFsaW5nCm9wdGlvbnMgCVFVT1RBCQkJIyBFbmFi bGUgZGlzayBxdW90YXMgZm9yIFVGUwojb3B0aW9ucwkJUFJPQ0ZTCm9wdGlvbnMgCVBTRVVET0ZT CQkjIFBzZXVkby1maWxlc3lzdGVtIGZyYW1ld29yawpvcHRpb25zIAlHRU9NX1BBUlRfR1BUCQkj IEdVSUQgUGFydGl0aW9uIFRhYmxlcy4Kb3B0aW9ucyAJR0VPTV9SQUlECQkjIFNvZnQgUkFJRCBm dW5jdGlvbmFsaXR5LgpvcHRpb25zIAlHRU9NX0xBQkVMCQkjIFByb3ZpZGVzIGxhYmVsaXphdGlv bgpvcHRpb25zIAlDT01QQVRfRlJFRUJTRDMyCSMgQ29tcGF0aWJsZSB3aXRoIGkzODYgYmluYXJp ZXMKI29wdGlvbnMgCUNPTVBBVF9GUkVFQlNENAkJIyBDb21wYXRpYmxlIHdpdGggRnJlZUJTRDQK I29wdGlvbnMgCUNPTVBBVF9GUkVFQlNENQkJIyBDb21wYXRpYmxlIHdpdGggRnJlZUJTRDUKI29w dGlvbnMgCUNPTVBBVF9GUkVFQlNENgkJIyBDb21wYXRpYmxlIHdpdGggRnJlZUJTRDYKI29wdGlv bnMgCUNPTVBBVF9GUkVFQlNENwkJIyBDb21wYXRpYmxlIHdpdGggRnJlZUJTRDcKb3B0aW9ucyAJ U0NTSV9ERUxBWT01MDAwCQkjIERlbGF5IChpbiBtcykgYmVmb3JlIHByb2JpbmcgU0NTSQpvcHRp b25zIAlLVFJBQ0UJCQkjIGt0cmFjZSgxKSBzdXBwb3J0Cm9wdGlvbnMgCVNUQUNLCQkJIyBzdGFj ayg5KSBzdXBwb3J0Cm9wdGlvbnMgCVNZU1ZTSE0JCQkjIFNZU1Ytc3R5bGUgc2hhcmVkIG1lbW9y eQpvcHRpb25zIAlTWVNWTVNHCQkJIyBTWVNWLXN0eWxlIG1lc3NhZ2UgcXVldWVzCm9wdGlvbnMg CVNZU1ZTRU0JCQkjIFNZU1Ytc3R5bGUgc2VtYXBob3JlcwpvcHRpb25zIAlfS1BPU0lYX1BSSU9S SVRZX1NDSEVEVUxJTkcgIyBQT1NJWCBQMTAwM18xQiByZWFsLXRpbWUgZXh0ZW5zaW9ucwpvcHRp b25zIAlQUklOVEZfQlVGUl9TSVpFPTEyOAkjIFByZXZlbnQgcHJpbnRmIG91dHB1dCBiZWluZyBp bnRlcnNwZXJzZWQuCm9wdGlvbnMgCUtCRF9JTlNUQUxMX0NERVYJIyBpbnN0YWxsIGEgQ0RFViBl bnRyeSBpbiAvZGV2Cm9wdGlvbnMgCUhXUE1DX0hPT0tTCQkjIE5lY2Vzc2FyeSBrZXJuZWwgaG9v a3MgZm9yIGh3cG1jKDQpCm9wdGlvbnMgCUFVRElUCQkJIyBTZWN1cml0eSBldmVudCBhdWRpdGlu ZwpvcHRpb25zIAlNQUMJCQkjIFRydXN0ZWRCU0QgTUFDIEZyYW1ld29yawpvcHRpb25zCQlNQUNf QlNERVhURU5ERUQKI29wdGlvbnMgCUtEVFJBQ0VfRlJBTUUJCSMgRW5zdXJlIGZyYW1lcyBhcmUg Y29tcGlsZWQgaW4KI29wdGlvbnMgCUtEVFJBQ0VfSE9PS1MJCSMgS2VybmVsIERUcmFjZSBob29r cwpvcHRpb25zIAlJTkNMVURFX0NPTkZJR19GSUxFICAgICAjIEluY2x1ZGUgdGhpcyBmaWxlIGlu IGtlcm5lbApvcHRpb25zIAlLREIJCQkjIEtlcm5lbCBkZWJ1Z2dlciByZWxhdGVkIGNvZGUKb3B0 aW9ucyAJS0RCX1RSQUNFCQkjIFByaW50IGEgc3RhY2sgdHJhY2UgZm9yIGEgcGFuaWMKCiMgTWFr ZSBhbiBTTVAtY2FwYWJsZSBrZXJuZWwgYnkgZGVmYXVsdApvcHRpb25zIAlTTVAJCQkjIFN5bW1l dHJpYyBNdWx0aVByb2Nlc3NvciBLZXJuZWwKCiMgQ1BVIGZyZXF1ZW5jeSBjb250cm9sCmRldmlj ZQkJY3B1ZnJlcQoKIyBCdXMgc3VwcG9ydC4KZGV2aWNlCQlhY3BpCmRldmljZQkJcGNpCgojIEFU QSBjb250cm9sbGVycwpkZXZpY2UJCWFoY2kJCSMgQUhDSS1jb21wYXRpYmxlIFNBVEEgY29udHJv bGxlcnMKZGV2aWNlCQlhdGEJCSMgTGVnYWN5IEFUQS9TQVRBIGNvbnRyb2xsZXJzCm9wdGlvbnMg CUFUQV9DQU0JCSMgSGFuZGxlIGxlZ2FjeSBjb250cm9sbGVycyB3aXRoIENBTQpvcHRpb25zIAlB VEFfU1RBVElDX0lECSMgU3RhdGljIGRldmljZSBudW1iZXJpbmcKCiMgQVRBL1NDU0kgcGVyaXBo ZXJhbHMKZGV2aWNlCQlzY2J1cwkJIyBTQ1NJIGJ1cyAocmVxdWlyZWQgZm9yIEFUQS9TQ1NJKQpk ZXZpY2UJCWNoCQkjIFNDU0kgbWVkaWEgY2hhbmdlcnMKZGV2aWNlCQlkYQkJIyBEaXJlY3QgQWNj ZXNzIChkaXNrcykKZGV2aWNlCQlwYXNzCQkjIFBhc3N0aHJvdWdoIGRldmljZSAoZGlyZWN0IEFU QS9TQ1NJIGFjY2VzcykKZGV2aWNlCQlzZXMJCSMgRW5jbG9zdXJlIFNlcnZpY2VzIChTRVMgYW5k IFNBRi1URSkKCiMgYXRrYmRjMCBjb250cm9scyBib3RoIHRoZSBrZXlib2FyZCBhbmQgdGhlIFBT LzIgbW91c2UKI2RldmljZQkJYXRrYmRjCQkjIEFUIGtleWJvYXJkIGNvbnRyb2xsZXIKI2Rldmlj ZQkJYXRrYmQJCSMgQVQga2V5Ym9hcmQKI2RldmljZQkJcHNtCQkjIFBTLzIgbW91c2UKCmRldmlj ZQkJa2JkbXV4CQkjIGtleWJvYXJkIG11bHRpcGxleGVyCgpkZXZpY2UJCXZnYQkJIyBWR0Egdmlk ZW8gY2FyZCBkcml2ZXIKb3B0aW9ucyAJVkVTQQkJIyBBZGQgc3VwcG9ydCBmb3IgVkVTQSBCSU9T IEV4dGVuc2lvbnMgKFZCRSkKCiMgc3lzY29ucyBpcyB0aGUgZGVmYXVsdCBjb25zb2xlIGRyaXZl ciwgcmVzZW1ibGluZyBhbiBTQ08gY29uc29sZQpkZXZpY2UJCXNjCm9wdGlvbnMgCVNDX1BJWEVM X01PREUJIyBhZGQgc3VwcG9ydCBmb3IgdGhlIHJhc3RlciB0ZXh0IG1vZGUKCmRldmljZQkJYWdw CQkjIHN1cHBvcnQgc2V2ZXJhbCBBR1AgY2hpcHNldHMKCiMgU2VyaWFsIChDT00pIHBvcnRzCmRl dmljZQkJdWFydAkJIyBHZW5lcmljIFVBUlQgZHJpdmVyCgoKIyBQQ0kgRXRoZXJuZXQgTklDcyB0 aGF0IHVzZSB0aGUgY29tbW9uIE1JSSBidXMgY29udHJvbGxlciBjb2RlLgojIE5PVEU6IEJlIHN1 cmUgdG8ga2VlcCB0aGUgJ2RldmljZSBtaWlidXMnIGxpbmUgaW4gb3JkZXIgdG8gdXNlIHRoZXNl IE5JQ3MhCiNkZXZpY2UJCW1paWJ1cwkJIyBNSUkgYnVzIHN1cHBvcnQKZGV2aWNlCQltaWkKZGV2 aWNlCQllMTAwMHBoeQpkZXZpY2UJCW1zawkJIyBNYXJ2ZWxsL1N5c0tvbm5lY3QgWXVrb24gSUkg R2lnYWJpdCBFdGhlcm5ldApkZXZpY2UJCXNrCQkjIFN5c0tvbm5lY3QgU0stOTg0eCAmIFNLLTk4 MnggZ2lnYWJpdCBFdGhlcm5ldAoKIyBQc2V1ZG8gZGV2aWNlcy4KZGV2aWNlCQlsb29wCQkjIE5l dHdvcmsgbG9vcGJhY2sKZGV2aWNlCQlyYW5kb20JCSMgRW50cm9weSBkZXZpY2UKb3B0aW9ucyAJ UkRSQU5EX1JORwkjIEludGVsIEJ1bGwgTW91bnRhaW4gUk5HCmRldmljZQkJZXRoZXIJCSMgRXRo ZXJuZXQgc3VwcG9ydApkZXZpY2UJCXZsYW4JCSMgODAyLjFRIFZMQU4gc3VwcG9ydApkZXZpY2UJ CXR1bgkJIyBQYWNrZXQgdHVubmVsLgpkZXZpY2UJCXB0eQkJIyBCU0Qtc3R5bGUgY29tcGF0aWJp bGl0eSBwc2V1ZG8gdHR5cwpkZXZpY2UJCW1kCQkjIE1lbW9yeSAiZGlza3MiCmRldmljZQkJZ2lm CQkjIElQdjYgYW5kIElQdjQgdHVubmVsaW5nCmRldmljZQkJZmFpdGgJCSMgSVB2Ni10by1JUHY0 IHJlbGF5aW5nICh0cmFuc2xhdGlvbikKZGV2aWNlCQlmaXJtd2FyZQkjIGZpcm13YXJlIGFzc2lz dCBtb2R1bGUKCiMgVGhlIGBicGYnIGRldmljZSBlbmFibGVzIHRoZSBCZXJrZWxleSBQYWNrZXQg RmlsdGVyLgojIEJlIGF3YXJlIG9mIHRoZSBhZG1pbmlzdHJhdGl2ZSBjb25zZXF1ZW5jZXMgb2Yg ZW5hYmxpbmcgdGhpcyEKIyBOb3RlIHRoYXQgJ2JwZicgaXMgcmVxdWlyZWQgZm9yIERIQ1AuCmRl dmljZQkJYnBmCQkjIEJlcmtlbGV5IHBhY2tldCBmaWx0ZXIKCiMgVVNCIHN1cHBvcnQKb3B0aW9u cyAJVVNCX0RFQlVHCSMgZW5hYmxlIGRlYnVnIG1zZ3MKZGV2aWNlCQl1aGNpCQkjIFVIQ0kgUENJ LT5VU0IgaW50ZXJmYWNlCmRldmljZQkJb2hjaQkJIyBPSENJIFBDSS0+VVNCIGludGVyZmFjZQpk ZXZpY2UJCWVoY2kJCSMgRUhDSSBQQ0ktPlVTQiBpbnRlcmZhY2UgKFVTQiAyLjApCiNkZXZpY2UJ CXhoY2kJCSMgWEhDSSBQQ0ktPlVTQiBpbnRlcmZhY2UgKFVTQiAzLjApCmRldmljZQkJdXNiCQkj IFVTQiBCdXMgKHJlcXVpcmVkKQpkZXZpY2UJCXVoaWQJCSMgIkh1bWFuIEludGVyZmFjZSBEZXZp Y2VzIgpkZXZpY2UJCXVrYmQJCSMgS2V5Ym9hcmQKZGV2aWNlCQl1bXMKCiMgU291bmQgc3VwcG9y dApkZXZpY2UJCXNvdW5kCQkjIEdlbmVyaWMgc291bmQgZHJpdmVyIChyZXF1aXJlZCkKZGV2aWNl CQlzbmRfaGRhCQkjIEludGVsIEhpZ2ggRGVmaW5pdGlvbiBBdWRpbwoKZGV2aWNlCQlhaWJzCmRl dmljZQkJY3B1Y3RsCmRldmljZQkJY29yZXRlbXAKb3B0aW9ucwkJSVBGSVJFV0FMTApvcHRpb25z CQlJUEZJUkVXQUxMX1ZFUkJPU0UKb3B0aW9ucwkJSVBGSVJFV0FMTF9WRVJCT1NFX0xJTUlUPTEw Cm9wdGlvbnMJCUlQU1RFQUxUSApvcHRpb25zCQlTQ19ESVNBQkxFX1JFQk9PVAkjIEN0cmwtQWx0 LURlbApkZXZpY2UJCXNtYgpkZXZpY2UJCXNtYnVzCmRldmljZQkJaWNoc21iCgpkZXZpY2UJCXds YW4JCSMgODAyLjExIHN1cHBvcnQKb3B0aW9ucyAJSUVFRTgwMjExX0RFQlVHCSMgZW5hYmxlIGRl YnVnIG1zZ3MKb3B0aW9ucyAJSUVFRTgwMjExX0FNUERVX0FHRSAjIGFnZSBmcmFtZXMgaW4gQU1Q RFUgcmVvcmRlciBxJ3MKb3B0aW9ucyAJSUVFRTgwMjExX1NVUFBPUlRfTUVTSAkjIGVuYWJsZSA4 MDIuMTFzIGRyYWZ0IHN1cHBvcnQKZGV2aWNlCQl3bGFuX3dlcAkjIDgwMi4xMSBXRVAgc3VwcG9y dApkZXZpY2UJCXdsYW5fY2NtcAkjIDgwMi4xMSBDQ01QIHN1cHBvcnQKZGV2aWNlCQl3bGFuX3Rr aXAJIyA4MDIuMTEgVEtJUCBzdXBwb3J0CmRldmljZQkJd2xhbl9hbXJyCSMgQU1SUiB0cmFuc21p dCByYXRlIGNvbnRyb2wgYWxnb3JpdGhtCmRldmljZQkJYXRoCQkjIEF0aGVyb3MgTklDcwpkZXZp Y2UJCWF0aF9wY2kJCSMgQXRoZXJvcyBwY2kvY2FyZGJ1cyBnbHVlCmRldmljZQkJYXRoX2hhbAkJ IyBwY2kvY2FyZGJ1cyBjaGlwIHN1cHBvcnQKb3B0aW9ucyAJQUhfU1VQUE9SVF9BUjU0MTYJIyBl bmFibGUgQVI1NDE2IHR4L3J4IGRlc2NyaXB0b3JzCmRldmljZQkJYXRoX3JhdGVfc2FtcGxlCSMg U2FtcGxlUmF0ZSB0eCByYXRlIGNvbnRyb2wgZm9yIGF0aAo= --e89a8ff1bf9a6a4d5d04e5e47224 Content-Type: application/octet-stream; name="kgdb.script" Content-Disposition: attachment; filename="kgdb.script" Content-Transfer-Encoding: base64 X-Attachment-Id: file2 U2NyaXB0IHN0YXJ0ZWQgb24gU3VuIFNlcCAgOCAyMTowMDoyMyAyMDEzCm9wIGhhcyBsb2dnZWQg b24gOjAgZnJvbSBsb2NhbC4NCm9wIGhhcyBsb2dnZWQgb24gcHRzLzAgZnJvbSA6MC4NCm9wIGhh cyBsb2dnZWQgb24gdHR5djIgZnJvbSBsb2NhbC4NChtbMW1yb290G1ttQBtbNG1wYW5kb3JhLWQb WzI0bSB+IyBrZ2R2CBtbS2IgL3RtCBtbSwgbW0tib290L2tlDQ0Ka2VybmVsLm9sZC8ga2VybmVs LyAgICAgDQ0KG1sxbXJvb3QbW21AG1s0bXBhbmRvcmEtZBtbMjRtIH4jIGtnZGIgL2Jvb3Qva2Vy bmVsL2tlDQ0Ka2VybmVsKiAgICAgICAgIGtlcm5lbC5zeW1ib2xzKiANDQobWzFtcm9vdBtbbUAb WzRtcGFuZG9yYS1kG1syNG0gfiMga2dkYiAvYm9vdC9rZXJuZWwva2VybmVsIC92YXIvY3Jhc2gv dm1jDQ0Kdm1jb3JlLjAgIHZtY29yZS4xICB2bWNvcmUuMiAgdm1jb3JlLjMgIHZtY29yZS40ICB2 bWNvcmUuNSAgDQ0KG1sxbXJvb3QbW21AG1s0bXBhbmRvcmEtZBtbMjRtIH4jIGtnZGIgL2Jvb3Qv a2VybmVsL2tlcm5lbCAvdmFyL2NyYXNoL3ZtY29yZS4zIA0NCkdOVSBnZGIgNi4xLjEgW0ZyZWVC U0RdDQpDb3B5cmlnaHQgMjAwNCBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4NCkdEQiBp cyBmcmVlIHNvZnR3YXJlLCBjb3ZlcmVkIGJ5IHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5z ZSwgYW5kIHlvdSBhcmUNCndlbGNvbWUgdG8gY2hhbmdlIGl0IGFuZC9vciBkaXN0cmlidXRlIGNv cGllcyBvZiBpdCB1bmRlciBjZXJ0YWluIGNvbmRpdGlvbnMuDQpUeXBlICJzaG93IGNvcHlpbmci IHRvIHNlZSB0aGUgY29uZGl0aW9ucy4NClRoZXJlIGlzIGFic29sdXRlbHkgbm8gd2FycmFudHkg Zm9yIEdEQi4gIFR5cGUgInNob3cgd2FycmFudHkiIGZvciBkZXRhaWxzLg0KVGhpcyBHREIgd2Fz IGNvbmZpZ3VyZWQgYXMgImFtZDY0LW1hcmNlbC1mcmVlYnNkIi4uLg0KDQpVbnJlYWQgcG9ydGlv biBvZiB0aGUga2VybmVsIG1lc3NhZ2UgYnVmZmVyOg0KPDExOD5TZXAgIDggMjA6MjI6MzQgcGFu ZG9yYS1kIHN5c2xvZ2Q6IGV4aXRpbmcgb24gc2lnbmFsIDE1DQoNCg0KRmF0YWwgdHJhcCAxMjog cGFnZSBmYXVsdCB3aGlsZSBpbiBrZXJuZWwgbW9kZQ0KY3B1aWQgPSAwOyBhcGljIGlkID0gMDAN CmZhdWx0IHZpcnR1YWwgYWRkcmVzcwk9IDB4NzgNCmZhdWx0IGNvZGUJCT0gc3VwZXJ2aXNvciBy ZWFkIGRhdGEsIHBhZ2Ugbm90IHByZXNlbnQNCmluc3RydWN0aW9uIHBvaW50ZXIJPSAweDIwOjB4 ZmZmZmZmZmY4MDQ4MmEwNQ0Kc3RhY2sgcG9pbnRlcgkgICAgICAgID0gMHgyODoweGZmZmZmZjgw MDAyNGU3ZDANCmZyYW1lIHBvaW50ZXIJICAgICAgICA9IDB4Mjg6MHhmZmZmZmY4MDAwMjRlODAw DQpjb2RlIHNlZ21lbnQJCT0gYmFzZSAweDAsIGxpbWl0IDB4ZmZmZmYsIHR5cGUgMHgxYg0KCQkJ PSBEUEwgMCwgcHJlcyAxLCBsb25nIDEsIGRlZjMyIDAsIGdyYW4gMQ0KcHJvY2Vzc29yIGVmbGFn cwk9IGludGVycnVwdCBlbmFibGVkLCByZXN1bWUsIElPUEwgPSAwDQpjdXJyZW50IHByb2Nlc3MJ CT0gMSAoaW5pdCkNCnRyYXAgbnVtYmVyCQk9IDEyDQpwYW5pYzogcGFnZSBmYXVsdA0KY3B1aWQg PSAwDQpLREI6IHN0YWNrIGJhY2t0cmFjZToNCiMwIDB4ZmZmZmZmZmY4MDRjZDY2MCBhdCBrZGJf YmFja3RyYWNlKzB4NjANCiMxIDB4ZmZmZmZmZmY4MDQ5Nzk3ZSBhdCBwYW5pYysweDFmZQ0KIzIg MHhmZmZmZmZmZjgwNjllM2RhIGF0IHRyYXBfZmF0YWwrMHgzN2ENCiMzIDB4ZmZmZmZmZmY4MDY5 ZTY0YiBhdCB0cmFwX3BmYXVsdCsweDI1Yg0KIzQgMHhmZmZmZmZmZjgwNjlkZDc0IGF0IHRyYXAr MHg0NTQNCiM1IDB4ZmZmZmZmZmY4MDY4ODU0MyBhdCBjYWxsdHJhcCsweDgNCiM2IDB4ZmZmZmZm ZmY4MDQ2ODkzYiBhdCBwcm9jX3JlYXArMHg0YmINCiM3IDB4ZmZmZmZmZmY4MDQ2OGQ1MSBhdCBw cm9jX3RvX3JlYXArMHgzNjENCiM4IDB4ZmZmZmZmZmY4MDQ2N2RkYiBhdCBrZXJuX3dhaXQ2KzB4 MjJiDQojOSAweGZmZmZmZmZmODA0Njc5YjYgYXQgc3lzX3dhaXQ0KzB4NzYNCiMxMCAweGZmZmZm ZmZmODA2OWViOWQgYXQgYW1kNjRfc3lzY2FsbCsweDI5ZA0KIzExIDB4ZmZmZmZmZmY4MDY4ODgy YiBhdCBYZmFzdF9zeXNjYWxsKzB4ZmINClVwdGltZTogMzRtMjBzDQpEdW1waW5nIDM2NyBvdXQg b2YgNDA4NCBNQjouLjUlLi4xNCUuLjIyJS4uMzElLi40NCUuLjUzJS4uNjIlLi43NSUuLjgzJS4u OTIlDQoNClJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9saW51eC5rby4uLlJlYWRp bmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9saW51eC5rby5zeW1ib2xzLi4uZG9uZS4NCmRv bmUuDQpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL2xpbnV4LmtvDQpSZWFkaW5nIHN5 bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvZ2VvbV9zY2hlZC5rby4uLlJlYWRpbmcgc3ltYm9scyBm cm9tIC9ib290L2tlcm5lbC9nZW9tX3NjaGVkLmtvLnN5bWJvbHMuLi5kb25lLg0KZG9uZS4NCkxv YWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvZ2VvbV9zY2hlZC5rbw0KUmVhZGluZyBzeW1i b2xzIGZyb20gL2Jvb3Qva2VybmVsL2dzY2hlZF9yci5rby4uLlJlYWRpbmcgc3ltYm9scyBmcm9t IC9ib290L2tlcm5lbC9nc2NoZWRfcnIua28uc3ltYm9scy4uLmRvbmUuDQpkb25lLg0KTG9hZGVk IHN5bWJvbHMgZm9yIC9ib290L2tlcm5lbC9nc2NoZWRfcnIua28NCiMwICBkb2FkdW1wICh0ZXh0 ZHVtcD08dmFsdWUgb3B0aW1pemVkIG91dD4pIGF0IHBjcHUuaDoyMzQNCjIzNAlwY3B1Lmg6IE5v IHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkuDQoJaW4gcGNwdS5oDQooa2dkYikgYnQNCiMwICBkb2Fk dW1wICh0ZXh0ZHVtcD08dmFsdWUgb3B0aW1pemVkIG91dD4pIGF0IHBjcHUuaDoyMzQNCiMxICAw eGZmZmZmZmZmODA0OTc1NTQgaW4ga2Vybl9yZWJvb3QgKGhvd3RvPTI2MCkNCiAgICBhdCAvdXNy L3NyYy9zeXMva2Vybi9rZXJuX3NodXRkb3duLmM6NDQ5DQojMiAgMHhmZmZmZmZmZjgwNDk3OWNm IGluIHBhbmljIChmbXQ9PHZhbHVlIG9wdGltaXplZCBvdXQ+KQ0KICAgIGF0IC91c3Ivc3JjL3N5 cy9rZXJuL2tlcm5fc2h1dGRvd24uYzo2MzcNCiMzICAweGZmZmZmZmZmODA2OWUzZGEgaW4gdHJh cF9mYXRhbCAoZnJhbWU9PHZhbHVlIG9wdGltaXplZCBvdXQ+LCANCiAgICBldmE9PHZhbHVlIG9w dGltaXplZCBvdXQ+KSBhdCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvdHJhcC5jOjg3OQ0KIzQg IDB4ZmZmZmZmZmY4MDY5ZTY0YiBpbiB0cmFwX3BmYXVsdCAoZnJhbWU9MHgwLCB1c2VybW9kZT0w KQ0KICAgIGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC90cmFwLmM6NzAwDQojNSAgMHhmZmZm ZmZmZjgwNjlkZDc0IGluIHRyYXAgKGZyYW1lPTB4ZmZmZmZmODAwMDI0ZTcyMCkNCiAgICBhdCAv dXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvdHJhcC5jOjQ2Mw0KIzYgIDB4ZmZmZmZmZmY4MDY4ODU0 MyBpbiBjYWxsdHJhcCAoKQ0KICAgIGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC9leGNlcHRp b24uUzoyMzINCiM3ICAweGZmZmZmZmZmODA0ODJhMDUgaW4gZnJlZSAoYWRkcj0weGZmZmZmZTAw MDVjODIwMDAsIA0KICAgIG10cD0weGZmZmZmZmZmODA5ZWIxNzApIGF0IC91c3Ivc3JjL3N5cy9r ZXJuL2tlcm5fbWFsbG9jLmM6NTUxDQojOCAgMHhmZmZmZmZmZjgwNDY4OTNiIGluIHByb2NfcmVh cCAodGQ9PHZhbHVlIG9wdGltaXplZCBvdXQ+LCANCiAgICBwPTB4ZmZmZmZlMDAwNTk0MzRhOCwg c3RhdHVzPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PiwgDQogICAgb3B0aW9ucz08dmFsdWUgb3B0aW1p emVkIG91dD4pIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZXhpdC5jOjg1NA0KIzkgIDB4ZmZm ZmZmZmY4MDQ2OGQ1MSBpbiBwcm9jX3RvX3JlYXAgKHRkPTB4ZmZmZmZlMDAwMTk0ZjkyMCwgDQog ICAgcD0weGZmZmZmZTAwMDU5NDM0YTgsIGlkdHlwZT08dmFsdWUgb3B0aW1pemVkIG91dD4sIA0K ICAgIGlkPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0Piwgc3RhdHVzPTB4ZmZmZmZmODAwMDI0ZTk1NCwg b3B0aW9ucz00OCwgDQogICAgd3J1c2FnZT08dmFsdWUgb3B0aW1pemVkIG91dD4sIHNpZ2luZm89 PHZhbHVlIG9wdGltaXplZCBvdXQ+KQ0KICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZXhp dC5jOjEwMTcNCi0tLVR5cGUgPHJldHVybj4gdG8gY29udGludWUsIG9yIHEgPHJldHVybj4gdG8g cXVpdC0tLQ0KIzEwIDB4ZmZmZmZmZmY4MDQ2N2RkYiBpbiBrZXJuX3dhaXQ2ICh0ZD0weGZmZmZm ZTAwMDE5NGY5MjAsIA0KICAgIGlkdHlwZT08dmFsdWUgb3B0aW1pemVkIG91dD4sIGlkPTAsIHN0 YXR1cz0weGZmZmZmZjgwMDAyNGU5NTQsIG9wdGlvbnM9NDgsIA0KICAgIHdydXNhZ2U9MHgwLCBz aWdpbmZvPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PikNCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9r ZXJuX2V4aXQuYzoxMTA5DQojMTEgMHhmZmZmZmZmZjgwNDY3OWI2IGluIHN5c193YWl0NCAodGQ9 MHg1YzgyMDAwLCB1YXA9MHhmZmZmZmY4MDAwMjRlYmMwKQ0KICAgIGF0IC91c3Ivc3JjL3N5cy9r ZXJuL2tlcm5fZXhpdC5jOjEwNjANCiMxMiAweGZmZmZmZmZmODA2OWViOWQgaW4gYW1kNjRfc3lz Y2FsbCAodGQ9MHhmZmZmZmUwMDAxOTRmOTIwLCB0cmFjZWQ9MCkNCiAgICBhdCBzdWJyX3N5c2Nh bGwuYzoxMzUNCiMxMyAweGZmZmZmZmZmODA2ODg4MmIgaW4gWGZhc3Rfc3lzY2FsbCAoKQ0KICAg IGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC9leGNlcHRpb24uUzozOTENCiMxNCAweDAwMDAw MDAwMDA0MTNjM2MgaW4gPz8gKCkNClByZXZpb3VzIGZyYW1lIGlubmVyIHRvIHRoaXMgZnJhbWUg KGNvcnJ1cHQgc3RhY2s/KQ0KQ3VycmVudCBsYW5ndWFnZTogIGF1dG87IGN1cnJlbnRseSBtaW5p bWFsDQooa2dkYikgYnQgZnVsbA0KIzAgIGRvYWR1bXAgKHRleHRkdW1wPTx2YWx1ZSBvcHRpbWl6 ZWQgb3V0PikgYXQgcGNwdS5oOjIzNA0KTm8gbG9jYWxzLg0KIzEgIDB4ZmZmZmZmZmY4MDQ5NzU1 NCBpbiBrZXJuX3JlYm9vdCAoaG93dG89MjYwKQ0KICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tl cm5fc2h1dGRvd24uYzo0NDkNCk5vIGxvY2Fscy4NCiMyICAweGZmZmZmZmZmODA0OTc5Y2YgaW4g cGFuaWMgKGZtdD08dmFsdWUgb3B0aW1pemVkIG91dD4pDQogICAgYXQgL3Vzci9zcmMvc3lzL2tl cm4va2Vybl9zaHV0ZG93bi5jOjYzNw0KCXBhbmljX2NwdSA9IDANCglidWYgPSAicGFnZSBmYXVs dCIsICdcMCcgPHJlcGVhdHMgMjQ1IHRpbWVzPg0KCWFwID0ge3tncF9vZmZzZXQgPSAxNiwgZnBf b2Zmc2V0ID0gNDgsIA0KICAgIG92ZXJmbG93X2FyZ19hcmVhID0gMHhmZmZmZmY4MDAwMjRlNGMw LCANCiAgICByZWdfc2F2ZV9hcmVhID0gMHhmZmZmZmY4MDAwMjRlNDQwfX0NCgl0ZCA9IDx2YWx1 ZSBvcHRpbWl6ZWQgb3V0Pg0KCW5ld3BhbmljID0gPHZhbHVlIG9wdGltaXplZCBvdXQ+DQoJYm9v dG9wdCA9IDx2YWx1ZSBvcHRpbWl6ZWQgb3V0Pg0KIzMgIDB4ZmZmZmZmZmY4MDY5ZTNkYSBpbiB0 cmFwX2ZhdGFsIChmcmFtZT08dmFsdWUgb3B0aW1pemVkIG91dD4sIA0KICAgIGV2YT08dmFsdWUg b3B0aW1pemVkIG91dD4pIGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC90cmFwLmM6ODc5DQoJ c29mdHNlZyA9IHtzc2RfYmFzZSA9IDAsIHNzZF9saW1pdCA9IDEwNDg1NzUsIHNzZF90eXBlID0g MjcsIA0KICBzc2RfZHBsID0gMCwgc3NkX3AgPSAxLCBzc2RfbG9uZyA9IDEsIHNzZF9kZWYzMiA9 IDAsIHNzZF9ncmFuID0gMX0NCiM0ICAweGZmZmZmZmZmODA2OWU2NGIgaW4gdHJhcF9wZmF1bHQg KGZyYW1lPTB4MCwgdXNlcm1vZGU9MCkNCiAgICBhdCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQv dHJhcC5jOjcwMA0KCXJ2ID0gQ2Fubm90IGFjY2VzcyBtZW1vcnkgYXQgYWRkcmVzcyAweDANCihr Z2RiKSBsDQo3MDAJCQkJdHJhcF9mYXRhbChmcmFtZSwgZXZhKTsNCjcwMQkJCQlyZXR1cm4gKC0x KTsNCjcwMgkJCX0NCjcwMwkJfQ0KNzA0CQl2YSA9IHRydW5jX3BhZ2UoZXZhKTsNCjcwNQkJaWYg KHZhID49IFZNX01JTl9LRVJORUxfQUREUkVTUykgew0KNzA2CQkJLyoNCjcwNwkJCSAqIERvbid0 IGFsbG93IHVzZXItbW9kZSBmYXVsdHMgaW4ga2VybmVsIGFkZHJlc3Mgc3BhY2UuDQo3MDgJCQkg Ki8NCjcwOQkJCWlmICh1c2VybW9kZSkNCihrZ2RiKSBmIDENCiMxICAweGZmZmZmZmZmODA0OTc1 NTQgaW4ga2Vybl9yZWJvb3QgKGhvd3RvPTI2MCkNCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9r ZXJuX3NodXRkb3duLmM6NDQ5DQo0NDkJCQlkb2FkdW1wKFRSVUUpOw0KKGtnZGIpIGwNCjQ0NAkJ ICogYmVlbiBjb21wbGV0ZWQuDQo0NDUJCSAqLw0KNDQ2CQlFVkVOVEhBTkRMRVJfSU5WT0tFKHNo dXRkb3duX3Bvc3Rfc3luYywgaG93dG8pOw0KNDQ3CQ0KNDQ4CQlpZiAoKGhvd3RvICYgKFJCX0hB TFR8UkJfRFVNUCkpID09IFJCX0RVTVAgJiYgIWNvbGQgJiYgIWR1bXBpbmcpIA0KNDQ5CQkJZG9h ZHVtcChUUlVFKTsNCjQ1MAkNCjQ1MQkJLyogTm93IHRoYXQgd2UncmUgZ29pbmcgdG8gcmVhbGx5 IGhhbHQgdGhlIHN5c3RlbS4uLiAqLw0KNDUyCQlFVkVOVEhBTkRMRVJfSU5WT0tFKHNodXRkb3du X2ZpbmFsLCBob3d0byk7DQo0NTMJDQooa2dkYikgZiAyDQojMiAgMHhmZmZmZmZmZjgwNDk3OWNm IGluIHBhbmljIChmbXQ9PHZhbHVlIG9wdGltaXplZCBvdXQ+KQ0KICAgIGF0IC91c3Ivc3JjL3N5 cy9rZXJuL2tlcm5fc2h1dGRvd24uYzo2MzcNCjYzNwkJa2Vybl9yZWJvb3QoYm9vdG9wdCk7DQoo a2dkYikgbAggCGYgMw0KIzMgIDB4ZmZmZmZmZmY4MDY5ZTNkYSBpbiB0cmFwX2ZhdGFsIChmcmFt ZT08dmFsdWUgb3B0aW1pemVkIG91dD4sIA0KICAgIGV2YT08dmFsdWUgb3B0aW1pemVkIG91dD4p IGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC90cmFwLmM6ODc5DQo4NzkJCQlwYW5pYygiJXMi LCB0cmFwX21zZ1t0eXBlXSk7DQooa2dkYikgbAggCGYgNQ0KIzUgIDB4ZmZmZmZmZmY4MDY5ZGQ3 NCBpbiB0cmFwIChmcmFtZT0weGZmZmZmZjgwMDAyNGU3MjApDQogICAgYXQgL3Vzci9zcmMvc3lz L2FtZDY0L2FtZDY0L3RyYXAuYzo0NjMNCjQ2MwkJCQkodm9pZCkgdHJhcF9wZmF1bHQoZnJhbWUs IEZBTFNFKTsNCihrZ2RiKSBmIDYNCiM2ICAweGZmZmZmZmZmODA2ODg1NDMgaW4gY2FsbHRyYXAg KCkNCiAgICBhdCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvZXhjZXB0aW9uLlM6MjMyDQoyMzIJ CWNhbGwJdHJhcA0KQ3VycmVudCBsYW5ndWFnZTogIGF1dG87IGN1cnJlbnRseSBhc20NCihrZ2Ri KSBmIDcNCiM3ICAweGZmZmZmZmZmODA0ODJhMDUgaW4gZnJlZSAoYWRkcj0weGZmZmZmZTAwMDVj ODIwMDAsIA0KICAgIG10cD0weGZmZmZmZmZmODA5ZWIxNzApIGF0IC91c3Ivc3JjL3N5cy9rZXJu L2tlcm5fbWFsbG9jLmM6NTUxDQo1NTEJCQlzaXplID0gc2xhYi0+dXNfa2VnLT51a19zaXplOw0K Q3VycmVudCBsYW5ndWFnZTogIGF1dG87IGN1cnJlbnRseSBtaW5pbWFsDQooa2dkYikgbA0KNTQ2 CQ0KNTQ3CQlpZiAoIShzbGFiLT51c19mbGFncyAmIFVNQV9TTEFCX01BTExPQykpIHsNCjU0OAkj aWZkZWYgSU5WQVJJQU5UUw0KNTQ5CQkJc3RydWN0IG1hbGxvY190eXBlICoqbXRwcCA9IGFkZHI7 DQo1NTAJI2VuZGlmDQo1NTEJCQlzaXplID0gc2xhYi0+dXNfa2VnLT51a19zaXplOw0KNTUyCSNp ZmRlZiBJTlZBUklBTlRTDQo1NTMJCQkvKg0KNTU0CQkJICogQ2FjaGUgYSBwb2ludGVyIHRvIHRo ZSBtYWxsb2NfdHlwZSB0aGF0IG1vc3QgcmVjZW50bHkgZnJlZWQNCjU1NQkJCSAqIHRoaXMgbWVt b3J5IGhlcmUuICBUaGlzIHdheSB3ZSBrbm93IHdobyBpcyBtb3N0IGxpa2VseSB0bw0KKGtnZGIp IGYgCCAICCAIB3Agc2l6ZQ0KJDEgPSA8dmFsdWUgb3B0aW1pemVkIG91dD4NCihrZ2RiKSBwIHNs YWIHLT5zCCAIdXMtCCAIX2tlZyANCk5vIHN5bWJvbCAic2xhYiIgaW4gY3VycmVudCBjb250ZXh0 Lg0KKGtnZGIpIHAgc2xhYi0+dXNfa2VnIAggCAggCAggCAggCAggCAggCAggCAggCAggCAggCAgg CAggCAggCAggCAggCAdwIHNpemUICAgICAhsG1tLCHAgc2l6ZQggCAggCAggCAggCHNsYWINCk5v IHN5bWJvbCAic2xhYiIgaW4gY3VycmVudCBjb250ZXh0Lg0KKGtnZGIpIGJ0DQojMCAgZG9hZHVt cCAodGV4dGR1bXA9PHZhbHVlIG9wdGltaXplZCBvdXQ+KSBhdCBwY3B1Lmg6MjM0DQojMSAgMHhm ZmZmZmZmZjgwNDk3NTU0IGluIGtlcm5fcmVib290IChob3d0bz0yNjApDQogICAgYXQgL3Vzci9z cmMvc3lzL2tlcm4va2Vybl9zaHV0ZG93bi5jOjQ0OQ0KIzIgIDB4ZmZmZmZmZmY4MDQ5NzljZiBp biBwYW5pYyAoZm10PTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PikNCiAgICBhdCAvdXNyL3NyYy9zeXMv a2Vybi9rZXJuX3NodXRkb3duLmM6NjM3DQojMyAgMHhmZmZmZmZmZjgwNjllM2RhIGluIHRyYXBf ZmF0YWwgKGZyYW1lPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PiwgDQogICAgZXZhPTx2YWx1ZSBvcHRp bWl6ZWQgb3V0PikgYXQgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L3RyYXAuYzo4NzkNCiM0ICAw eGZmZmZmZmZmODA2OWU2NGIgaW4gdHJhcF9wZmF1bHQgKGZyYW1lPTB4MCwgdXNlcm1vZGU9MCkN CiAgICBhdCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvdHJhcC5jOjcwMA0KIzUgIDB4ZmZmZmZm ZmY4MDY5ZGQ3NCBpbiB0cmFwIChmcmFtZT0weGZmZmZmZjgwMDAyNGU3MjApDQogICAgYXQgL3Vz ci9zcmMvc3lzL2FtZDY0L2FtZDY0L3RyYXAuYzo0NjMNCiM2ICAweGZmZmZmZmZmODA2ODg1NDMg aW4gY2FsbHRyYXAgKCkNCiAgICBhdCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvZXhjZXB0aW9u LlM6MjMyDQojNyAgMHhmZmZmZmZmZjgwNDgyYTA1IGluIGZyZWUgKGFkZHI9MHhmZmZmZmUwMDA1 YzgyMDAwLCANCiAgICBtdHA9MHhmZmZmZmZmZjgwOWViMTcwKSBhdCAvdXNyL3NyYy9zeXMva2Vy bi9rZXJuX21hbGxvYy5jOjU1MQ0KIzggIDB4ZmZmZmZmZmY4MDQ2ODkzYiBpbiBwcm9jX3JlYXAg KHRkPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PiwgDQogICAgcD0weGZmZmZmZTAwMDU5NDM0YTgsIHN0 YXR1cz08dmFsdWUgb3B0aW1pemVkIG91dD4sIA0KICAgIG9wdGlvbnM9PHZhbHVlIG9wdGltaXpl ZCBvdXQ+KSBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2V4aXQuYzo4NTQNCiM5ICAweGZmZmZm ZmZmODA0NjhkNTEgaW4gcHJvY190b19yZWFwICh0ZD0weGZmZmZmZTAwMDE5NGY5MjAsIA0KICAg IHA9MHhmZmZmZmUwMDA1OTQzNGE4LCBpZHR5cGU9PHZhbHVlIG9wdGltaXplZCBvdXQ+LCANCiAg ICBpZD08dmFsdWUgb3B0aW1pemVkIG91dD4sIHN0YXR1cz0weGZmZmZmZjgwMDAyNGU5NTQsIG9w dGlvbnM9NDgsIA0KICAgIHdydXNhZ2U9PHZhbHVlIG9wdGltaXplZCBvdXQ+LCBzaWdpbmZvPTx2 YWx1ZSBvcHRpbWl6ZWQgb3V0PikNCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2V4aXQu YzoxMDE3DQotLS1UeXBlIDxyZXR1cm4+IHRvIGNvbnRpbnVlLCBvciBxIDxyZXR1cm4+IHRvIHF1 aXQtLS1xcQggCAggCHENClF1aXQNCihrZ2RiKSBmIDcNCiM3ICAweGZmZmZmZmZmODA0ODJhMDUg aW4gZnJlZSAoYWRkcj0weGZmZmZmZTAwMDVjODIwMDAsIA0KICAgIG10cD0weGZmZmZmZmZmODA5 ZWIxNzApIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fbWFsbG9jLmM6NTUxDQo1NTEJCQlzaXpl ID0gc2xhYi0+dXNfa2VnLT51a19zaXplOw0KKGtnZGIpIGJ0IGZ1bGwNCiMwICBkb2FkdW1wICh0 ZXh0ZHVtcD08dmFsdWUgb3B0aW1pemVkIG91dD4pIGF0IHBjcHUuaDoyMzQNCk5vIGxvY2Fscy4N CiMxICAweGZmZmZmZmZmODA0OTc1NTQgaW4ga2Vybl9yZWJvb3QgKGhvd3RvPTI2MCkNCiAgICBh dCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NodXRkb3duLmM6NDQ5DQpObyBsb2NhbHMuDQojMiAg MHhmZmZmZmZmZjgwNDk3OWNmIGluIHBhbmljIChmbXQ9PHZhbHVlIG9wdGltaXplZCBvdXQ+KQ0K ICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2h1dGRvd24uYzo2MzcNCglwYW5pY19jcHUg PSAwDQoJYnVmID0gInBhZ2UgZmF1bHQiLCAnXDAnIDxyZXBlYXRzIDI0NSB0aW1lcz4NCglhcCA9 IHt7Z3Bfb2Zmc2V0ID0gMTYsIGZwX29mZnNldCA9IDQ4LCANCiAgICBvdmVyZmxvd19hcmdfYXJl YSA9IDB4ZmZmZmZmODAwMDI0ZTRjMCwgDQogICAgcmVnX3NhdmVfYXJlYSA9IDB4ZmZmZmZmODAw MDI0ZTQ0MH19DQoJdGQgPSA8dmFsdWUgb3B0aW1pemVkIG91dD4NCgluZXdwYW5pYyA9IDx2YWx1 ZSBvcHRpbWl6ZWQgb3V0Pg0KCWJvb3RvcHQgPSA8dmFsdWUgb3B0aW1pemVkIG91dD4NCiMzICAw eGZmZmZmZmZmODA2OWUzZGEgaW4gdHJhcF9mYXRhbCAoZnJhbWU9PHZhbHVlIG9wdGltaXplZCBv dXQ+LCANCiAgICBldmE9PHZhbHVlIG9wdGltaXplZCBvdXQ+KSBhdCAvdXNyL3NyYy9zeXMvYW1k NjQvYW1kNjQvdHJhcC5jOjg3OQ0KCXNvZnRzZWcgPSB7c3NkX2Jhc2UgPSAwLCBzc2RfbGltaXQg PSAxMDQ4NTc1LCBzc2RfdHlwZSA9IDI3LCANCiAgc3NkX2RwbCA9IDAsIHNzZF9wID0gMSwgc3Nk X2xvbmcgPSAxLCBzc2RfZGVmMzIgPSAwLCBzc2RfZ3JhbiA9IDF9DQojNCAgMHhmZmZmZmZmZjgw NjllNjRiIGluIHRyYXBfcGZhdWx0IChmcmFtZT0weDAsIHVzZXJtb2RlPTApDQogICAgYXQgL3Vz ci9zcmMvc3lzL2FtZDY0L2FtZDY0L3RyYXAuYzo3MDANCglydiA9IENhbm5vdCBhY2Nlc3MgbWVt b3J5IGF0IGFkZHJlc3MgMHgwDQooa2dkYikgZiA3DQojNyAgMHhmZmZmZmZmZjgwNDgyYTA1IGlu IGZyZWUgKGFkZHI9MHhmZmZmZmUwMDA1YzgyMDAwLCANCiAgICBtdHA9MHhmZmZmZmZmZjgwOWVi MTcwKSBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX21hbGxvYy5jOjU1MQ0KNTUxCQkJc2l6ZSA9 IHNsYWItPnVzX2tlZy0+dWtfc2l6ZTsNCihrZ2RiKSBpbmZvIGxvY2Fscw0Kc2l6ZSA9IDx2YWx1 ZSBvcHRpbWl6ZWQgb3V0Pg0KKGtnZGIpIGYgOA0KIzggIDB4ZmZmZmZmZmY4MDQ2ODkzYiBpbiBw cm9jX3JlYXAgKHRkPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PiwgDQogICAgcD0weGZmZmZmZTAwMDU5 NDM0YTgsIHN0YXR1cz08dmFsdWUgb3B0aW1pemVkIG91dD4sIA0KICAgIG9wdGlvbnM9PHZhbHVl IG9wdGltaXplZCBvdXQ+KSBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2V4aXQuYzo4NTQNCjg1 NAkJc2lnYWN0c19mcmVlKHAtPnBfc2lnYWN0cyk7DQooa2dkYikgaW5mbyBsb2NhbHMNCnEgPSA8 dmFsdWUgb3B0aW1pemVkIG91dD4NCnQgPSA8dmFsdWUgb3B0aW1pemVkIG91dD4NCihrZ2RiKSBm IDkNCiM5ICAweGZmZmZmZmZmODA0NjhkNTEgaW4gcHJvY190b19yZWFwICh0ZD0weGZmZmZmZTAw MDE5NGY5MjAsIA0KICAgIHA9MHhmZmZmZmUwMDA1OTQzNGE4LCBpZHR5cGU9PHZhbHVlIG9wdGlt aXplZCBvdXQ+LCANCiAgICBpZD08dmFsdWUgb3B0aW1pemVkIG91dD4sIHN0YXR1cz0weGZmZmZm ZjgwMDAyNGU5NTQsIG9wdGlvbnM9NDgsIA0KICAgIHdydXNhZ2U9PHZhbHVlIG9wdGltaXplZCBv dXQ+LCBzaWdpbmZvPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PikNCiAgICBhdCAvdXNyL3NyYy9zeXMv a2Vybi9rZXJuX2V4aXQuYzoxMDE3DQoxMDE3CQkJcHJvY19yZWFwKHRkLCBwLCBzdGF0dXMsIG9w dGlvbnMpOw0KKGtnZGIpIGluZiAIIAhvIGxvY2Fscw0KX3RpZCA9IDx2YWx1ZSBvcHRpbWl6ZWQg b3V0Pg0KcnVwID0gPHZhbHVlIG9wdGltaXplZCBvdXQ+DQooa2dkYikgcQ0KG1sxbXJvb3QbW21A G1s0bXBhbmRvcmEtZBtbMjRtIH4jIF5ECAhleGl0DQoKU2NyaXB0IGRvbmUgb24gU3VuIFNlcCAg OCAyMTowNjoxOCAyMDEzCg== --e89a8ff1bf9a6a4d5d04e5e47224-- From owner-freebsd-stable@FreeBSD.ORG Sun Sep 8 21:40:02 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F02BAFF1; Sun, 8 Sep 2013 21:40:02 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AEB8922FB; Sun, 8 Sep 2013 21:40:02 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id h1so5770671oag.24 for ; Sun, 08 Sep 2013 14:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wZ2vU7jqk/i7dE0q5i9B3epg6ZmgioRd+mYfxD/zgTU=; b=bvr6CypU+NQUi5Fba/d3akgT6twvYS0Shq6ktNusYAJep6ozn+8D0UXkJCnLZD2dK+ +WqENCip4Ot46JxFbNfIiQdi2OzTwDwGVjIJ//Ey0YQciH57ClMgzZ3mGWr88OqWNdjm 774tGtsJN9R4CPPME11ZrePR1l5brp60wg7uJUHTHgvOgBnq3rVhh5PY8aEtXrD7zE71 uPFyWUstEBpoa9MlnPLRNKRS78tQ30ob0AnTYRcPxMIXa5egoObL0EKwnpfFyAn5tOI+ y3wAiwal/qCJfyJlfxuQsf1xR4xoislLBE/LShiQkwmlH1cH+rAaFcNAQ/KaeGx7s8Hb pusw== MIME-Version: 1.0 X-Received: by 10.182.74.195 with SMTP id w3mr9267436obv.45.1378676401933; Sun, 08 Sep 2013 14:40:01 -0700 (PDT) Received: by 10.182.22.161 with HTTP; Sun, 8 Sep 2013 14:40:01 -0700 (PDT) In-Reply-To: References: Date: Sun, 8 Sep 2013 23:40:01 +0200 Message-ID: Subject: Re: 9.2-STABLE: supervisor read data, page not present From: Oliver Pinter To: stable@freebsd.org Content-Type: multipart/mixed; boundary=089e01634b1e3291fc04e5e61d07 Cc: kib@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Sep 2013 21:40:03 -0000 --089e01634b1e3291fc04e5e61d07 Content-Type: text/plain; charset=ISO-8859-1 On 9/8/13, Oliver Pinter wrote: > Hi! > > I got this panic on recent 9-STABLE (amd64): > > 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: > <118>Sep 8 20:22:34 pandora-d syslogd: exiting on signal 15 > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x78 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80482a05 > stack pointer = 0x28:0xffffff800024e7d0 > frame pointer = 0x28:0xffffff800024e800 > 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 = 1 (init) > trap number = 12 > panic: page fault > cpuid = 0 > KDB: stack backtrace: > #0 0xffffffff804cd660 at kdb_backtrace+0x60 > #1 0xffffffff8049797e at panic+0x1fe > #2 0xffffffff8069e3da at trap_fatal+0x37a > #3 0xffffffff8069e64b at trap_pfault+0x25b > #4 0xffffffff8069dd74 at trap+0x454 > #5 0xffffffff80688543 at calltrap+0x8 > #6 0xffffffff8046893b at proc_reap+0x4bb > #7 0xffffffff80468d51 at proc_to_reap+0x361 > #8 0xffffffff80467ddb at kern_wait6+0x22b > #9 0xffffffff804679b6 at sys_wait4+0x76 > #10 0xffffffff8069eb9d at amd64_syscall+0x29d > #11 0xffffffff8068882b at Xfast_syscall+0xfb > Uptime: 34m20s > Dumping 367 out of 4084 > MB:..5%..14%..22%..31%..44%..53%..62%..75%..83%..92% > > This is fully reproducible. > > The HEAD stay on : > > commit aba57138f98f1a98e4b7c7c61511daefb0542524 > Author: des > Date: Sun Sep 8 10:04:26 2013 +0000 > > Make libldns and libssh private. > > Approved by: re (blanket) > > Notes: > svn path=/head/; revision=255386 > > The panic first appeared on likely between august 8 and 17. > > When you need more info, the ping me. > after recompiling the kernel with INVARIANTS: zone: 4096(0xfffffe00cff68380) slab 0xfffffe00059af470 freed address 0xfffffe00059b2010 unaligned. panic: should be 0xfffffe00059b2000 cpuid = 0 KDB: stack backtrace: #0 0xffffffff804c7790 at kdb_backtrace+0x60 #1 0xffffffff80494c8e at panic+0x1fe #2 0xffffffff8066062c at uma_dbg_free+0x10c #3 0xffffffff8065dbe5 at uma_zfree_arg+0x75 #4 0xffffffff8047f1f7 at free+0x97 #5 0xffffffff806a2ab3 at cpuctl_ioctl+0x4b3 #6 0xffffffff80401640 at devfs_ioctl_f+0xf0 #7 0xffffffff804db190 at kern_ioctl+0x1b0 #8 0xffffffff804daf92 at sys_ioctl+0x142 #9 0xffffffff806989c1 at amd64_syscall+0x211 #10 0xffffffff80681ecb at Xfast_syscall+0xfb Uptime: 28s Dumping 264 out of 4084 MB:..7%..13%..25%..31%..43%..55%..61%..73%..85%..91% --089e01634b1e3291fc04e5e61d07 Content-Type: text/plain; name="kernel-with-invariants.txt" Content-Disposition: attachment; filename="kernel-with-invariants.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: file0 U2NyaXB0IHN0YXJ0ZWQgb24gU3VuIFNlcCAgOCAyMzozMToyNSAyMDEzChtbMW1yb290G1ttQBtb NG1wYW5kb3JhLWQbWzI0bSB+IyBrZ2RiIC9ib290L2tlcg0NCmtlcm5lbC5vbGQvIGtlcm5lbC8g ICAgIA0NChtbMW1yb290G1ttQBtbNG1wYW5kb3JhLWQbWzI0bSB+IyBrZ2RiIC9ib290L2tlcm5l bA0NCmtlcm5lbC5vbGQvIGtlcm5lbC8gICAgIA0NChtbMW1yb290G1ttQBtbNG1wYW5kb3JhLWQb WzI0bSB+IyBrZ2RiIC9ib290L2tlcm5lbC9rZXINDQprZXJuZWwqICAgICAgICAga2VybmVsLnN5 bWJvbHMqIA0NChtbMW1yb290G1ttQBtbNG1wYW5kb3JhLWQbWzI0bSB+IyBrZ2RiIC9ib290L2tl cm5lbC9rZXJuZWwgL3Zhci9jcmFzaC92bWNvDQ0Kdm1jb3JlLjAgIHZtY29yZS4xICB2bWNvcmUu MiAgdm1jb3JlLjMgIHZtY29yZS40ICB2bWNvcmUuNSAgDQ0KG1sxbXJvb3QbW21AG1s0bXBhbmRv cmEtZBtbMjRtIH4jIGtnZGIgL2Jvb3Qva2VybmVsL2tlcm5lbCAvdmFyL2NyYXNoL3ZtY29yZS40 IA0NCkdOVSBnZGIgNi4xLjEgW0ZyZWVCU0RdDQpDb3B5cmlnaHQgMjAwNCBGcmVlIFNvZnR3YXJl IEZvdW5kYXRpb24sIEluYy4NCkdEQiBpcyBmcmVlIHNvZnR3YXJlLCBjb3ZlcmVkIGJ5IHRoZSBH TlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSwgYW5kIHlvdSBhcmUNCndlbGNvbWUgdG8gY2hhbmdl IGl0IGFuZC9vciBkaXN0cmlidXRlIGNvcGllcyBvZiBpdCB1bmRlciBjZXJ0YWluIGNvbmRpdGlv bnMuDQpUeXBlICJzaG93IGNvcHlpbmciIHRvIHNlZSB0aGUgY29uZGl0aW9ucy4NClRoZXJlIGlz IGFic29sdXRlbHkgbm8gd2FycmFudHkgZm9yIEdEQi4gIFR5cGUgInNob3cgd2FycmFudHkiIGZv ciBkZXRhaWxzLg0KVGhpcyBHREIgd2FzIGNvbmZpZ3VyZWQgYXMgImFtZDY0LW1hcmNlbC1mcmVl YnNkIi4uLg0KDQpVbnJlYWQgcG9ydGlvbiBvZiB0aGUga2VybmVsIG1lc3NhZ2UgYnVmZmVyOg0K PDExOD5uZ2lueDogY29uZmlndXJhdGlvbiBmaWxlIC91c3IvbG9jYWwvZXRjL25naW54L25naW54 LmNvbmYgdGVzdCBpcyBzdWNjZXNzZnVsDQo8MTE4PlN0YXJ0aW5nIG5naW54Lg0KPDExOD5VcGRh dGluZyBjcHVjb2Rlcy4uLg0KPDExOD4vdXNyL2xvY2FsL3NoYXJlL2NwdWNvbnRyb2wvbTEwMTA2 Nzc3MEEuZnc6IHVwZGF0aW5nIGNwdSAvZGV2L2NwdWN0bDAgZnJvbSByZXYgMHg3MDUgdG8gcmV2 IDB4NzBhLi4uIA0Kem9uZTogNDA5NigweGZmZmZmZTAwY2ZmNjgzODApIHNsYWIgMHhmZmZmZmUw MDA1OWFmNDcwIGZyZWVkIGFkZHJlc3MgMHhmZmZmZmUwMDA1OWIyMDEwIHVuYWxpZ25lZC4NCnBh bmljOiBzaG91bGQgYmUgMHhmZmZmZmUwMDA1OWIyMDAwDQoNCmNwdWlkID0gMA0KS0RCOiBzdGFj ayBiYWNrdHJhY2U6DQojMCAweGZmZmZmZmZmODA0Yzc3OTAgYXQga2RiX2JhY2t0cmFjZSsweDYw DQojMSAweGZmZmZmZmZmODA0OTRjOGUgYXQgcGFuaWMrMHgxZmUNCiMyIDB4ZmZmZmZmZmY4MDY2 MDYyYyBhdCB1bWFfZGJnX2ZyZWUrMHgxMGMNCiMzIDB4ZmZmZmZmZmY4MDY1ZGJlNSBhdCB1bWFf emZyZWVfYXJnKzB4NzUNCiM0IDB4ZmZmZmZmZmY4MDQ3ZjFmNyBhdCBmcmVlKzB4OTcNCiM1IDB4 ZmZmZmZmZmY4MDZhMmFiMyBhdCBjcHVjdGxfaW9jdGwrMHg0YjMNCiM2IDB4ZmZmZmZmZmY4MDQw MTY0MCBhdCBkZXZmc19pb2N0bF9mKzB4ZjANCiM3IDB4ZmZmZmZmZmY4MDRkYjE5MCBhdCBrZXJu X2lvY3RsKzB4MWIwDQojOCAweGZmZmZmZmZmODA0ZGFmOTIgYXQgc3lzX2lvY3RsKzB4MTQyDQoj OSAweGZmZmZmZmZmODA2OTg5YzEgYXQgYW1kNjRfc3lzY2FsbCsweDIxMQ0KIzEwIDB4ZmZmZmZm ZmY4MDY4MWVjYiBhdCBYZmFzdF9zeXNjYWxsKzB4ZmINClVwdGltZTogMjhzDQpEdW1waW5nIDI2 NCBvdXQgb2YgNDA4NCBNQjouLjclLi4xMyUuLjI1JS4uMzElLi40MyUuLjU1JS4uNjElLi43MyUu Ljg1JS4uOTElDQoNClJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9saW51eC5rby4u LlJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9saW51eC5rby5zeW1ib2xzLi4uZG9u ZS4NCmRvbmUuDQpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL2xpbnV4LmtvDQpSZWFk aW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvZ2VvbV9zY2hlZC5rby4uLlJlYWRpbmcgc3lt Ym9scyBmcm9tIC9ib290L2tlcm5lbC9nZW9tX3NjaGVkLmtvLnN5bWJvbHMuLi5kb25lLg0KZG9u ZS4NCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvZ2VvbV9zY2hlZC5rbw0KUmVhZGlu ZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2dzY2hlZF9yci5rby4uLlJlYWRpbmcgc3ltYm9s cyBmcm9tIC9ib290L2tlcm5lbC9nc2NoZWRfcnIua28uc3ltYm9scy4uLmRvbmUuDQpkb25lLg0K TG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L2tlcm5lbC9nc2NoZWRfcnIua28NCiMwICBkb2FkdW1w ICh0ZXh0ZHVtcD08dmFsdWUgb3B0aW1pemVkIG91dD4pIGF0IHBjcHUuaDoyMzQNCjIzNAlwY3B1 Lmg6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkuDQoJaW4gcGNwdS5oDQooa2dkYikgYnQgZHUI IAgIIAhmdWxsDQojMCAgZG9hZHVtcCAodGV4dGR1bXA9PHZhbHVlIG9wdGltaXplZCBvdXQ+KSBh dCBwY3B1Lmg6MjM0DQpObyBsb2NhbHMuDQojMSAgMHhmZmZmZmZmZjgwNDk0ODgwIGluIGtlcm5f cmVib290IChob3d0bz0yNjApDQogICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaHV0ZG93 bi5jOjQ0OQ0KCV9lbCA9IDx2YWx1ZSBvcHRpbWl6ZWQgb3V0Pg0KIzIgIDB4ZmZmZmZmZmY4MDQ5 NGNkZiBpbiBwYW5pYyAoZm10PTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PikNCiAgICBhdCAvdXNyL3Ny Yy9zeXMva2Vybi9rZXJuX3NodXRkb3duLmM6NjM3DQoJcGFuaWNfY3B1ID0gMA0KCWJ1ZiA9ICJz aG91bGQgYmUgMHhmZmZmZmUwMDA1OWIyMDAwXG4iLCAnXDAnIDxyZXBlYXRzIDIyNiB0aW1lcz4N CglhcCA9IHt7Z3Bfb2Zmc2V0ID0gMTYsIGZwX29mZnNldCA9IDQ4LCANCiAgICBvdmVyZmxvd19h cmdfYXJlYSA9IDB4ZmZmZmZmODEyZWRiNzhjMCwgDQogICAgcmVnX3NhdmVfYXJlYSA9IDB4ZmZm ZmZmODEyZWRiNzg0MH19DQoJdGQgPSA8dmFsdWUgb3B0aW1pemVkIG91dD4NCgluZXdwYW5pYyA9 IDx2YWx1ZSBvcHRpbWl6ZWQgb3V0Pg0KCWJvb3RvcHQgPSA8dmFsdWUgb3B0aW1pemVkIG91dD4N CiMzICAweGZmZmZmZmZmODA2NjA2MmMgaW4gdW1hX2RiZ19mcmVlICh6b25lPTB4ZmZmZmZlMDBj ZmY2ODM4MCwgDQogICAgc2xhYj08dmFsdWUgb3B0aW1pemVkIG91dD4sIGl0ZW09MHhmZmZmZmUw MDA1OWIyMDEwKQ0KICAgIGF0IC91c3Ivc3JjL3N5cy92bS91bWFfZGJnLmM6Mjc5DQoJa2VnID0g PHZhbHVlIG9wdGltaXplZCBvdXQ+DQoJZnJlZWkgPSAwDQojNCAgMHhmZmZmZmZmZjgwNjVkYmU1 IGluIHVtYV96ZnJlZV9hcmcgKHpvbmU9MHhmZmZmZmUwMGNmZjY4MzgwLCANCiAgICBpdGVtPTB4 ZmZmZmZlMDAwNTliMjAxMCwgdWRhdGE9MHhmZmZmZmUwMDA1OWFmNDcwKQ0KICAgIGF0IC91c3Iv c3JjL3N5cy92bS91bWFfY29yZS5jOjI1NTcNCi0tLVR5cGUgPHJldHVybj4gdG8gY29udGludWUs IG9yIHEgPHJldHVybj4gdG8gcXVpdC0tLQ0KCWNhY2hlID0gPHZhbHVlIG9wdGltaXplZCBvdXQ+ DQoJYnVja2V0ID0gPHZhbHVlIG9wdGltaXplZCBvdXQ+DQojNSAgMHhmZmZmZmZmZjgwNDdmMWY3 IGluIGZyZWUgKGFkZHI9PHZhbHVlIG9wdGltaXplZCBvdXQ+LCANCiAgICBtdHA9MHhmZmZmZmZm ZjgwYTIyMWIwKSBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX21hbGxvYy5jOjU2Nw0KCW10cHAg PSA8dmFsdWUgb3B0aW1pemVkIG91dD4NCglzaXplID0gPHZhbHVlIG9wdGltaXplZCBvdXQ+DQoj NiAgMHhmZmZmZmZmZjgwNmEyYWIzIGluIGNwdWN0bF9pb2N0bCAoZGV2PTx2YWx1ZSBvcHRpbWl6 ZWQgb3V0PiwgDQogICAgY21kPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PiwgZGF0YT08dmFsdWUgb3B0 aW1pemVkIG91dD4sIGZsYWdzPTAsIA0KICAgIHRkPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PikgYXQg L3Vzci9zcmMvc3lzL2Rldi9jcHVjdGwvY3B1Y3RsLmM6NDc4DQoJY3B1ID0gPHZhbHVlIG9wdGlt aXplZCBvdXQ+DQoJcmV0ID0gPHZhbHVlIG9wdGltaXplZCBvdXQ+DQojNyAgMHhmZmZmZmZmZjgw NDAxNjQwIGluIGRldmZzX2lvY3RsX2YgKGZwPTB4ZmZmZmZlMDAwNWFlMzM3MCwgDQogICAgY29t PTMyMjIyOTkzOTYsIGRhdGE9MHhmZmZmZmUwMDA1OWU2ODMwLCBjcmVkPTx2YWx1ZSBvcHRpbWl6 ZWQgb3V0PiwgDQogICAgdGQ9MHhmZmZmZmUwMDA1YjRkNDkwKSBhdCAvdXNyL3NyYy9zeXMvZnMv ZGV2ZnMvZGV2ZnNfdm5vcHMuYzo3NTcNCglkZXYgPSAoc3RydWN0IGNkZXYgKikgMHhmZmZmZmUw MDAxOWFjYTAwDQoJZHN3ID0gKHN0cnVjdCBjZGV2c3cgKikgMHhmZmZmZmZmZjgwYTIyMWQwDQoJ cmVmID0gMQ0KCWRldiA9IChzdHJ1Y3QgY2RldiAqKSAweGZmZmZmZTAwMDE5YWNhMDANCglkZXYg PSAoc3RydWN0IGNkZXYgKikgMHhmZmZmZmUwMDAxOWFjYTAwDQoJZHN3ID0gKHN0cnVjdCBjZGV2 c3cgKikgMHhmZmZmZmZmZjgwYTIyMWQwDQoJcmVmID0gMQ0KCWZwb3AgPSAoc3RydWN0IGZpbGUg KikgMHgwDQoJZXJyb3IgPSA8dmFsdWUgb3B0aW1pemVkIG91dD4NCi0tLVR5cGUgPHJldHVybj4g dG8gY29udGludWUsIG9yIHEgPHJldHVybj4gdG8gcXVpdC0tLQ0KCXAgPSA8dmFsdWUgb3B0aW1p emVkIG91dD4NCglpID0gPHZhbHVlIG9wdGltaXplZCBvdXQ+DQoJdnAgPSA8dmFsdWUgb3B0aW1p emVkIG91dD4NCgl2cG9sZCA9IDx2YWx1ZSBvcHRpbWl6ZWQgb3V0Pg0KIzggIDB4ZmZmZmZmZmY4 MDRkYjE5MCBpbiBrZXJuX2lvY3RsICh0ZD0weGZmZmZmZTAwMDViNGQ0OTAsIGZkPTgsIA0KICAg IGNvbT0zMjIyMjk5Mzk2KSBhdCBmaWxlLmg6MzExDQoJZnAgPSAoc3RydWN0IGZpbGUgKikgMHhm ZmZmZmUwMDA1YWUzMzcwDQoJZnAgPSAoc3RydWN0IGZpbGUgKikgMHhmZmZmZmUwMDA1YWUzMzcw DQoJdG1wID0gMg0KCWZwID0gKHN0cnVjdCBmaWxlICopIDB4ZmZmZmZlMDAwNWFlMzM3MA0KCWZw ID0gKHN0cnVjdCBmaWxlICopIDB4ZmZmZmZlMDAwNWFlMzM3MA0KCWZwID0gKHN0cnVjdCBmaWxl ICopIDB4ZmZmZmZlMDAwNWFlMzM3MA0KCWZwID0gKHN0cnVjdCBmaWxlICopIDB4ZmZmZmZlMDAw NWFlMzM3MA0KCWVycm9yID0gPHZhbHVlIG9wdGltaXplZCBvdXQ+DQoJZmRwID0gPHZhbHVlIG9w dGltaXplZCBvdXQ+DQojOSAgMHhmZmZmZmZmZjgwNGRhZjkyIGluIHN5c19pb2N0bCAodGQ9MHhm ZmZmZmUwMDA1YjRkNDkwLCANCiAgICB1YXA9MHhmZmZmZmY4MTJlZGI3YmMwKSBhdCAvdXNyL3Ny Yy9zeXMva2Vybi9zeXNfZ2VuZXJpYy5jOjY5Mg0KCWFyZyA9IC0xDQoJY29tID0gMzIyMjI5OTM5 Ng0KCXNpemUgPSA8dmFsdWUgb3B0aW1pemVkIG91dD4NCgllcnJvciA9IDx2YWx1ZSBvcHRpbWl6 ZWQgb3V0Pg0KIzEwIDB4ZmZmZmZmZmY4MDY5ODljMSBpbiBhbWQ2NF9zeXNjYWxsICh0ZD0weGZm ZmZmZTAwMDViNGQ0OTAsIHRyYWNlZD0wKQ0KICAgIGF0IHN1YnJfc3lzY2FsbC5jOjEzNQ0KLS0t VHlwZSA8cmV0dXJuPiB0byBjb250aW51ZSwgb3IgcSA8cmV0dXJuPiB0byBxdWl0LS0tDQoJc2Eg PSB7Y29kZSA9IDU0LCBjYWxscCA9IDB4ZmZmZmZmZmY4MDllZmM2MCwgYXJncyA9IHs4LCAzMjIy Mjk5Mzk2LCANCiAgICAxNDA3Mzc0ODgzNDQ3OTIsIDQ3ODYzMzk3MDk1MzYyMjAxNDUsIDEsIC0y MTM3MDE1NTY4LCAtNTQ0Njc0NzEwNDgwLCANCiAgICAtMjE0MjQxMTYwOH0sIG5hcmcgPSAzfQ0K CWtzaSA9IHtrc2lfbGluayA9IHt0cWVfbmV4dCA9IDB4ZmZmZmZmODEyZWRiN2I1MCwgDQogICAg dHFlX3ByZXYgPSAweGZmZmZmZmZmODA0OWFlZGZ9LCBrc2lfaW5mbyA9IHtzaV9zaWdubyA9IDc4 NjEzNTk4NCwgDQogICAgc2lfZXJybm8gPSAtMTI3LCBzaV9jb2RlID0gLTIxNDI1NDAyNjQsIHNp X3BpZCA9IC0xLCBzaV91aWQgPSA1MTQsIA0KICAgIHNpX3N0YXR1cyA9IDAsIHNpX2FkZHIgPSAw eDI1ODAsIHNpX3ZhbHVlID0ge3NpdmFsX2ludCA9IC0yMTM2NjAyNjI0LCANCiAgICAgIHNpdmFs X3B0ciA9IDB4ZmZmZmZmZmY4MGE2MDgwMCwgc2lndmFsX2ludCA9IC0yMTM2NjAyNjI0LCANCiAg ICAgIHNpZ3ZhbF9wdHIgPSAweGZmZmZmZmZmODBhNjA4MDB9LCBfcmVhc29uID0ge19mYXVsdCA9 IHtfdHJhcG5vID0gM30sIA0KICAgICAgX3RpbWVyID0ge190aW1lcmlkID0gMywgX292ZXJydW4g PSAwfSwgX21lc2dxID0ge19tcWQgPSAzfSwgX3BvbGwgPSB7DQogICAgICAgIF9iYW5kID0gM30s IF9fc3BhcmVfXyA9IHtfX3NwYXJlMV9fID0gMywgX19zcGFyZTJfXyA9IHs2MzcwNzI5LCA4LCAN CiAgICAgICAgICA5ODMyMDM4NCwgLTUxMiwgMjIsIDAsIDk1NzM2OTc2fX19fSwga3NpX2ZsYWdz ID0gNjU1NDAsIA0KICBrc2lfc2lncSA9IDB4MTAwMDR9DQoJZXJyb3IgPSA8dmFsdWUgb3B0aW1p emVkIG91dD4NCiMxMSAweGZmZmZmZmZmODA2ODFlY2IgaW4gWGZhc3Rfc3lzY2FsbCAoKQ0KICAg IGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC9leGNlcHRpb24uUzozOTENCk5vIGxvY2Fscy4N CiMxMiAweDAwMDAwMDA4MDA5MjRhZWMgaW4gPz8gKCkNCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2 YWlsYWJsZS4NClByZXZpb3VzIGZyYW1lIGlubmVyIHRvIHRoaXMgZnJhbWUgKGNvcnJ1cHQgc3Rh Y2s/KQ0KQ3VycmVudCBsYW5ndWFnZTogIGF1dG87IGN1cnJlbnRseSBtaW5pbWFsDQooa2dkYikg cQ0KG1sxbXJvb3QbW21AG1s0bXBhbmRvcmEtZBtbMjRtIH4jIF5ECAhleGl0DQoKU2NyaXB0IGRv bmUgb24gU3VuIFNlcCAgOCAyMzozMjoyNCAyMDEzCg== --089e01634b1e3291fc04e5e61d07-- From owner-freebsd-stable@FreeBSD.ORG Mon Sep 9 00:17:21 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B1C183B9 for ; Mon, 9 Sep 2013 00:17:21 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 869C928D6 for ; Mon, 9 Sep 2013 00:17:21 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id qd12so1471416ieb.36 for ; Sun, 08 Sep 2013 17:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=4H7t0ht0D/pgJiwTuoFknPXtqjjlugJ7zRAbGSOhwK0=; b=W6SsXthbW+JYj37oxe1kYwNjt+sr8Mg0Sb62ogxcXQLIyQ9ljOKwHLbmqo39TW7ePR XXpsvT3G5fnQDFjM4eZD3RQkGiHo3vaDzAMz6Fm55LAZXeCr3a2TgD6cFvPuxwq4yS6q r+IfB/P2eTwt5/qWWKrZyEl+gyme2FiUyZyl1xUMBA6ymQyWyEleLL4G6KUGgeUqH5iF 6PjCaQcydiaRD//mdLrtIG7U8mcu+WYwYD/+QrZomKGRypl/Ln/BzlasApRdmur2AcsK 53hoU5ku2rNeJcWeK/OlsNqW4JbAN8h9bCWeWe6/oP0aTn3Y70tookyNMo5yLnxWYala xkAg== MIME-Version: 1.0 X-Received: by 10.50.30.103 with SMTP id r7mr6117819igh.35.1378685840986; Sun, 08 Sep 2013 17:17:20 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.43.157.8 with HTTP; Sun, 8 Sep 2013 17:17:20 -0700 (PDT) Date: Sun, 8 Sep 2013 20:17:20 -0400 X-Google-Sender-Auth: qu7-sduB-NuPBMkPVtVe1LEXLdc Message-ID: Subject: Small bug in sys/kern/vfs_mountroot.c From: J David To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Sep 2013 00:17:21 -0000 In releng/9.2 (and possibly other versions), in kern/vfs_mountroot.c, in parse_mount, there appears to be a small bug. The expression sizeof(errmsg) is used in a strlcpy. This would work if errmsg were an array, but it's a char*, so sizeof() returns the pointer's size and this limits the error message to seven characters + NULL (on amd64), translating "unknown file system" into the moderately less helpful "unknown." A "patch" is below. (It's a tiny fix.) Index: vfs_mountroot.c =================================================================== --- vfs_mountroot.c (revision 255409) +++ vfs_mountroot.c (working copy) @@ -709,7 +709,7 @@ errmsg = malloc(ERRMSGL, M_TEMP, M_WAITOK | M_ZERO); if (vfs_byname(fs) == NULL) { - strlcpy(errmsg, "unknown file system", sizeof(errmsg)); + strlcpy(errmsg, "unknown file system", ERRMSGL); error = ENOENT; goto out; } From owner-freebsd-stable@FreeBSD.ORG Mon Sep 9 01:02:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CF79A9B4; Mon, 9 Sep 2013 01:02:04 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9AA1B2A86; Mon, 9 Sep 2013 01:02:04 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id tp5so11633801ieb.0 for ; Sun, 08 Sep 2013 18:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=QeEcWjU1DUYd2OwVU+RYtFoMui1dzh2RgLqjU2eQKAw=; b=Pfo5HzJOGzDw2p4L8U8ycqduj/yiguBKoM24kj7MdUL8cpxO2IcunqhQb1OTXgt35y TCd1hNnurQ7gfCywsR5HF3CRBcVXHVicMyC+F97XxG6GIyZNCetpvttgKUPMajf8zscc jJXUhyjwc2w4Z1GDuydh1RbQzpp5Ycz3+k02OESd6UuuKd93uSJp1vOfOyEcClsfIhNF 9F1FyaeZXOoE3IISXtoB5eiKM4Qu4X6Qtt5Sw05D8QtTJ1VsJ1K/S0S5/4B2FgWKYSXp 4BYh4XEyQaGJ45azdPKqQIlj79mnIh7TgvrxLEumy4hNBCtZhsEgqRfdBHKhCWeOgPb1 ckeQ== MIME-Version: 1.0 X-Received: by 10.50.72.33 with SMTP id a1mr6188153igv.58.1378688524108; Sun, 08 Sep 2013 18:02:04 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.43.157.8 with HTTP; Sun, 8 Sep 2013 18:02:04 -0700 (PDT) Date: Sun, 8 Sep 2013 21:02:04 -0400 X-Google-Sender-Auth: 8IW3EzEXL7LGf4QY3M3-LAIqu-k Message-ID: Subject: zfs_enable vs zfs_load in loader.conf (but neither works) From: J David To: "freebsd-fs@freebsd.org" , freebsd-stable Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Sep 2013 01:02:04 -0000 After setting up a new machine to boot from a ZFS root using the 9.1 install, it worked fine, but when the kernel & world was updated to releng/9.2, it stopped booting. The pool is called "data" and the root partition is "data/root." Under 9.1 it had in loader.conf: zfs_load=3D"YES" vfs.root.mountfrom=3D"zfs:data/root" Under 9.2-RC3, the same config results in a panic: Trying to mount root from zfs:data/root []=85 init: not found in path /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/sysinstall panic: no init If this is changed (as many Google hits recommend) to: zfs_enable=3D"YES" vfs.root.mountfrom=3D"zfs:data/root" It seems like ZFS doesn't get loaded, so it fails instead with: Trying to mount root from zfs:data/root []=85 Mounting from zfs:data/root failed with error 2: unknown file system. If the "?" mountroot> option is used, 50 devices are listed, none of which are ZFS. And the "unknown file system" response comes from vfs_byname returning NULL for zfs. (If both zfs_enable and zfs_load are set to "YES" then it fails as the zfs_load case.) The system is using update-to-date zpool (v5000 / feature flags), and all the updated bootblocks from the releng/9.2 build. zpool.cache is correct, the zpool imports fine from the 9.2-RC3 live cd. The zpool's bootfs is set correctly, the zfs mountpoint of data/root is / . And, of course, init is present and health in data/root. The system booted fine until updating to 9.2. Which loader.conf entry is actually correct for ZFS roots on 9.2, and what (else) needs to happen to make this system bootable again? Thanks for any advice! From owner-freebsd-stable@FreeBSD.ORG Mon Sep 9 02:22:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A40515DA; Mon, 9 Sep 2013 02:22:13 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from yoshi.bluerosetech.com (yoshi.bluerosetech.com [174.136.100.66]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B5E52DC2; Mon, 9 Sep 2013 02:22:13 +0000 (UTC) Received: from chombo.houseloki.net (unknown [IPv6:2001:558:6025:2d:68f0:67e3:f35d:f840]) by yoshi.bluerosetech.com (Postfix) with ESMTPSA id 6F638E6040; Sun, 8 Sep 2013 19:22:10 -0700 (PDT) Received: from [127.0.0.1] (ivy.houseloki.net [10.9.70.20]) by chombo.houseloki.net (Postfix) with ESMTPSA id 7FB5B24F; Sun, 8 Sep 2013 19:22:06 -0700 (PDT) Message-ID: <522D30C9.8000203@bluerosetech.com> Date: Sun, 08 Sep 2013 19:22:01 -0700 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: J David Subject: Re: zfs_enable vs zfs_load in loader.conf (but neither works) References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-fs@freebsd.org" , freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Sep 2013 02:22:13 -0000 On 9/8/2013 6:02 PM, J David wrote: > Trying to mount root from zfs:data/root []… > Mounting from zfs:data/root failed with error 2: unknown file system. Did you build and install new boot blocks? From owner-freebsd-stable@FreeBSD.ORG Mon Sep 9 02:52:18 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 658E6C54; Mon, 9 Sep 2013 02:52:18 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2CE772EF2; Mon, 9 Sep 2013 02:52:18 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id 16so534038iea.30 for ; Sun, 08 Sep 2013 19:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Ubc+d7Q158p8jgVQoQu1+26i6YuTLPzOdvHah/mQ5yw=; b=tU/Boi3m8nMN811Zdki5UnIW13jivM4bd/se7QINvuXb6s+DsVUdG6a32FvKAroRAV wZDupKacSMQNjgj72EjXbvBFPO20cdjuZS3Uyqmqlct6drqLn/bUdRMzJ12m8/I9ynWw Y9andEspDvA7z6FCuIgVuouVeVTESPxCuD9YhvSMeH8sQ5GlTP1IcEraA7/Yycp8summ zKiJ2PMW7CNb+wWyJ5HRKObdqw4CsDu0YsWqCCP4PZ2/RL4LVjRf8SPH2MwwqeJZIWqw SZ3VOPFo4L0X3OZANP9SQSJT6LvyVm0JMUAC+Om/wpa61pS+0OW+CoiEl/UZbuycjYXd N4KA== MIME-Version: 1.0 X-Received: by 10.50.120.6 with SMTP id ky6mr6384038igb.58.1378695137747; Sun, 08 Sep 2013 19:52:17 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.43.157.8 with HTTP; Sun, 8 Sep 2013 19:52:17 -0700 (PDT) In-Reply-To: <522D30C9.8000203@bluerosetech.com> References: <522D30C9.8000203@bluerosetech.com> Date: Sun, 8 Sep 2013 22:52:17 -0400 X-Google-Sender-Auth: fz4Zs4VkyQJ2IEp3cv5bWXWjEX4 Message-ID: Subject: Re: zfs_enable vs zfs_load in loader.conf (but neither works) From: J David To: Darren Pilgrim Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-fs@freebsd.org" , freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Sep 2013 02:52:18 -0000 On Sun, Sep 8, 2013 at 10:22 PM, Darren Pilgrim wrote: > Did you build and install new boot blocks? Yes. Oddly, setting: zfs set mountpoint=legacy data/root (plus the appropriate fstab entry) instead of zfs set mountpoint=/ data/root seems to produce a bootable system, although it absolutely should not be necessary to do things that way anymore. Weird. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 9 03:11:57 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7DF54152; Mon, 9 Sep 2013 03:11:57 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from yoshi.bluerosetech.com (yoshi.bluerosetech.com [IPv6:2607:f2f8:a450::66]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 64B232086; Mon, 9 Sep 2013 03:11:57 +0000 (UTC) Received: from chombo.houseloki.net (unknown [IPv6:2001:558:6025:2d:68f0:67e3:f35d:f840]) by yoshi.bluerosetech.com (Postfix) with ESMTPSA id A9D07E6040; Sun, 8 Sep 2013 20:11:53 -0700 (PDT) Received: from [127.0.0.1] (ivy.houseloki.net [10.9.70.20]) by chombo.houseloki.net (Postfix) with ESMTPSA id 78539256; Sun, 8 Sep 2013 20:11:52 -0700 (PDT) Message-ID: <522D3C76.1030705@bluerosetech.com> Date: Sun, 08 Sep 2013 20:11:50 -0700 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: J David Subject: Re: zfs_enable vs zfs_load in loader.conf (but neither works) References: <522D30C9.8000203@bluerosetech.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@freebsd.org" , freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Sep 2013 03:11:57 -0000 On 9/8/2013 7:52 PM, J David wrote: > On Sun, Sep 8, 2013 at 10:22 PM, Darren Pilgrim > wrote: >> Did you build and install new boot blocks? > > Yes. > > Oddly, setting: > > zfs set mountpoint=legacy data/root (plus the appropriate fstab entry) You can use zfs.root.mountfrom="zfs:data/root" in /boot/loader.conf instead of an fstab entry. Mountpoint=legacy is required either way. > instead of > > zfs set mountpoint=/ data/root This only applies to Solaris, IIRC. > seems to produce a bootable system, although it absolutely should not > be necessary to do things that way anymore. I ran into that problem as well. The instructions for root-on-zfs for 9.x (at least as of 9.1) are wrong--you need to use the 8.x-style instructions with mountpoint=legacy for / and, for fresh installs, leaving the pool imported and copying over /boot/zfs/zpool.cache. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 9 05:14:49 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7D820EC1 for ; Mon, 9 Sep 2013 05:14:49 +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-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1D42C25A4 for ; Mon, 9 Sep 2013 05:14:48 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r895EicJ064659; Mon, 9 Sep 2013 08:14:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r895EicJ064659 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r895EiIO064658; Mon, 9 Sep 2013 08:14:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 9 Sep 2013 08:14:44 +0300 From: Konstantin Belousov To: Oliver Pinter Subject: Re: 9.2-STABLE: supervisor read data, page not present Message-ID: <20130909051444.GG41229@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ie9RhXlkjyREuElA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Sep 2013 05:14:49 -0000 --ie9RhXlkjyREuElA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 08, 2013 at 11:40:01PM +0200, Oliver Pinter wrote: > #6 0xffffffff806a2ab3 in cpuctl_ioctl (dev=3D,=20 > cmd=3D, data=3D, flags=3D0,= =20 > td=3D) at /usr/src/sys/dev/cpuctl/cpuctl.c:478 > cpu =3D > ret =3D Do you indeed posses VIA CPU ? Was it due to some violence act ? I am not sure about the first panic, lets fix the malloc/free corruption and see. The proc_reap() issue might be a consequence of the memory corruption from the wrong free(). There is no public documentation for VIA CPUs, at least I was not able to find anything when I looked. According to the comment in the update_via(), all what is needed is that update buffer was 4-bytes aligned, which is always guaranteed by our malloc(9), at least for the allocation of size >=3D4. Try this. diff --git a/sys/dev/cpuctl/cpuctl.c b/sys/dev/cpuctl/cpuctl.c index 4e5abb2..ca5ed56 100644 --- a/sys/dev/cpuctl/cpuctl.c +++ b/sys/dev/cpuctl/cpuctl.c @@ -408,10 +408,10 @@ fail: static int update_via(int cpu, cpuctl_update_args_t *args, struct thread *td) { - void *ptr =3D NULL; + void *ptr; uint64_t rev0, rev1, res; uint32_t tmp[4]; - int is_bound =3D 0; + int is_bound; int oldcpu; int ret; =20 @@ -427,8 +427,7 @@ update_via(int cpu, cpuctl_update_args_t *args, struct = thread *td) /* * 4 byte alignment required. */ - ptr =3D malloc(args->size + 16, M_CPUCTL, M_WAITOK); - ptr =3D (void *)(16 + ((intptr_t)ptr & ~0xf)); + ptr =3D malloc(args->size, M_CPUCTL, M_WAITOK); if (copyin(args->data, ptr, args->size) !=3D 0) { DPRINTF("[cpuctl,%d]: copyin %p->%p of %zd bytes failed", __LINE__, args->data, ptr, args->size); --ie9RhXlkjyREuElA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSLVlDAAoJEJDCuSvBvK1BvnEP/RXZlu7xSCgfnUevd5nTX+Cx 6/WB6Bj5FFLBrdU/Tr4qYRnG/XMWA591ahTJdORFxna5EYBycJQvRCGS/KeKzZ2s FtPazvniBgNWIvKQD5KzDOSHDS1+FBeh513Se29Nas+UOmERQtsGi0DdyjhEacdM AWQZz4OnghyCf8jHc8/T1ST9h2GYxF2wXhAtOeMLf5FAYqBkkHO9dTATz00FdFxS 8L5aCoib5lGLWt0dnaBgXc4uwgsHvnukO8rPX/nNltO3x4p+bZh2zek1bhcc8xih ZVDt5ZiP4ZykAPj+zMH1xuPfADY221pCm9OQEs2ZxzTipE0BW/G1Jf9d+bUG4e04 LRvHu3Htvi14Skg6CATi3+M5KVHiiqWqgdnz/Bd2AsJqZ8WI4L5EOZAOh2xnh1N8 2zwoikH0bgP+GbQyaBwpYHcBNJAzuyRpiA1RuzvRJ+6kl4r17h94+LiFpKygEOzA qeRnIvbYDpzARcSqLntYc78aIo86yYfI1NgJH0KvDKSzaLqN9CwTx0JR/I8DBCeD 0z+yZ/icr+z8Xj/Uvseh7pY/OY37KK0OcWgWlDh0uHLJBL8MnczYjppMlKjqinOT YfL1mYDpBTWpAM5l8lnPPO8nyIZIAk1APmgGuC2Oh2WNFavZ4d+6njJnPV0919vB xl3ruq860oR0qBnEzGSH =JSpx -----END PGP SIGNATURE----- --ie9RhXlkjyREuElA-- From owner-freebsd-stable@FreeBSD.ORG Mon Sep 9 06:45:22 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 05F18C9F for ; Mon, 9 Sep 2013 06:45:22 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C5DE129BD for ; Mon, 9 Sep 2013 06:45:21 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id xn12so5640338obc.34 for ; Sun, 08 Sep 2013 23:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GTXZ2i79z1kZHp5c+jP4l3kK3dD8WgKtFZamOH+hLpA=; b=qCbmktfjyuPucYTfIXaJ2A20qRYSFylbsjI4c1RM0T2XHK8TvH0p6/YTmHcVhXwzT6 wI2Z35unryPlFKJiudHD6Iv8LiIV9TaRPEyG+37RkKHQJ0RPq8AEUaCJPcap6Xx2aQcf zE2GtrAHBzgKdAKoJ1ArjygcUx43qWjAQpZ25L+CWc6bYMaV1ll6+2E1WSRzCppkmZ3O HvTiVOvVCnGMAOwErZPSOMt4hemlyKMVMXGMON6ZKd5I7pYylX/mrQXwTKkX6eBqE3e2 Npu74AAd9tk1vN0I7GXilh0OvcxUYW7oHqswyCyYDHxUSfBg8scGFR4StuUp3z1+RCyg 0/HQ== MIME-Version: 1.0 X-Received: by 10.182.44.134 with SMTP id e6mr10403709obm.14.1378709121160; Sun, 08 Sep 2013 23:45:21 -0700 (PDT) Received: by 10.182.22.161 with HTTP; Sun, 8 Sep 2013 23:45:21 -0700 (PDT) In-Reply-To: <20130909051444.GG41229@kib.kiev.ua> References: <20130909051444.GG41229@kib.kiev.ua> Date: Mon, 9 Sep 2013 08:45:21 +0200 Message-ID: Subject: Re: 9.2-STABLE: supervisor read data, page not present From: Oliver Pinter To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Sep 2013 06:45:22 -0000 On 9/9/13, Konstantin Belousov wrote: > On Sun, Sep 08, 2013 at 11:40:01PM +0200, Oliver Pinter wrote: >> #6 0xffffffff806a2ab3 in cpuctl_ioctl (dev=, >> cmd=, data=, flags=0, >> td=) at /usr/src/sys/dev/cpuctl/cpuctl.c:478 >> cpu = >> ret = > > Do you indeed posses VIA CPU ? Was it due to some violence act ? Nope, this is an Intel Q9300. FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz (2499.76-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10677 Family = 0x6 Model = 0x17 Stepping = 7 Features=0xbfebfbff Features2=0x8e3fd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 4103024640 (3912 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 > > I am not sure about the first panic, lets fix the malloc/free corruption > and see. The proc_reap() issue might be a consequence of the memory > corruption from the wrong free(). > > There is no public documentation for VIA CPUs, at least I was not > able to find anything when I looked. According to the comment in the > update_via(), all what is needed is that update buffer was 4-bytes > aligned, which is always guaranteed by our malloc(9), at least for the > allocation of size >=4. > > Try this. > > diff --git a/sys/dev/cpuctl/cpuctl.c b/sys/dev/cpuctl/cpuctl.c > index 4e5abb2..ca5ed56 100644 > --- a/sys/dev/cpuctl/cpuctl.c > +++ b/sys/dev/cpuctl/cpuctl.c > @@ -408,10 +408,10 @@ fail: > static int > update_via(int cpu, cpuctl_update_args_t *args, struct thread *td) > { > - void *ptr = NULL; > + void *ptr; > uint64_t rev0, rev1, res; > uint32_t tmp[4]; > - int is_bound = 0; > + int is_bound; > int oldcpu; > int ret; > > @@ -427,8 +427,7 @@ update_via(int cpu, cpuctl_update_args_t *args, struct > thread *td) > /* > * 4 byte alignment required. > */ > - ptr = malloc(args->size + 16, M_CPUCTL, M_WAITOK); > - ptr = (void *)(16 + ((intptr_t)ptr & ~0xf)); > + ptr = malloc(args->size, M_CPUCTL, M_WAITOK); > if (copyin(args->data, ptr, args->size) != 0) { > DPRINTF("[cpuctl,%d]: copyin %p->%p of %zd bytes failed", > __LINE__, args->data, ptr, args->size); > From owner-freebsd-stable@FreeBSD.ORG Mon Sep 9 07:11:22 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D619A444 for ; Mon, 9 Sep 2013 07:11:22 +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-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7511D2B2C for ; Mon, 9 Sep 2013 07:11:22 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r897BCmA090075; Mon, 9 Sep 2013 10:11:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r897BCmA090075 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r897BCjB090074; Mon, 9 Sep 2013 10:11:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 9 Sep 2013 10:11:12 +0300 From: Konstantin Belousov To: Oliver Pinter Subject: Re: 9.2-STABLE: supervisor read data, page not present Message-ID: <20130909071112.GI41229@kib.kiev.ua> References: <20130909051444.GG41229@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SWXyBy1zHAaCX+aB" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Sep 2013 07:11:23 -0000 --SWXyBy1zHAaCX+aB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 09, 2013 at 08:45:21AM +0200, Oliver Pinter wrote: > On 9/9/13, Konstantin Belousov wrote: > > On Sun, Sep 08, 2013 at 11:40:01PM +0200, Oliver Pinter wrote: > >> #6 0xffffffff806a2ab3 in cpuctl_ioctl (dev=3D, > >> cmd=3D, data=3D, flags= =3D0, > >> td=3D) at /usr/src/sys/dev/cpuctl/cpuctl.c:478 > >> cpu =3D > >> ret =3D > > > > Do you indeed posses VIA CPU ? Was it due to some violence act ? >=20 > Nope, this is an Intel Q9300. >=20 > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > CPU: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz (2499.76-MHz K8-clas= s CPU) > Origin =3D "GenuineIntel" Id =3D 0x10677 Family =3D 0x6 Model =3D 0x= 17 > Stepping =3D 7 > Features=3D0xbfebfbff > Features2=3D0x8e3fd > AMD Features=3D0x20100800 > AMD Features2=3D0x1 > TSC: P-state invariant, performance statistics > real memory =3D 4294967296 (4096 MB) > avail memory =3D 4103024640 (3912 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 1 package(s) x 4 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 Intel update code has the same issue. Still, it is weird that the debugger reported the line from the update_via(). >=20 >=20 > > > > I am not sure about the first panic, lets fix the malloc/free corruption > > and see. The proc_reap() issue might be a consequence of the memory > > corruption from the wrong free(). > > > > There is no public documentation for VIA CPUs, at least I was not > > able to find anything when I looked. According to the comment in the > > update_via(), all what is needed is that update buffer was 4-bytes > > aligned, which is always guaranteed by our malloc(9), at least for the > > allocation of size >=3D4. > > > > Try this. Updated patch. diff --git a/sys/dev/cpuctl/cpuctl.c b/sys/dev/cpuctl/cpuctl.c index 4e5abb2..317fc08 100644 --- a/sys/dev/cpuctl/cpuctl.c +++ b/sys/dev/cpuctl/cpuctl.c @@ -295,10 +295,10 @@ cpuctl_do_update(int cpu, cpuctl_update_args_t *data,= struct thread *td) static int update_intel(int cpu, cpuctl_update_args_t *args, struct thread *td) { - void *ptr =3D NULL; + void *ptr; uint64_t rev0, rev1; uint32_t tmp[4]; - int is_bound =3D 0; + int is_bound; int oldcpu; int ret; =20 @@ -312,10 +312,11 @@ update_intel(int cpu, cpuctl_update_args_t *args, str= uct thread *td) } =20 /* - * 16 byte alignment required. + * 16 byte alignment required. Rely on the fact that + * malloc(9) always returns the pointer aligned at least on + * the size of the allocation. */ ptr =3D malloc(args->size + 16, M_CPUCTL, M_WAITOK); - ptr =3D (void *)(16 + ((intptr_t)ptr & ~0xf)); if (copyin(args->data, ptr, args->size) !=3D 0) { DPRINTF("[cpuctl,%d]: copyin %p->%p of %zd bytes failed", __LINE__, args->data, ptr, args->size); @@ -408,10 +409,10 @@ fail: static int update_via(int cpu, cpuctl_update_args_t *args, struct thread *td) { - void *ptr =3D NULL; + void *ptr; uint64_t rev0, rev1, res; uint32_t tmp[4]; - int is_bound =3D 0; + int is_bound; int oldcpu; int ret; =20 @@ -427,8 +428,7 @@ update_via(int cpu, cpuctl_update_args_t *args, struct = thread *td) /* * 4 byte alignment required. */ - ptr =3D malloc(args->size + 16, M_CPUCTL, M_WAITOK); - ptr =3D (void *)(16 + ((intptr_t)ptr & ~0xf)); + ptr =3D malloc(args->size, M_CPUCTL, M_WAITOK); if (copyin(args->data, ptr, args->size) !=3D 0) { DPRINTF("[cpuctl,%d]: copyin %p->%p of %zd bytes failed", __LINE__, args->data, ptr, args->size); --SWXyBy1zHAaCX+aB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSLXSPAAoJEJDCuSvBvK1Bv84P/3cmggIntT24YsCN9/qnt1a5 px4mDPkRyMH+Up+R2FOdewryiKdstDi61RtA/4C4WPBe8cqork6x9V5RHzwTnSvU 3YAgtv/PSK5ABMtwv2IgfejzAowGivwxpFYj+i+jibq4DpiF56upS8iElQMI/HQi uL7JX5zDWZE7ePMWIE3HZddRahKUyJUrHLdCdaUJyNen77V/sOSPuDalvvNbrrAJ qh9JWkZvmvgH/ei3iKLGa+GWVYD/w5KvfL1MAoLJyatVque0Sakn3JCb1+8dmVgZ 68lQv4v3kCThEZlM7y1QTxE6iCBx7x1IHQYBhNyd4JtgCzJuqe45fpvtCq9snmyf j83jMEGya5+LWBnNtxubtCexNt57KEM4C14T4A0wNq7gJ1CjylegZ5ppG/BCVpEj WB63QZCmtdfdaYAblbnCB1uq2E7YKKxCzbx/hi1xRRLa8cWKJt7fxKvxjqpK8t78 mM6yKktes8pGQxBLJAqv39aCOdKcVLK9SxN0lx1mi2E3QV/vqaaekpXxAm/VZ9RK qJciPYeSXzuZMT66E/4GO2pWGo9G6d59GFS5VlhuxurVIxHf5aCpusKv0SNNW+ON kpQjTVUsHFp940tSQIWr6MqjI3MeHQeK+CDU39ERAeJZWdn0hwH/tQIpKZCiS+Df 4kU/s/rIAU67/vBds6AK =1qPV -----END PGP SIGNATURE----- --SWXyBy1zHAaCX+aB-- From owner-freebsd-stable@FreeBSD.ORG Mon Sep 9 09:19:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 41B56E39; Mon, 9 Sep 2013 09:19:49 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9D61C2252; Mon, 9 Sep 2013 09:19:48 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id y10so5044258wgg.0 for ; Mon, 09 Sep 2013 02:19:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/th8GnQzNiG1SinHZaXrQLTfCST+/oz5nkNb4ITGvQg=; b=IP5CwLF1zy2vo04ddXFLj97AhqkmIjcARLxf0gT4Lj+V62Z5tb/L8o2B/DFUnQDppo sINXjrLOQKkdgkAQOkTKBih/mCJGcjIi72VKrg9jP6YuG7qH6qZC55jT/iwvWjJh9jF7 sk5vJgywrtlLqmsUQqQBrICkDD/4FTWjXZO8dFAjO5f0PlK36ok91Fe5kisc1agPaQTb u+0vN4krybjDK6XQOus1WD1D4SCRHGNvF0zX/ADmUZQcZ5gVOtvYZGd+i+31SpR8HJu9 6Xf6GOGgFtE/cN/MqW1E4UPFeSDqydmnZKyX/sPxmLlckUfLEPDM+PIWICk+7vjThMTU +9hA== MIME-Version: 1.0 X-Received: by 10.194.249.97 with SMTP id yt1mr452279wjc.49.1378718387172; Mon, 09 Sep 2013 02:19:47 -0700 (PDT) Received: by 10.216.235.9 with HTTP; Mon, 9 Sep 2013 02:19:47 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Sep 2013 10:19:47 +0100 Message-ID: Subject: Re: zfs_enable vs zfs_load in loader.conf (but neither works) From: krad To: J David Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-fs@freebsd.org" , freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Sep 2013 09:19:49 -0000 once you have it all working and understood have a look at the following port ''usr/ports/sysutils/beadm'' It may make things a little easier to manage in the future. In my experience BE's on zfs rock. On 9 September 2013 02:02, J David wrote: > After setting up a new machine to boot from a ZFS root using the 9.1 > install, it worked fine, but when the kernel & world was updated to > releng/9.2, it stopped booting. The pool is called "data" and the > root partition is "data/root." > > Under 9.1 it had in loader.conf: > > zfs_load=3D"YES" > vfs.root.mountfrom=3D"zfs:data/root" > > Under 9.2-RC3, the same config results in a panic: > > Trying to mount root from zfs:data/root []=85 > init: not found in path > /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/sysinstall > panic: no init > > If this is changed (as many Google hits recommend) to: > > zfs_enable=3D"YES" > vfs.root.mountfrom=3D"zfs:data/root" > > It seems like ZFS doesn't get loaded, so it fails instead with: > > Trying to mount root from zfs:data/root []=85 > Mounting from zfs:data/root failed with error 2: unknown file system. > > If the "?" mountroot> option is used, 50 devices are listed, none of > which are ZFS. And the "unknown file system" response comes from > vfs_byname returning NULL for zfs. > > (If both zfs_enable and zfs_load are set to "YES" then it fails as the > zfs_load case.) > > The system is using update-to-date zpool (v5000 / feature flags), and > all the updated bootblocks from the releng/9.2 build. zpool.cache is > correct, the zpool imports fine from the 9.2-RC3 live cd. The zpool's > bootfs is set correctly, the zfs mountpoint of data/root is / . And, > of course, init is present and health in data/root. The system booted > fine until updating to 9.2. > > Which loader.conf entry is actually correct for ZFS roots on 9.2, and > what (else) needs to happen to make this system bootable again? > > Thanks for any advice! > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Mon Sep 9 11:50:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8193FC63; Mon, 9 Sep 2013 11:50:02 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 49E632DB2; Mon, 9 Sep 2013 11:50:02 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id s9so11843956iec.7 for ; Mon, 09 Sep 2013 04:50:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4ei2cNMOxRpLdAcFNGEVqeNpjL+VUMI/AdKpgHr9o8s=; b=fDMe2Xh5v7qUbYsuAEMVqzY/G3JgSKYAzEUmLUFkOZTbLKvJUDrvwzY6ilgxb97QjO kWvMf+69QTIdO9A5UZsvpOh3EORKfXGALTb0jMHXLfshtC9d+W1KlVjyWQ0iURsxsyoH y/n9cvRs7Iie3m+oSERG0LOE7Rnyw9JlFryiGTiXQu30EDsKAnrJv3ZnZ1hS6po/5qKi i3Ttj7mIEVSDNIkpuZaCefP0MnEP/6SgEv84Y7MX1fT6iOXlxOZdiYdWQ3JFY8wKUREZ eScTfjz7RGcxtssbRZsdtfPZX2xYMt7zPofsbwmzrtQCu04N4pcR2LwxztWLmy7EbZoR AtfQ== MIME-Version: 1.0 X-Received: by 10.50.178.234 with SMTP id db10mr7647925igc.35.1378727401711; Mon, 09 Sep 2013 04:50:01 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.43.157.8 with HTTP; Mon, 9 Sep 2013 04:50:01 -0700 (PDT) In-Reply-To: <522D3C76.1030705@bluerosetech.com> References: <522D30C9.8000203@bluerosetech.com> <522D3C76.1030705@bluerosetech.com> Date: Mon, 9 Sep 2013 07:50:01 -0400 X-Google-Sender-Auth: uoYP0pNMY6VEwxOEbmxBYcvd5pY Message-ID: Subject: Re: zfs_enable vs zfs_load in loader.conf (but neither works) From: J David To: Darren Pilgrim Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-fs@freebsd.org" , freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Sep 2013 11:50:02 -0000 On Sun, Sep 8, 2013 at 11:11 PM, Darren Pilgrim wrote: > You can use zfs.root.mountfrom="zfs:data/root" in /boot/loader.conf instead > of an fstab entry. That has been in loader.conf the whole time. > Mountpoint=legacy is required either way. It isn't. There is another machine right next to it running 9.2-RC1 and it works fine with the mountpoint=/ setting and an empty fstab. And it worked fine on *this* machine on 9.1. It's not clear what changed to stop it from working after upgrading to 9.2-RC3. If time permits, we will update our PXE install environment to 9.2 and rebuild the whole thing. That would eliminate the upgrade step and hopefully give a result others could reproduce. > This only applies to Solaris, IIRC. [citation needed] Setting mountpoint=/ is necessary in order for "zpool import -o altroot=/mnt data" to do the right thing at maintenance time. Thanks! From owner-freebsd-stable@FreeBSD.ORG Mon Sep 9 15:39:23 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3A40AA7A for ; Mon, 9 Sep 2013 15:39:23 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 053B62EF1 for ; Mon, 9 Sep 2013 15:39:22 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id fb19so5932039obc.24 for ; Mon, 09 Sep 2013 08:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rUC9NhyrhQwF1SRhAic6WptGEVCX8nKvPZqHyBJFT90=; b=aJSF8Yc+Qsoyl5buH5GvMqeam9KReiLgC4sKiErDQPlZotu3CN2K5hGrYzBWrPRCHM x2kQFK43Uh3gtM07g4isvNaziIYC5hGsupoThWHQuwgPJU8OsWO4wowS9GoSXi3yQFTm 3QRHYMIBnDh43KU0Go4FlOiCeKunLlxzjqM2NhVh9Kyy8loXI8dQ6N5MeeDqinJ5lBgi 8EpdJcH7jdYB6xTSSq2kYurEHfoElMLYTfKNuf5hJyzU9ot560XCGvELCncaO/2s6CPR +ekOzATFOYCZtlCJd776oWpASGS/Ldt4A5FYzkqy0/0MK4iWcGKXfKukYx6wrvbTq3zv 6P8g== MIME-Version: 1.0 X-Received: by 10.182.16.201 with SMTP id i9mr1793570obd.21.1378741162254; Mon, 09 Sep 2013 08:39:22 -0700 (PDT) Received: by 10.182.22.161 with HTTP; Mon, 9 Sep 2013 08:39:22 -0700 (PDT) In-Reply-To: <20130909071112.GI41229@kib.kiev.ua> References: <20130909051444.GG41229@kib.kiev.ua> <20130909071112.GI41229@kib.kiev.ua> Date: Mon, 9 Sep 2013 17:39:22 +0200 Message-ID: Subject: Re: 9.2-STABLE: supervisor read data, page not present From: Oliver Pinter To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Sep 2013 15:39:23 -0000 On 9/9/13, Konstantin Belousov wrote: > On Mon, Sep 09, 2013 at 08:45:21AM +0200, Oliver Pinter wrote: >> On 9/9/13, Konstantin Belousov wrote: >> > On Sun, Sep 08, 2013 at 11:40:01PM +0200, Oliver Pinter wrote: >> >> #6 0xffffffff806a2ab3 in cpuctl_ioctl (dev=, >> >> cmd=, data=, flags=0, >> >> td=) at /usr/src/sys/dev/cpuctl/cpuctl.c:478 >> >> cpu = >> >> ret = >> > >> > Do you indeed posses VIA CPU ? Was it due to some violence act ? >> >> Nope, this is an Intel Q9300. >> >> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 >> CPU: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz (2499.76-MHz K8-class >> CPU) >> Origin = "GenuineIntel" Id = 0x10677 Family = 0x6 Model = 0x17 >> Stepping = 7 >> >> Features=0xbfebfbff >> >> Features2=0x8e3fd >> AMD Features=0x20100800 >> AMD Features2=0x1 >> TSC: P-state invariant, performance statistics >> real memory = 4294967296 (4096 MB) >> avail memory = 4103024640 (3912 MB) >> Event timer "LAPIC" quality 400 >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> FreeBSD/SMP: 1 package(s) x 4 core(s) >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> cpu2 (AP): APIC ID: 2 >> cpu3 (AP): APIC ID: 3 > Intel update code has the same issue. Still, it is weird that the debugger > reported the line from the update_via(). > >> >> >> > >> > I am not sure about the first panic, lets fix the malloc/free >> > corruption >> > and see. The proc_reap() issue might be a consequence of the memory >> > corruption from the wrong free(). >> > >> > There is no public documentation for VIA CPUs, at least I was not >> > able to find anything when I looked. According to the comment in the >> > update_via(), all what is needed is that update buffer was 4-bytes >> > aligned, which is always guaranteed by our malloc(9), at least for the >> > allocation of size >=4. >> > >> > Try this. > > Updated patch. > > diff --git a/sys/dev/cpuctl/cpuctl.c b/sys/dev/cpuctl/cpuctl.c > index 4e5abb2..317fc08 100644 > --- a/sys/dev/cpuctl/cpuctl.c > +++ b/sys/dev/cpuctl/cpuctl.c > @@ -295,10 +295,10 @@ cpuctl_do_update(int cpu, cpuctl_update_args_t *data, > struct thread *td) > static int > update_intel(int cpu, cpuctl_update_args_t *args, struct thread *td) > { > - void *ptr = NULL; > + void *ptr; > uint64_t rev0, rev1; > uint32_t tmp[4]; > - int is_bound = 0; > + int is_bound; > int oldcpu; > int ret; > > @@ -312,10 +312,11 @@ update_intel(int cpu, cpuctl_update_args_t *args, > struct thread *td) > } > > /* > - * 16 byte alignment required. > + * 16 byte alignment required. Rely on the fact that > + * malloc(9) always returns the pointer aligned at least on > + * the size of the allocation. > */ > ptr = malloc(args->size + 16, M_CPUCTL, M_WAITOK); > - ptr = (void *)(16 + ((intptr_t)ptr & ~0xf)); > if (copyin(args->data, ptr, args->size) != 0) { > DPRINTF("[cpuctl,%d]: copyin %p->%p of %zd bytes failed", > __LINE__, args->data, ptr, args->size); > @@ -408,10 +409,10 @@ fail: > static int > update_via(int cpu, cpuctl_update_args_t *args, struct thread *td) > { > - void *ptr = NULL; > + void *ptr; > uint64_t rev0, rev1, res; > uint32_t tmp[4]; > - int is_bound = 0; > + int is_bound; > int oldcpu; > int ret; > > @@ -427,8 +428,7 @@ update_via(int cpu, cpuctl_update_args_t *args, struct > thread *td) > /* > * 4 byte alignment required. > */ > - ptr = malloc(args->size + 16, M_CPUCTL, M_WAITOK); > - ptr = (void *)(16 + ((intptr_t)ptr & ~0xf)); > + ptr = malloc(args->size, M_CPUCTL, M_WAITOK); > if (copyin(args->data, ptr, args->size) != 0) { > DPRINTF("[cpuctl,%d]: copyin %p->%p of %zd bytes failed", > __LINE__, args->data, ptr, args->size); > Thanks, this patch fixed the issue. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 9 17:13:44 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 806F89C4 for ; Mon, 9 Sep 2013 17:13:44 +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-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CD20D262A for ; Mon, 9 Sep 2013 17:13:43 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r89HDb7w017067; Mon, 9 Sep 2013 20:13:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r89HDb7w017067 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r89HDbaN017066; Mon, 9 Sep 2013 20:13:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 9 Sep 2013 20:13:37 +0300 From: Konstantin Belousov To: Oliver Pinter Subject: Re: 9.2-STABLE: supervisor read data, page not present Message-ID: <20130909171337.GP41229@kib.kiev.ua> References: <20130909051444.GG41229@kib.kiev.ua> <20130909071112.GI41229@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hVel+ndfTAVlA9HE" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Sep 2013 17:13:44 -0000 --hVel+ndfTAVlA9HE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Sep 09, 2013 at 05:39:22PM +0200, Oliver Pinter wrote: > Thanks, this patch fixed the issue. Which issue among the two problems you reported ? I assume that cpuctl panic is gone, but what about proc_reap issue ? --hVel+ndfTAVlA9HE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSLgHAAAoJEJDCuSvBvK1BWzcP/2WSCU4A2sh11YG1KaPPHSW/ ah/1IRU881+jq36pIwaYqS3vTzwy+UftkhQBVgTM+aNm1ZAuHAao8T3rmuxKblC2 ggWksh9LSYlMlKJmRTmu3R50t+8UN/B1RjI21pZxPBZUOe3h637ppekeWciscvVW RObwF4Tri4Sd7xISMHA4j2ItEGky7CMnS64JWqw3gjMAI5WAKtcjLWBk/kVQnVrw gFi7K59AMqs7rRXA7cFpHp7A7SVodzgSfrDqY7i91ALjvfyYbVURuUipu1OFt8xX 8F8UmCcLoMnXyK6DEGRnky27A2qf2bnBU79tHbtwL1BL6GmtDCLOMMDOe3At6bUS oejeNkzwZtGb9f6wwWmRMlpZGBgP04GMR+rhZVBX3vYJaPRrNzykSrf/dCm3YHHy IUZznypnMGtcbpRtuznH7sfKl5a0Y/kPxhuahQMjzW6GwDo1irIH/1DMM6TMBLmZ UgYChgagHzpBeqLUKSBfYzQwO0zpaxnv+YLWT6oOQtt9FXOSpgHHlmakbqpghRgW JM67uR3+n8E/pPDu/SDqf9kykBRgJ3U8iM2v0mAY86ciYhXo7ldeV9DH6Up1EOIv vsaRoOgnkpqpfswAqT6qQIC83JVOtQrFwYbp/FSjxRRY13o/JjXV0QdOXM5u33zD 3DbktN9t/9MZHjbe6N6A =hhcy -----END PGP SIGNATURE----- --hVel+ndfTAVlA9HE-- From owner-freebsd-stable@FreeBSD.ORG Mon Sep 9 17:51:04 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 575E7A8D for ; Mon, 9 Sep 2013 17:51:04 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 228D028AD for ; Mon, 9 Sep 2013 17:51:04 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id j6so6879863oag.28 for ; Mon, 09 Sep 2013 10:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iUZEEBCQpdzSRNswIieRQYyIOyRMHlyc3v+dGkJaogs=; b=zJ3/YOlQ/ZkRutzDL/79w2XeZpG5JhST82/0VPIpapo9CgFvezNa/gFEazis77Md3s uGYdyIVsbjzrV0HWctSZQTu3LmmpY/KP5uA61F71TjBBwXXME2OdRnU+m3dtKD3ae5E3 pSz19L+2vwERNsCg9QnyexiiF0NZ3B0j63tqiEbZRJZrIR4OogFAdWnzfUde4REy982/ Mbe+eU/nh4S/3b20ebU6K47JYJAzQGIOCQ8U+MYq6QwS0hnpNHRdiBktwzMPohVu3zsy uuUvejvBmYA9QJId914jp/IMHA93aj5Cg0mhsNA7gjiDVbEyx+cW4CdIj5QtSwZreYfQ fT+A== MIME-Version: 1.0 X-Received: by 10.182.16.201 with SMTP id i9mr2189300obd.21.1378749063523; Mon, 09 Sep 2013 10:51:03 -0700 (PDT) Received: by 10.182.22.161 with HTTP; Mon, 9 Sep 2013 10:51:03 -0700 (PDT) In-Reply-To: <20130909171337.GP41229@kib.kiev.ua> References: <20130909051444.GG41229@kib.kiev.ua> <20130909071112.GI41229@kib.kiev.ua> <20130909171337.GP41229@kib.kiev.ua> Date: Mon, 9 Sep 2013 19:51:03 +0200 Message-ID: Subject: Re: 9.2-STABLE: supervisor read data, page not present From: Oliver Pinter To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Sep 2013 17:51:04 -0000 On 9/9/13, Konstantin Belousov wrote: > On Mon, Sep 09, 2013 at 05:39:22PM +0200, Oliver Pinter wrote: >> Thanks, this patch fixed the issue. > > Which issue among the two problems you reported ? I assume that cpuctl > panic is gone, but what about proc_reap issue ? > Seems like both issue fixed. The system survived a full build word plus a portupgrade -arR. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 9 23:11:11 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0297811F; Mon, 9 Sep 2013 23:11:11 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by mx1.freebsd.org (Postfix) with ESMTP id 5EE862A9C; Mon, 9 Sep 2013 23:11:10 +0000 (UTC) Received: from ppp118-210-73-223.lns20.adl2.internode.on.net (HELO leader.local) ([118.210.73.223]) by ipmail06.adl2.internode.on.net with ESMTP; 10 Sep 2013 08:40:57 +0930 Message-ID: <522E557E.5050202@ShaneWare.Biz> Date: Tue, 10 Sep 2013 08:40:54 +0930 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130516 Thunderbird/17.0.6 MIME-Version: 1.0 To: J David Subject: Re: zfs_enable vs zfs_load in loader.conf (but neither works) References: <522D30C9.8000203@bluerosetech.com> <522D3C76.1030705@bluerosetech.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@freebsd.org" , freebsd-stable , Darren Pilgrim X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Sep 2013 23:11:11 -0000 On 09/09/2013 21:20, J David wrote: > On Sun, Sep 8, 2013 at 11:11 PM, Darren Pilgrim > wrote: >> You can use zfs.root.mountfrom="zfs:data/root" in /boot/loader.conf >> instead of an fstab entry. > > That has been in loader.conf the whole time. > >> Mountpoint=legacy is required either way. > > It isn't. There is another machine right next to it running 9.2-RC1 > and it works fine with the mountpoint=/ setting and an empty fstab. > I installed 9.0 onto my machine booting from zfs about a year and a half ago and remember having issues getting it bootable. As I recall mounpoint=legacy and mountpoint=/ effectively point to two different filesystems. Changing the mounpoint after installing hides the / filesystem. So it isn't so much which mountpoint to use but which mountpoint *was* used when you installed the system. From owner-freebsd-stable@FreeBSD.ORG Tue Sep 10 06:11:42 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8C7C1855 for ; Tue, 10 Sep 2013 06:11:42 +0000 (UTC) (envelope-from rmcintosh@nitemare.net) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 49C2A2CE6 for ; Tue, 10 Sep 2013 06:11:41 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id j15so164062qaq.4 for ; Mon, 09 Sep 2013 23:11:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EY/V3wQ/ZMtOggYl9dDL5PTyMvqfoM3S/5xqyaCNL8k=; b=GgnEP6xMRKImMRgdDL5jQ0IbB0d/H5yC5uY5TbJnNFAecB+dppVaZfTs53rs+sW9sQ 0Rx7Pay9UFdvoGfJaCRbMtfBofkxcgMcwxdPEwBxqLF1jcMiKAf5v7DHi2Nq0Sz6ob5m YK5u/cWJ4ObhalMkvY8hkYZwki1CvVZwFkc2PM3ptQOx/PkGz3gOCBysde7T+tIHcypI 1bf6ZGv57SCLaVs602Z4dvfHEmJw2/mVJxGMyMbWhwpDCOmDe9HYd8DQP2gkJ4rWo827 17VWtw+VRsP3/4m8D5G7I0keeOJ4WAl8MElubQ78MA05DB1RfzZojbAez6WImWQpCTop at3w== X-Gm-Message-State: ALoCoQmcO5lATAdfNyt0hcqkPCwNFUNzjQ60VIkjj8mkSTO+WilkpW83xEz05XfOSvd9XHc+xA7y MIME-Version: 1.0 X-Received: by 10.224.13.16 with SMTP id z16mr30518qaz.98.1378793495194; Mon, 09 Sep 2013 23:11:35 -0700 (PDT) Received: by 10.49.60.10 with HTTP; Mon, 9 Sep 2013 23:11:35 -0700 (PDT) X-Originating-IP: [2001:470:8ca5:2001:901b:bccc:8b91:66ee] In-Reply-To: <522C99AA.7010008@mu.org> References: <522C99AA.7010008@mu.org> Date: Tue, 10 Sep 2013 02:11:35 -0400 Message-ID: Subject: Re: Looking for driver help From: Ryan McIntosh To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Sep 2013 06:11:42 -0000 Presently 9.1-RELEASE but I believe I searched HEAD for the driver which came up with nothing. I'm all ears though if you find something. root@dev01:/root # pciconf -l hostb0@pci0:0:0:0: class=0x060000 card=0xbc8015d9 chip=0x40038086 rev=0x20 hdr=0x00 pcib1@pci0:0:1:0: class=0x060400 card=0xbc8015d9 chip=0x40218086 rev=0x20 hdr=0x01 pcib2@pci0:0:5:0: class=0x060400 card=0xbc8015d9 chip=0x40258086 rev=0x20 hdr=0x01 pcib7@pci0:0:7:0: class=0x060400 card=0xbc8015d9 chip=0x40278086 rev=0x20 hdr=0x01 none0@pci0:0:15:0: class=0x088000 card=0xbc8015d9 chip=0x402f8086 rev=0x20 hdr=0x00 hostb1@pci0:0:16:0: class=0x060000 card=0xbc8015d9 chip=0x40308086 rev=0x20 hdr=0x00 hostb2@pci0:0:16:1: class=0x060000 card=0xbc8015d9 chip=0x40308086 rev=0x20 hdr=0x00 hostb3@pci0:0:16:2: class=0x060000 card=0xbc8015d9 chip=0x40308086 rev=0x20 hdr=0x00 hostb4@pci0:0:16:3: class=0x060000 card=0xbc8015d9 chip=0x40308086 rev=0x20 hdr=0x00 hostb5@pci0:0:16:4: class=0x060000 card=0xbc8015d9 chip=0x40308086 rev=0x20 hdr=0x00 hostb6@pci0:0:17:0: class=0x060000 card=0xbc8015d9 chip=0x40318086 rev=0x20 hdr=0x00 hostb7@pci0:0:21:0: class=0x060000 card=0xbc8015d9 chip=0x40358086 rev=0x20 hdr=0x00 hostb8@pci0:0:21:1: class=0x060000 card=0xbc8015d9 chip=0x40358086 rev=0x20 hdr=0x00 hostb9@pci0:0:22:0: class=0x060000 card=0xbc8015d9 chip=0x40368086 rev=0x20 hdr=0x00 hostb10@pci0:0:22:1: class=0x060000 card=0xbc8015d9 chip=0x40368086 rev=0x20 hdr=0x00 uhci0@pci0:0:29:0: class=0x0c0300 card=0xbc8015d9 chip=0x26888086 rev=0x09 hdr=0x00 uhci1@pci0:0:29:1: class=0x0c0300 card=0xbc8015d9 chip=0x26898086 rev=0x09 hdr=0x00 uhci2@pci0:0:29:2: class=0x0c0300 card=0xbc8015d9 chip=0x268a8086 rev=0x09 hdr=0x00 ehci0@pci0:0:29:7: class=0x0c0320 card=0xbc8015d9 chip=0x268c8086 rev=0x09 hdr=0x00 pcib8@pci0:0:30:0: class=0x060401 card=0xbc8015d9 chip=0x244e8086 rev=0xd9 hdr=0x01 isab0@pci0:0:31:0: class=0x060100 card=0xbc8015d9 chip=0x26708086 rev=0x09 hdr=0x00 ahci0@pci0:0:31:2: class=0x010601 card=0xbc8015d9 chip=0x26818086 rev=0x09 hdr=0x00 none1@pci0:0:31:3: class=0x0c0500 card=0xbc8015d9 chip=0x269b8086 rev=0x09 hdr=0x00 none2@pci0:1:0:0: class=0x020000 card=0x01264040 chip=0x01004040 rev=0x42 hdr=0x00 none3@pci0:1:0:1: class=0x020000 card=0x01264040 chip=0x01004040 rev=0x42 hdr=0x00 pcib3@pci0:3:0:0: class=0x060400 card=0xbc8015d9 chip=0x35008086 rev=0x01 hdr=0x01 pcib6@pci0:3:0:3: class=0x060400 card=0xbc8015d9 chip=0x350c8086 rev=0x01 hdr=0x01 pcib4@pci0:4:0:0: class=0x060400 card=0xbc8015d9 chip=0x35108086 rev=0x01 hdr=0x01 pcib5@pci0:4:2:0: class=0x060400 card=0xbc8015d9 chip=0x35188086 rev=0x01 hdr=0x01 em0@pci0:6:0:0: class=0x020000 card=0x109615d9 chip=0x10968086 rev=0x01 hdr=0x00 em1@pci0:6:0:1: class=0x020000 card=0x109615d9 chip=0x10968086 rev=0x01 hdr=0x00 none4@pci0:8:0:0: class=0x0c0600 card=0x627415b3 chip=0x627415b3 rev=0x20 hdr=0x00 vgapci0@pci0:9:1:0: class=0x030000 card=0xbc8015d9 chip=0x515e1002 rev=0x02 hdr=0x00 - snip from pciconf -lv for the card in question (its a dual port) - none2@pci0:1:0:0: class=0x020000 card=0x01264040 chip=0x01004040 rev=0x42 hdr=0x00 vendor = 'NetXen Incorporated' device = 'NX3031 Multifunction 1/10-Gigabit Server Adapter' class = network subclass = ethernet none3@pci0:1:0:1: class=0x020000 card=0x01264040 chip=0x01004040 rev=0x42 hdr=0x00 vendor = 'NetXen Incorporated' device = 'NX3031 Multifunction 1/10-Gigabit Server Adapter' class = network subclass = ethernet - end snip - root@dev01:/root # uname -a FreeBSD dev01 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 root@dev01:/root # I'll upgrade to whatever if there's a chance of a driver already existing but so far I've found nothing. Thanks and sorry for the delay. Ryan On Sun, Sep 8, 2013 at 11:37 AM, Alfred Perlstein wrote: > On 9/8/13 3:01 AM, Ryan McIntosh wrote: > >> I sent an email out to freebsd-net without a response, soo this is my last >> attempt at getting any assistance here. >> >> I have a QLE3142-CU-CK (rebranded NetXen NX3-20GCU w/ NX3031 chipset) with >> no driver support in *BSD from anything I saw. I came across solaris's >> ntxn >> driver which seems to work appropriately but I have no use for solaris as >> a >> host o/s. Naturally I'll attempt at trying to get the driver to work >> myself, however I'm far from knowledgeable on the method to port a driver, >> but I won't say no to making it work after the response Qlogic gave me. >> Any >> insight/assistance/pointers would be helpful, including which mailing list >> might be best for this. >> >> Ryan >> ______________________________**_________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/**mailman/listinfo/freebsd-**stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@** >> freebsd.org " >> >> What version of FreeBSD are you using? FreeBSD 10 has drivers for > several qlogic 10gb cards. > > It would help to see output of "pciconf -l" on this machine as well > knowing what version you are using. > > > > -- > Alfred Perlstein > > From owner-freebsd-stable@FreeBSD.ORG Tue Sep 10 08:26:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A92A642D; Tue, 10 Sep 2013 08:26:30 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 74E582385; Tue, 10 Sep 2013 08:26:30 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c10so15505925ieb.31 for ; Tue, 10 Sep 2013 01:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=23Q9ki+gG7P5PZAWls1yePNzPSiAd+Fg09GpB69b8Aw=; b=G6Z6Udj8X/uk5ToC7ZVrA/csuW2kIBsn9XnQru4luM232G3rr4UkW+nLkUsxwEHlwz Df85gHRfscM7eiGgRQ0V+ulkWLoi9QH4Z2KCRdcwtbppww+sICKo1VewOApI3YbkQUoI /K72E2pJs5duq1CHsED/VT/YUpfDnwNsvw+HQV4rB88mSF/Kfqo6mvSUHoByglqCSQP+ iwKyLVI2Fgm6koXUp+E34yD9a9z7jpNPHQTSDXePc7oUNG6CELrLhhHg6Mk4TvSY+cDy EmMkMoZxvmeBVFjxojMB3Ve9p6i3sL+iaaQ1rVzrwRkIjDaOrS4BbAV12FejHRp40zgv 187A== MIME-Version: 1.0 X-Received: by 10.50.154.41 with SMTP id vl9mr10600672igb.10.1378801589927; Tue, 10 Sep 2013 01:26:29 -0700 (PDT) Received: by 10.64.60.1 with HTTP; Tue, 10 Sep 2013 01:26:29 -0700 (PDT) In-Reply-To: <20130828131017.GA89499@lyxys.ka.sub.org> References: <20130828131017.GA89499@lyxys.ka.sub.org> Date: Tue, 10 Sep 2013 10:26:29 +0200 Message-ID: Subject: Re: State of Unicode collation support in FreeBSD? From: David Demelier To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: freebsd-i18n@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Sep 2013 08:26:30 -0000 2013/8/28 Wolfgang Zenker : > [crossposted to -stable and -i18n, replies directed to -stable] > > Hi everyone, > > could someone point me to infos regarding Unicode collation support in FreeBSD? > All I could find was https://wiki.freebsd.org/KonradJankowski/Collation but > that page has not been changed in more than two years. Looking at sources of > -current it doesn't look like those changes made it into the source tree yet. > > Wolfgang I think no one is really interested to add real UTF-8 support to Syscons. Currently you can get UTF-8 output by using Syscons xterm ttys (which is default) and set your appropriate locales. For input it's currently (unfortunately) not supported. If you use X.Org, then your fine using UTF-8. Cheers, -- Demelier David From owner-freebsd-stable@FreeBSD.ORG Tue Sep 10 08:46:01 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 11BDBB3E; Tue, 10 Sep 2013 08:46:01 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id C222024CD; Tue, 10 Sep 2013 08:46:00 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VJJcB-0002vK-LJ; Tue, 10 Sep 2013 12:48:03 +0400 Date: Tue, 10 Sep 2013 12:48:03 +0400 From: Slawa Olhovchenkov To: David Demelier Subject: Re: State of Unicode collation support in FreeBSD? Message-ID: <20130910084803.GA11079@zxy.spb.ru> References: <20130828131017.GA89499@lyxys.ka.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org, freebsd-i18n@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Sep 2013 08:46:01 -0000 On Tue, Sep 10, 2013 at 10:26:29AM +0200, David Demelier wrote: > 2013/8/28 Wolfgang Zenker : > > [crossposted to -stable and -i18n, replies directed to -stable] > > > > Hi everyone, > > > > could someone point me to infos regarding Unicode collation support in FreeBSD? > > All I could find was https://wiki.freebsd.org/KonradJankowski/Collation but > > that page has not been changed in more than two years. Looking at sources of > > -current it doesn't look like those changes made it into the source tree yet. > > > > Wolfgang > > I think no one is really interested to add real UTF-8 support to > Syscons. Currently you can get UTF-8 output by using Syscons xterm > ttys (which is default) and set your appropriate locales. For input > it's currently (unfortunately) not supported. > > If you use X.Org, then your fine using UTF-8. Why you talk about syscons? This is about sort, postgres and other software. From owner-freebsd-stable@FreeBSD.ORG Tue Sep 10 09:39:44 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 55121ED2; Tue, 10 Sep 2013 09:39:44 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from saturn.lyxys.ka.sub.org (saturn.lyxys.ka.sub.org [217.29.35.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B6C3D2800; Tue, 10 Sep 2013 09:39:43 +0000 (UTC) Received: from juno.lyxys.ka.sub.org (juno.lyx [IPv6:fd2a:89ca:7d54:0:20f:feff:fe0e:7312]) by saturn.lyxys.ka.sub.org (8.14.7/8.14.7) with ESMTP id r8A9U9bC051081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Sep 2013 11:30:10 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (localhost [127.0.0.1]) by juno.lyxys.ka.sub.org (8.14.7/8.14.7) with ESMTP id r8A9U97C025910; Tue, 10 Sep 2013 11:30:09 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: (from wolfgang@localhost) by juno.lyxys.ka.sub.org (8.14.7/8.14.7/Submit) id r8A9U9No025909; Tue, 10 Sep 2013 11:30:09 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) X-Authentication-Warning: juno.lyxys.ka.sub.org: wolfgang set sender to wolfgang@lyxys.ka.sub.org using -f Date: Tue, 10 Sep 2013 11:30:09 +0200 From: Wolfgang Zenker To: freebsd-stable@freebsd.org Subject: Re: State of Unicode collation support in FreeBSD? Message-ID: <20130910093009.GA25595@lyxys.ka.sub.org> References: <20130828131017.GA89499@lyxys.ka.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: private site User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (saturn.lyxys.ka.sub.org [IPv6:fd2a:89ca:7d54:1:200:24ff:feca:b4cc]); Tue, 10 Sep 2013 11:30:10 +0200 (CEST) Cc: freebsd-i18n@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Sep 2013 09:39:44 -0000 * David Demelier [130910 10:26]: > 2013/8/28 Wolfgang Zenker : >> [crossposted to -stable and -i18n] >> could someone point me to infos regarding Unicode collation support in FreeBSD? >> All I could find was https://wiki.freebsd.org/KonradJankowski/Collation but >> that page has not been changed in more than two years. Looking at sources of >> -current it doesn't look like those changes made it into the source tree yet. > I think no one is really interested to add real UTF-8 support to > Syscons. Currently you can get UTF-8 output by using Syscons xterm > ttys (which is default) and set your appropriate locales. For input > it's currently (unfortunately) not supported. > If you use X.Org, then your fine using UTF-8. There might be a misunderstanding: Collation is about ordering characters and sorting strings. What we have in FreeBSD right now is support for input and output of utf-8 characters, and with X11 and the right set of fonts they display ok, and at least using vim editing utf-8 text works ok. But sorting utf-8 strings yields "interesting" results as soon as you have non-ascii characters in your strings. Wolfgang From owner-freebsd-stable@FreeBSD.ORG Tue Sep 10 14:57:01 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CEB2E8E9 for ; Tue, 10 Sep 2013 14:57:01 +0000 (UTC) (envelope-from marko.cupac@mimar.rs) Received: from www.mimar.rs (www.mimar.rs [193.53.106.101]) by mx1.freebsd.org (Postfix) with ESMTP id 9700A20FB for ; Tue, 10 Sep 2013 14:57:00 +0000 (UTC) Received: from kaa.mimar.rs (unknown [193.53.106.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marko.cupac@mimar.rs) by www.mimar.rs (Postfix) with ESMTPSA id 223EEB9020 for ; Tue, 10 Sep 2013 16:51:00 +0200 (CEST) Date: Tue, 10 Sep 2013 16:50:55 +0200 From: Marko =?UTF-8?B?Q3VwYcSH?= To: freebsd-stable@freebsd.org Subject: 9.2-PRERELEASE #0 r254557 amd64: core dump on shutdown Message-Id: <20130910165055.da25cd4234c283dafef39462@mimar.rs> Organization: Mimar X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; amd64-portbld-freebsd9.2) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Sep 2013 14:57:01 -0000 My 9.2-PRERELEASE #0 r254557 amd64 just dumped core on shutdown. I updated src to Last Changed Rev: 255395 two days ago but did not get to rebuild world&kernel. Also I did not rebuild any ports since. Virtualbox was not running. pacija@kaa:/var/crash % uname -a FreeBSD kaa.mimar.rs 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r254557: Sun Aug 25 22:44:52 CEST 2013 pacija@kaa.mimar.rs:/usr/obj/usr/src/sys/KAAGEN amd64 pacija@kaa:/var/crash % sudo cat core.txt.2 kaa.mimar.rs dumped core - see /var/crash/vmcore.2 Tue Sep 10 16:41:45 CEST 2013 FreeBSD kaa.mimar.rs 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r254557: Sun Aug 25 22:44:52 CEST 2013 pacija@kaa.mimar.rs:/usr/obj/usr/src/sys/KAAGEN amd64 panic: page fault 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: <118>Sep 10 16:39:49 kaa syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop...Syncing disks, vnodes remaining...8 8 4 1 1 1 0 0 done All buffers synced. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x9 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80b71085 stack pointer = 0x28:0xffffff800026a9e0 frame pointer = 0x28:0xffffff800026aa60 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 = 1 (init) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xffffffff80948356 at kdb_backtrace+0x66 #1 0xffffffff8090deae at panic+0x1ce #2 0xffffffff80cf2c00 at trap_fatal+0x290 #3 0xffffffff80cf2f61 at trap_pfault+0x211 #4 0xffffffff80cf3514 at trap+0x344 #5 0xffffffff80cdc843 at calltrap+0x8 #6 0xffffffff80b715e5 at swapoff_all+0xc5 #7 0xffffffff8090dca5 at kern_reboot+0x805 #8 0xffffffff8090e06c at sys_reboot+0x6c #9 0xffffffff80cf23aa at amd64_syscall+0x5ea #10 0xffffffff80cdcb27 at Xfast_syscall+0xf7 Uptime: 8h16m49s Dumping 417 out of 3984 MB:..4%..12%..23%..31%..43%..54%..62%..73%..81%..92% Reading symbols from /boot/kernel/acpi_video.ko...Reading symbols from /boot/kernel/acpi_video.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_video.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from /boot/kernel/tmpfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/tmpfs.ko Reading symbols from /boot/kernel/ng_ubt.ko...Reading symbols from /boot/kernel/ng_ubt.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ubt.ko Reading symbols from /boot/kernel/ng_hci.ko...Reading symbols from /boot/kernel/ng_hci.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_hci.ko Reading symbols from /boot/kernel/ng_bluetooth.ko...Reading symbols from /boot/kernel/ng_bluetooth.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_bluetooth.ko Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot/kernel/netgraph.ko.symbols...done. done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/ng_l2cap.ko...Reading symbols from /boot/kernel/ng_l2cap.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_l2cap.ko Reading symbols from /boot/kernel/ng_btsocket.ko...Reading symbols from /boot/kernel/ng_btsocket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_btsocket.ko Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from /boot/kernel/ng_socket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_socket.ko Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ether.ko Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko #0 doadump (textdump=) at pcpu.h:234 234 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:234 #1 0xffffffff8090d986 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0xffffffff8090de87 in panic (fmt=0x1
) at /usr/src/sys/kern/kern_shutdown.c:637 #3 0xffffffff80cf2c00 in trap_fatal (frame=0xc, eva=) at /usr/src/sys/amd64/amd64/trap.c:879 #4 0xffffffff80cf2f61 in trap_pfault (frame=0xffffff800026a930, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:795 #5 0xffffffff80cf3514 in trap (frame=0xffffff800026a930) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0xffffffff80cdc843 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #7 0xffffffff80b71085 in swapoff_one (sp=0xfffffe0006296600, cred=0xfffffe00037a0e00) at /usr/src/sys/vm/swap_pager.c:1753 #8 0xffffffff80b715e5 in swapoff_all () at /usr/src/sys/vm/swap_pager.c:2369 #9 0xffffffff8090dca5 in kern_reboot (howto=16392) at /usr/src/sys/kern/kern_shutdown.c:434 #10 0xffffffff8090e06c in sys_reboot (td=0xfffffe0003923920, uap=0xffffff800026abb0) at /usr/src/sys/kern/kern_shutdown.c:193 #11 0xffffffff80cf23aa in amd64_syscall (td=0xfffffe0003923920, traced=0) at subr_syscall.c:135 #12 0xffffffff80cdcb27 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #13 0x000000000040e41c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -52 0 0 0 - DLs ?? 1:22.62 [kernel] 0 1 0 0 52 0 6276 0 - RLs ?? 0:00.02 [init] 0 2 0 0 -16 0 0 0 waiting_ DL ?? 0:00.00 [sctp_iterator] 0 3 0 0 -16 0 0 0 ccb_scan DL ?? 0:00.00 [xpt_thrd] 0 4 0 0 -16 0 0 0 psleep DL ?? 0:00.04 [pagedaemon] 0 5 0 0 -16 0 0 0 psleep DL ?? 0:00.00 [vmdaemon] 0 6 0 0 155 0 0 0 pgzero DL ?? 0:00.00 [pagezero] 0 7 0 0 -16 0 0 0 kpsusp DL ?? 0:00.22 [bufdaemon] 0 8 0 0 16 0 0 0 kpsusp DL ?? 0:09.10 [syncer] 0 9 0 0 -16 0 0 0 kpsusp DL ?? 0:00.21 [vnlru] 0 10 0 0 -16 0 0 0 audit_wo DL ?? 0:00.00 [audit] 0 11 0 0 155 0 0 0 - RL ?? 3872:46.20 [idle] 0 12 0 0 -84 0 0 0 - WL ?? 8:13.25 [intr] 0 13 0 0 -8 0 0 0 - DL ?? 0:03.31 [geom] 0 14 0 0 -16 0 0 0 - DL ?? 0:03.74 [yarrow] 0 15 0 0 -68 0 0 0 - DL ?? 0:45.16 [usb] 0 16 0 0 -16 0 0 0 tzpoll DL ?? 0:00.73 [acpi_thermal] 0 17 0 0 -16 0 0 0 cooling DL ?? 0:00.02 [acpi_cooling0] 0 18 0 0 -20 0 0 0 VBoxIS DL ?? 0:00.00 [TIMER] 0 19 0 0 -16 0 0 0 sdflush DL ?? 0:00.51 [softdepflush] 0 811 0 0 -16 0 0 0 sleep DL ?? 0:00.00 [ng_queue] ------------------------------------------------------------------------ vmstat -s 79424836 cpu context switches 19588291 device interrupts 7335930 software interrupts 15166560 traps 299984975 system calls 20 kernel threads created 6019 fork() calls 3110 vfork() calls 0 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 60988 vnode pager pageins 172371 vnode pager pages paged in 8926 vnode pager pageouts 52160 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 43545 pages reactivated 361432 copy-on-write faults 779 copy-on-write optimized faults 5517735 zero fill pages zeroed 8609 zero fill pages prezeroed 360 intransit blocking page faults 6720556 total VM faults taken 0 pages affected by kernel thread creation 3257870 pages affected by fork() 1502839 pages affected by vfork() 0 pages affected by rfork() 0 pages cached 7141258 pages freed 0 pages freed by daemon 0 pages freed by exiting processes 31 pages active 7 pages inactive 0 pages in VM cache 58279 pages wired down 923095 pages free 4096 bytes per page 11160180 total name lookups cache hits (87% pos + 1% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) CAM SIM 4 1K - 4 256 acpidev 44 3K - 44 64 USBdev 58 17K - 241 64,128,512 isadev 8 1K - 8 128 USB 56 114K - 64 16,32,128,256,512,1024,2048,4096 cdev 8 2K - 8 256 entropy 1024 64K - 1024 64 sigio 0 0K - 2 64 filedesc 21 11K - 9532 16,32,64,128,256,512,1024,2048,4096 kdtrace 345 83K - 34348 64,256 kenv 84 12K - 95 16,32,64,128 kqueue 0 0K - 6914 256,512,2048,4096 proc-args 1 1K - 12608 16,32,64,128,256 hhook 2 1K - 2 256 kbdmux 6 18K - 6 16,512,1024,2048 ithread 107 18K - 107 32,128,256 LED 12 1K - 12 16,128 KTRACE 100 13K - 100 128 linker 358 418K - 474 16,32,64,128,256,512,1024,2048,4096 lockf 2 1K - 27002 64,128 loginclass 1 1K - 160 64 ip6ndp 8 1K - 9 64,128 temp 59 40K - 1349846 16,32,64,128,256,512,1024,2048,4096 devbuf 18078 36682K - 43760 16,32,64,128,256,512,1024,2048,4096 module 493 62K - 494 128 pci_link 16 2K - 16 64,128 mtx_pool 2 16K - 2 hdaa 21 37K - 21 256,512,1024,2048 hdac 2 2K - 2 512,1024 osd 2 1K - 2 16,64 hdacc 5 1K - 5 32 pmchooks 1 1K - 1 128 acpi_perf 8 2K - 8 256 subproc 286 217K - 9416 512,4096 proc 2 32K - 2 session 1 1K - 221 128 pgrp 1 1K - 292 128 cred 18 3K - 226696 64,256 uidinfo 4 5K - 215 128,4096 plimit 1 1K - 2379 256 sysctltmp 0 0K - 2950 16,32,64,128,4096 sysctloid 6638 331K - 6818 16,32,64,128 sysctl 0 0K - 48250 16,32,64 tidhash 1 32K - 1 callout 7 3584K - 7 umtx 1620 203K - 1620 128 p1003.1b 1 1K - 1 16 SWAP 2 549K - 2 64 bus-sc 134 446K - 6168 16,32,64,128,256,512,1024,2048,4096 bus 1417 125K - 9641 16,32,64,128,256,512,1024,2048 devstat 4 9K - 4 32,4096 eventhandler 90 8K - 91 64,128 feeder 39 5K - 24981 32,128 kobj 346 1384K - 1562 4096 CAM periph 6 2K - 19 16,32,64,128,256 Per-cpu 1 1K - 1 32 DEVFS1 121 61K - 144 512 DEVFS3 135 34K - 176 256 rman 259 30K - 681 16,32,128 sbuf 0 0K - 1848 16,32,64,128,256,512,1024,2048,4096 sglist 3 1K - 61 32,128,512,1024,2048 DEVFS_RULE 61 29K - 61 64,512 DEVFS 23 1K - 24 16,128 stack 0 0K - 2 256 taskqueue 23 2K - 23 16,32,128 Unitno 28 2K - 66610 32,64 iov 0 0K - 8029608 16,32,64,128,256,512 select 284 36K - 39683451 128,512 ioctlops 0 0K - 74167269 16,32,64,128,256,512,1024,2048 msg 4 30K - 4 2048,4096 sem 4 106K - 4 2048,4096 shm 1 20K - 273 2048 tty 17 17K - 30 1024,2048 pts 0 0K - 11 256 mbuf_tag 0 0K - 358 32,64,128 shmfd 1 8K - 1 DEVFSP 0 0K - 211 64 pcb 23 157K - 36351 16,32,64,128,1024,2048,4096 soname 0 0K - 62351 16,32,64,128 vfscache 1 2048K - 1 cl_savebuf 0 0K - 2050 64 vfs_hash 1 1024K - 1 msdosfs_node 0 0K - 1099319 256 vnodes 2 1K - 3 64,256 msdosfs_fileno 0 0K - 13032 64 mount 1 1K - 175 16,32,64,128,256 vnodemarker 0 0K - 5848 512 BPF 8 1K - 33 16,128,512,4096 ether_multi 19 1K - 164 16,32,64 ifaddr 337 26K - 395 32,64,128,256,512,4096 ifnet 8 15K - 9 128,2048 msdosfs_fat 0 0K - 1 clone 6 24K - 6 4096 arpcom 2 1K - 3 16 lltable 17 8K - 101 256,512 msdosfs_mount 0 0K - 1 512 routetbl 30 5K - 670 32,64,128,256,512 80211vap 1 4K - 2 4096 80211crypto 0 0K - 34 128,512 80211com 1 8K - 1 80211nodeie 0 0K - 231 32,128,256,512 80211node 2 17K - 26 1024 80211scan 2 6K - 52 512,2048,4096 igmp 7 2K - 8 256 in_multi 2 1K - 20 256 sctp_iter 0 0K - 24 256 sctp_ifn 1 1K - 18 128 sctp_ifa 3 1K - 20 128 sctp_vrf 1 1K - 1 64 sctp_a_it 0 0K - 24 16 hostcache 1 28K - 1 syncache 1 96K - 1 in6_multi 15 2K - 15 32,256 mld 7 1K - 8 128 NFS FHA 1 2K - 1 2048 rpc 2 1K - 2 256 audit_evclass 180 6K - 219 32 jblocks 0 0K - 2 128,256 savedino 0 0K - 8706 256 sbdep 0 0K - 945 64 jsegdep 0 0K - 106456 64 jseg 0 0K - 3654 128 jfreefrag 0 0K - 11616 128 jnewblk 0 0K - 69713 128 jmvref 0 0K - 5 128 jremref 0 0K - 4672 128 jaddref 0 0K - 20455 128 freedep 0 0K - 131 64 freework 1 1K - 5214 64,128 newdirblk 0 0K - 735 64 dirrem 0 0K - 4604 128 mkdir 0 0K - 1344 128 diradd 0 0K - 19111 128 freefile 0 0K - 2768 64 freeblks 0 0K - 2931 256 freefrag 0 0K - 11616 128 indirdep 0 0K - 336 128 newblk 1 128K - 69714 256 bmsafemap 1 8K - 19121 256 inodedep 1 1024K - 22306 512 pagedep 1 128K - 2560 256 ufs_dirhash 0 0K - 855 16,32,64,128,256,512,1024,2048 ufs_quota 1 1024K - 1 ufs_mount 0 0K - 3 512,4096 vm_pgdata 2 513K - 2 128 UMAHash 5 75K - 20 512,1024,2048,4096 pfs_nodes 21 6K - 21 256 pfs_vncache 0 0K - 126 64 GEOM 61 19K - 626 16,32,64,128,256,512,1024,2048 memdesc 1 4K - 2 4096 atkbddev 2 1K - 2 64 mixer 6 24K - 6 4096 acpiintr 1 1K - 1 64 acpica 8243 839K - 1356151 16,32,64,128,256,512,1024,2048,4096 acpitask 1 8K - 1 CAM dev queue 4 1K - 4 128 raid_data 0 0K - 78 32,128,256 md_nvidia_data 0 0K - 12 512 apmdev 1 1K - 1 128 madt_table 0 0K - 1 4096 acpisem 74 10K - 74 128 md_sii_data 0 0K - 12 512 CAM path 8 1K - 28 32 athdev 3 70K - 3 2048 io_apic 1 2K - 1 2048 CAM CCB 35 70K - 59473 2048 scsi_cd 0 0K - 14 16 MCA 18 3K - 18 64,128 msi 12 2K - 12 128 nexusdev 3 1K - 3 16 ath_hal 3 15K - 3 128,2048 CAM DEV 6 12K - 9 2048 CAM XPT 25 2K - 67 16,32,64,128,256,1024 CAM queue 17 1K - 45 16,32,64,512 acpivideo 3 1K - 3 128 linux 16 1K - 16 64 nvidia 202 935K - 639814 16,32,64,128,256,512,1024,2048,4096 iprtheap 23 56K - 23 32,64,128,256,2048 tmpfs name 0 0K - 6536 16,32,64 tmpfs mount 0 0K - 1 128 netgraph_node 11 3K - 23 128,256 netgraph_hook 10 2K - 10 128 netgraph_msg 0 0K - 40 64,128,256,1024 netgraph 2 1K - 3 64 netgraph_hci 1 1K - 1 256 netgraph_l2cap 1 1K - 1 128 netgraph_btsocks_hci_raw 1 8K - 23 128 netgraph_btsocks_l2cap_raw 1 1K - 1 32 netgraph_btsocks_l2cap 1 1K - 1 32 netgraph_sock 0 0K - 18 128 netgraph_path 0 0K - 11 16 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 208, 0, 92, 10, 94, 0, 0 UMA Zones: 1408, 0, 92, 2, 94, 0, 0 UMA Slabs: 568, 0, 10459, 97, 19937, 0, 0 UMA RCntSlabs: 568, 0, 1192, 5, 1192, 0, 0 UMA Hash: 256, 0, 0, 15, 5, 0, 0 16 Bucket: 152, 0, 214, 11, 214, 0, 0 32 Bucket: 280, 0, 254, 26, 273, 0, 0 64 Bucket: 536, 0, 299, 2, 306, 98, 0 128 Bucket: 1048, 0, 3429, 0, 6281,16433, 0 VM OBJECT: 232, 0, 345, 33927, 229245, 0, 0 MAP: 240, 0, 8, 24, 8, 0, 0 KMAP ENTRY: 128, 166460, 196, 2414, 122830, 0, 0 MAP ENTRY: 128, 0, 9, 14549, 568727, 0, 0 fakepg: 120, 0, 3, 5918, 7691, 0, 0 mt_zone: 4112, 0, 346, 123, 350, 0, 0 16: 16, 0, 3046, 986,74761134, 0, 0 32: 32, 0, 3455, 8059, 712086, 0, 0 64: 64, 0, 13841, 49999, 4178119, 0, 0 128: 128, 0, 11100, 20771, 5089322, 0, 0 256: 256, 0, 878, 56497, 1443440, 0, 0 512: 512, 0, 734, 15352,39729872, 0, 0 1024: 1024, 0, 67, 425, 299717, 0, 0 2048: 2048, 0, 107, 429, 1191580, 0, 0 4096: 4096, 0, 436, 375, 21682, 0, 0 Files: 80, 0, 0, 3375, 372975, 0, 0 rl_entry: 40, 0, 247, 509, 247, 0, 0 TURNSTILE: 136, 0, 811, 129, 811, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1192, 0, 20, 244, 9149, 0, 0 THREAD: 1160, 0, 323, 487, 25197, 0, 0 SLEEPQUEUE: 80, 0, 811, 175, 811, 0, 0 VMSPACE: 400, 0, 1, 305, 9131, 0, 0 cpuset: 72, 0, 82, 118, 82, 0, 0 audit_record: 960, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 1570260, 296, 1375, 2865471, 0, 0 mbuf: 256, 1570260, 1, 2310, 9208464, 0, 0 mbuf_cluster: 2048, 51200, 1664, 88, 1673, 0, 0 mbuf_jumbo_page: 4096, 122676, 0, 316, 391598, 0, 0 mbuf_jumbo_9k: 9216, 109044, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 81784, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 ttyinq: 160, 0, 0, 864, 1305, 0, 0 ttyoutq: 256, 0, 0, 495, 679, 0, 0 g_bio: 248, 0, 0, 7140, 460674, 0, 0 ata_request: 328, 0, 0, 0, 0, 0, 0 ata_composite: 336, 0, 0, 0, 0, 0, 0 vtnet_tx_hdr: 24, 0, 0, 0, 0, 0, 0 nv_stack_t: 12288, 0, 2, 149, 60029, 0, 0 FPU_save_area: 512, 0, 0, 0, 0, 0, 0 VNODE: 504, 0, 8, 61064, 1153701, 0, 0 VNODEPOLL: 112, 0, 1, 824, 670, 0, 0 NAMEI: 1024, 0, 0, 176, 1943649, 0, 0 S VFS Cache: 108, 0, 0, 44748, 1145973, 0, 0 STS VFS Cache: 148, 0, 0, 0, 0, 0, 0 L VFS Cache: 328, 0, 0, 20760, 36620, 0, 0 LTS VFS Cache: 368, 0, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 0, 1592, 1552, 0, 0 NCLNODE: 568, 0, 0, 0, 0, 0, 0 pipe: 728, 0, 0, 330, 5552, 0, 0 Mountpoints: 824, 0, 1, 11, 5, 0, 0 ksiginfo: 112, 0, 253, 869, 554822, 0, 0 itimer: 344, 0, 0, 22, 1, 0, 0 KNOTE: 128, 0, 0, 1334, 2259530, 0, 0 socket: 680, 25002, 1, 2531, 70473, 0, 0 ipq: 56, 1638, 0, 0, 0, 0, 0 udp_inpcb: 392, 25000, 0, 180, 42021, 0, 0 udpcb: 16, 25032, 0, 1176, 42021, 0, 0 tcp_inpcb: 392, 25000, 11, 6899, 26699, 0, 0 tcpcb: 976, 25000, 1, 2287, 26699, 0, 0 tcptw: 72, 5000, 10, 4990, 7051,2843, 0 syncache: 152, 15375, 0, 75, 3, 0, 0 hostcache: 136, 15372, 44, 264, 216, 0, 0 tcpreass: 40, 3276, 0, 1008, 15743, 0, 0 sackhole: 32, 0, 0, 606, 15, 0, 0 sctp_ep: 1384, 25000, 0, 0, 0, 0, 0 sctp_asoc: 2288, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80064, 0, 648, 36, 0, 0 sctp_raddr: 704, 80000, 0, 0, 0, 0, 0 sctp_chunk: 136, 400008, 0, 0, 0, 0, 0 sctp_readq: 104, 400032, 0, 0, 0, 0, 0 sctp_stream_msg_out: 104, 400032, 0, 0, 0, 0, 0 sctp_asconf: 40, 400008, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400032, 0, 0, 0, 0, 0 ripcb: 392, 25000, 0, 50, 6, 0, 0 unpcb: 240, 25008, 0, 560, 1624, 0, 0 rtentry: 200, 0, 12, 178, 63, 0, 0 selfd: 56, 0, 312, 2334,796151112, 0, 0 SWAPMETA: 288, 490711, 0, 0, 0, 0, 0 FFS inode: 168, 0, 0, 32890, 47594, 0, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 0, 33195, 47577, 0, 0 NetGraph items: 72, 4118, 0, 174, 61, 0, 0 NetGraph data items: 72, 522, 0, 232, 54, 0, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq1: atkbd0 51855 850 irq9: acpi0 35884 588 irq12: psm0 587513 9631 irq16: vgapci0+ 1330731 21815 irq17: hdac0 ath0 3111095 51001 irq23: ehci1 64593 1058 irq256: hpet0:t0 2816317 46169 irq257: hpet0:t1 1605139 26313 irq258: hpet0:t2 1433495 23499 irq259: hpet0:t3 1462408 23973 irq260: hpet0:t4 1398251 22922 irq261: hpet0:t5 1728670 28338 irq262: hpet0:t6 1336809 21914 irq263: hpet0:t7 1774032 29082 irq264: hdac1 685780 11242 irq267: ahci0 165719 2716 Total 19588291 321119 ------------------------------------------------------------------------ pstat -T 0/25000 files 0M/4095M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/ada0s2b 8388328 0 8388328 0% ------------------------------------------------------------------------ iostat iostat: kvm_read(_tk_nin): invalid address (0x0) iostat: disabling TTY statistics ada0 cd0 pass0 cpu KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 29.56 1982 57.22 0.00 1 0.00 0.00 0 0.00 2 0 1 0 98 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME m 65536 1346981710 --rw-rw-rw- noip noip noip noip 0 2016 1268 1268 8:23:38 16:39:49 8:23:38 Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 536870912 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 131072 (max amount of shared memory in pages) seminfo: semmni: 50 (# of semaphore identifiers) semmns: 340 (# of semaphores in system) semmnu: 150 (# of undo structures in system) semmsl: 340 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 50 (max # of undo entries per process) semusz: 632 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat Client Info: Rpc Counts: Getattr Setattr Lookup Readlink Read Write Create Remove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 0 Cache Info: Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Misses 0 0 0 0 0 0 0 0 BioRLHits Misses BioD Hits Misses DirE Hits Misses Accs Hits Misses 0 0 0 0 0 0 0 0 Server Info: Getattr Setattr Lookup Readlink Read Write Create Remove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Server Ret-Failed 0 Server Faults 0 Server Cache Stats: Inprog Idem Non-idem Misses 0 0 0 0 Server Write Gathering: WriteOps WriteRPC Opsaved 0 0 0 ------------------------------------------------------------------------ netstat -s tcp: 752845 packets sent 251576 data packets (313594956 bytes) 4061 data packets (495649 bytes) retransmitted 256 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 445730 ack-only packets (70132 delayed) 0 URG only packets 0 window probe packets 12508 window update packets 39105 control packets 860777 packets received 135529 acks (for 313557933 bytes) 13083 duplicate acks 0 acks for unsent data 734462 packets (791313065 bytes) received in-sequence 3285 completely duplicate packets (1277277 bytes) 0 old duplicate packets 80 packets with some dup. data (65068 bytes duped) 15743 out-of-order packets (11042428 bytes) 0 packets (0 bytes) of data after window 0 window probes 811 window update packets 198 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 26573 connection requests 3 connection accepts 0 bad connection attempts 0 listen queue overflows 1 ignored RSTs in the window 12510 connections established (including accepts) 26688 connections closed (including 162 drops) 1301 connections updated cached RTT on close 1305 connections updated cached RTT variance on close 659 connections updated cached ssthresh on close 3 embryonic connections dropped 87017 segments updated rtt (of 101196 attempts) 22561 retransmit timeouts 83 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 40669 correct ACK header predictions 691330 correct data packet header predictions 3 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 3 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 3 cookies sent 0 cookies received 216 hostcache entries added 0 bucket overflow 53 SACK recovery episodes 26 segment rexmits in SACK recovery episodes 30228 byte rexmits in SACK recovery episodes 508 SACK options (SACK blocks) received 11164 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 49355 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 54 dropped due to no socket 45655 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 3646 delivered 3721 datagrams output 0 times multicast source filter matched ip: 912283 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 911991 packets for this host 190 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 102 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 759228 packets sent from this host 12 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 51 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 50 calls to icmp_error 0 errors not generated in response to an icmp message Output histogram: echo reply: 1853 destination unreachable: 50 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored Input histogram: echo reply: 6 destination unreachable: 194 echo: 1853 1853 message responses generated 0 invalid return addresses 0 no return routes igmp: 0 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 0 V1/V2 membership queries received 0 V3 membership queries received 0 membership queries received with invalid field(s) 0 general queries received 0 group queries received 0 group-source queries received 0 group-source queries dropped 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 0 membership reports sent arp: 77 ARP requests sent 567 ARP replies sent 42261 ARP requests received 60 ARP replies received 42362 ARP packets received 35 total packets dropped due to no ARP entry 0 ARP entrys timed out 0 Duplicate IPs seen ip6: 8 total packets received 0 with size smaller than minimum 0 with data size < data length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 fragments that exceeded limit 0 packets reassembled ok 4 packets for this host 0 packets forwarded 0 packets not forwardable 0 redirects sent 8 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 9414 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 packets that violated scope rules 0 multicast packets which we don't join Input histogram: UDP: 4 ICMP6: 4 Mbuf statistics: 8 one mbuf 0 one ext mbuf 0 two or more ext mbuf 0 packets whose headers are not contiguous 0 tunneling packets that can't find gif 0 packets discarded because of too many headers 4 failures of source address selection source addresses on a non-outgoing I/F 4 addresses scope=f Source addresses selection rule applied: 4 same address icmp6: 4 calls to icmp6_error 0 errors not generated in response to an icmp6 message 0 errors not generated because of rate limitation Output histogram: unreach: 4 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Input histogram: unreach: 4 Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 0 address unreachable 4 port unreachable 0 packet too big 0 time exceed transit 0 time exceed reassembly 0 erroneous header field 0 unrecognized next header 0 unrecognized option 0 redirect 0 unknown 0 message responses generated 0 messages with too many ND options 0 messages with bad ND options 0 bad neighbor solicitation messages 0 bad neighbor advertisement messages 0 bad router solicitation messages 0 bad router advertisement messages 0 bad redirect messages 0 path MTU changes rip6: 0 messages received 0 checksum calculations on inbound 0 messages with bad checksum 0 messages dropped due to no socket 0 multicast messages dropped due to no socket 0 messages dropped due to full socket buffers 0 delivered 0 datagrams output ------------------------------------------------------------------------ netstat -m 297/3685/3982 mbufs in use (current/cache/total) 289/1463/1752/51200 mbuf clusters in use (current/cache/total/max) 296/1375 mbuf+clusters out of packet secondary zone in use (current/cache) 0/316/316/122676 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/109044 9k jumbo clusters in use (current/cache/total/max) 0/0/0/81784 16k jumbo clusters in use (current/cache/total/max) 652K/5111K/5763K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines ------------------------------------------------------------------------ netstat -id Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop usbus 0 0 0 0 0 0 0 0 ath0* 2290 48:5d:60:5f:96:e6 1615847 405364 0 750995 1 0 10154 usbus 0 0 0 0 0 0 0 0 alc0 1500 48:5b:39:9b:e8:e0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 lo0 16384 42 0 0 42 0 0 0 lo0 16384 localhost ::1 8 - - 8 - - - lo0 16384 fe80::1%lo0 fe80::1 0 - - 0 - - - lo0 16384 your-net localhost 34 - - 34 - - - wlan0 1500 48:5d:60:5f:96:e6 628035 0 0 558364 42 0 0 wlan0 1500 192.168.5.0 192.168.5.31 128051 - - 208325 - - - ------------------------------------------------------------------------ netstat -anr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.5.1 UGS 0 207921 wlan0 127.0.0.1 link#6 UH 0 34 lo0 192.168.5.31 link#7 UHS 0 0 lo0 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 ::1 link#6 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 fe80::/10 ::1 UGRS lo0 fe80::%lo0/64 link#6 U lo0 fe80::1%lo0 link#6 UHS lo0 ff01::%lo0/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%lo0/32 ::1 U lo0 ------------------------------------------------------------------------ netstat -anA Active Internet connections (including servers) Tcpcb Proto Recv-Q Send-Q Local Address Foreign Address (state) fffffe013ed256c0 tcp4 0 0 192.168.5.31.19965 195.24.233.55.80 TIME_WAIT fffffe013ed25798 tcp4 0 0 192.168.5.31.52863 193.53.106.102.80 TIME_WAIT fffffe013c1ca4c8 tcp4 0 0 192.168.5.31.32887 178.253.195.26.443 TIME_WAIT fffffe013ed25750 tcp4 0 0 192.168.5.31.23173 178.253.195.24.443 TIME_WAIT fffffe013c1ca510 tcp4 0 0 192.168.5.31.25802 178.253.195.23.443 TIME_WAIT fffffe0011adc000 tcp4 0 0 192.168.5.31.30589 157.249.32.164.80 LAST_ACK fffffe013ed51090 tcp4 0 0 192.168.5.31.62822 193.53.106.14.22 TIME_WAIT fffffe013ed51048 tcp4 0 0 192.168.5.31.62149 193.53.106.102.22 TIME_WAIT fffffe013ed4a1b0 tcp4 0 0 192.168.5.31.15190 83.176.244.163.448 TIME_WAIT fffffe013c1ca480 tcp4 0 0 192.168.5.31.65493 193.53.106.102.22 TIME_WAIT fffffe013ed25708 tcp4 0 0 192.168.5.31.52076 178.170.121.156.41 TIME_WAIT ------------------------------------------------------------------------ netstat -aL Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address ------------------------------------------------------------------------ fstat USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root ng_queue 811 root - - bad - root ng_queue 811 wd - - bad - root init 1 root - - bad - root init 1 wd - - bad - root init 1 text - - bad - root kernel 0 root - - bad - root kernel 0 wd - - bad - ------------------------------------------------------------------------ dmesg Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.2-PRERELEASE #0 r254557: Sun Aug 25 22:44:52 CEST 2013 pacija@kaa.mimar.rs:/usr/obj/usr/src/sys/KAAGEN amd64 gcc version 4.2.1 20070831 patched [FreeBSD] CPU: Intel(R) Core(TM) i7 CPU Q 740 @ 1.73GHz (1729.04-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106e5 Family = 0x6 Model = 0x1e Stepping = 5 Features=0xbfebfbff Features2=0x98e3fd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3989553152 (3804 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <_ASUS_ Notebook> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ACPI Warning: 32/64X FACS address mismatch in FADT - 0xBB5B3F40/0x00000000BB5CDD40, using 32 (20110527/tbfadt-517) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <_ASUS_ Notebook> on motherboard acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 3.0 on pci0 pci1: on pcib1 vgapci0: port 0xd000-0xd07f mem 0xd2000000-0xd2ffffff,0xc0000000-0xcfffffff,0xd0000000-0xd1ffffff irq 16 at device 0.0 on pci1 acpi_video0: on vgapci0 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io hdac0: mem 0xd3080000-0xd3083fff irq 17 at device 0.1 on pci1 pci0: at device 8.0 (no driver attached) pci0: at device 8.1 (no driver attached) pci0: at device 8.2 (no driver attached) pci0: at device 8.3 (no driver attached) pci0: at device 16.0 (no driver attached) pci0: at device 16.1 (no driver attached) pci0: at device 22.0 (no driver attached) ehci0: mem 0xd9608000-0xd96083ff irq 16 at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0 on ehci0 hdac1: mem 0xd9600000-0xd9603fff irq 22 at device 27.0 on pci0 pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 17 at device 28.1 on pci0 pci3: on pcib3 ath0: mem 0xd6e00000-0xd6e0ffff irq 17 at device 0.0 on pci3 ath0: AR9285 mac 192.2 RF5133 phy 14.0 pcib4: irq 19 at device 28.3 on pci0 pci4: on pcib4 xhci0: mem 0xd5a00000-0xd5a0ffff irq 19 at device 0.0 on pci4 xhci0: 32 byte context size. usbus1 on xhci0 pcib5: irq 16 at device 28.4 on pci0 pci5: on pcib5 pcib6: irq 17 at device 28.5 on pci0 pci6: on pcib6 alc0: port 0x8000-0x807f mem 0xd3200000-0xd323ffff irq 17 at device 0.0 on pci6 alc0: 15872 Tx FIFO, 15360 Rx FIFO alc0: Using 1 MSI message(s). miibus0: on alc0 atphy0: PHY 0 on miibus0 atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow alc0: Ethernet address: 48:5b:39:9b:e8:e0 ehci1: mem 0xd9607000-0xd96073ff irq 23 at device 29.0 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci1 pcib7: at device 30.0 on pci0 pci7: on pcib7 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xe070-0xe077,0xe060-0xe063,0xe050-0xe057,0xe040-0xe043,0xe020-0xe03f mem 0xd9606000-0xd96067ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 4 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich5: at channel 5 on ahci0 pcib8: on acpi0 pci255: on pcib8 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_tz0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 est1: on cpu1 est2: on cpu2 est3: on cpu3 est4: on cpu4 est5: on cpu5 est6: on cpu6 est7: on cpu7 Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x4ec offMax=0x6ff hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 5 on hdaa0 hdacc1: at cad 1 on hdac0 hdaa1: at nid 1 on hdacc1 pcm1: at nid 5 on hdaa1 hdacc2: at cad 2 on hdac0 hdaa2: at nid 1 on hdacc2 pcm2: at nid 5 on hdaa2 hdacc3: at cad 3 on hdac0 hdaa3: at nid 1 on hdacc3 pcm3: at nid 5 on hdaa3 hdacc4: at cad 0 on hdac1 hdaa4: at nid 1 on hdacc4 pcm4: at nid 27,33 and 24,25 on hdaa4 pcm5: at nid 30 on hdaa4 usbus0: 480Mbps High Speed USB v2.0 usbus1: 5.0Gbps Super Speed USB v3.0 usbus2: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: <0x1b73> at usbus1 uhub1: <0x1b73 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 610480MB (1250263728 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #6 Launched! Timecounter "TSC" frequency 1729039384 Hz quality 1000 uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus2 usbus0 uhub0: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered Root mount waiting for: usbus2 usbus0 ugen0.2: at usbus0 uhub3: on usbus0 ugen2.2: at usbus2 uhub4: on usbus2 Root mount waiting for: usbus2 usbus0 uhub3: 6 ports with 6 removable, self powered uhub4: 8 ports with 8 removable, self powered ugen0.3: at usbus0 ugen0.4: at usbus0 Root mount waiting for: usbus0 Trying to mount root from ufs:/dev/ada0s2a [rw]... Setting hostuuid: 0009d6cf-5000-8009-ffff-485b399be8e0. Setting hostid: 0x4538276e. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/ada0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0s2a: clean, 5494310 free (158646 frags, 666958 blocks, 1.4% fragmentation) /dev/ada0s3: FILESYSTEM CLEAN; SKIPPING CHECKS Mounting local file systems:. Setting hostname: kaa.mimar.rs. wlan0: Ethernet address: 48:5d:60:5f:96:e6 Starting wpa_supplicant. Starting Network: lo0 ath0 alc0. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 ath0: flags=8843 metric 0 mtu 2290 ether 48:5d:60:5f:96:e6 nd6 options=29 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated alc0: flags=8843 metric 0 mtu 1500 options=c3198 ether 48:5b:39:9b:e8:e0 nd6 options=29 media: Ethernet autoselect (none) status: no carrier Starting devd. ubt0: on usbus0 Starting dhclient. DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPNAK from 192.168.5.18 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6 DHCPOFFER from 192.168.5.18 DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPACK from 192.168.5.18 bound to 192.168.5.31 -- renewal in 1800 seconds. WARNING: attempt to domain_add(bluetooth) after domainfinalize() WARNING: attempt to domain_add(netgraph) after domainfinalize() add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/kde4/lib /usr/local/lib/alsa-lib /usr/local/lib/event2 /usr/local/lib/ffmpeg1 /usr/local/lib/gegl-0.2 /usr/local/lib/graphviz /usr/local/lib/nss /usr/local/lib/pth /usr/local/lib/qt4 /usr/local/lib/virtualbox 32-bit compatibility ldconfig path: /usr/lib32 Creating and/or trimming log files. Starting syslogd. No core dumps found. Additional ABI support: linux. Clearing /tmp (X related). Recovering vi editor sessions:. Updating motd:. Starting fusefs. fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.19 Starting ntpd. Starting powerd. Starting tftpd. Starting noip. Starting dbus. Starting hald. Configuring syscons: keymap blanktime. Performing sanity check on sshd configuration. Starting sshd. Starting cron. Starting background file system checks in 60 seconds. Tue Sep 10 08:23:41 CEST 2013 Sep 10 08:24:26 kaa dbus[1275]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.16" (uid=1001 pid=1483 comm="nautilus --sm-client-id 25bdad1e0-0659-11e3-bd1e-4") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination=":1.1" (uid=0 pid=1296 comm="/usr/local/sbin/console-kit-daemon --no-daemon ") Sep 10 08:32:27 kaa gnome-keyring-daemon[1562]: couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files Sep 10 08:32:27 kaa gnome-keyring-daemon[1562]: couldn't allocate secure memory to keep passwords and or keys from being written to the disk Sep 10 08:33:11 kaa gnome-keyring-prompt: couldn't allocate secure memory to keep passwords and or keys from being written to the disk Sep 10 08:33:11 kaa gnome-keyring-daemon[1562]: ** Message: couldn't allocate secure memory to keep passwords and or keys from being written to the disk Sep 10 08:54:38 kaa noip2[1268]: Can't get our visible IP address from ip1.dynupdate.no-ip.com wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN Sep 10 09:43:15 kaa ntpd[1238]: sendto(195.83.66.158) (fd=25): Network is down wlan0: link state changed to UP wlan0: link state changed to DOWN Sep 10 11:21:30 kaa ntpd[1238]: sendto(195.83.66.158) (fd=25): Network is down wlan0: link state changed to UP wlan0: link state changed to DOWN ath0: device timeout Sep 10 11:22:33 kaa dhclient[843]: connection closed Sep 10 11:22:33 kaa dhclient[843]: exiting. wlan0: Ethernet address: 48:5d:60:5f:96:e6 wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP ath0: bb hang detected (0x4), resetting wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP Sep 10 16:39:46 kaa shutdown: power-down by root: Stopping cron. Waiting for PIDS: 1333. Stopping sshd. Waiting for PIDS: 1322. Stopping tftpd. Waiting for PIDS: 1260. Stopping powerd. Waiting for PIDS: 1241. Stopping ntpd. Waiting for PIDS: 1238. Stopping fusefs. Stopping devd. Waiting for PIDS: 929. Writing entropy file:. . Terminated wlan0: link state changed to DOWN Sep 10 16:39:49 kaa syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop...Syncing disks, vnodes remaining...8 8 4 1 1 1 0 0 done All buffers synced. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x9 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80b71085 stack pointer = 0x28:0xffffff800026a9e0 frame pointer = 0x28:0xffffff800026aa60 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 = 1 (init) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xffffffff80948356 at kdb_backtrace+0x66 #1 0xffffffff8090deae at panic+0x1ce #2 0xffffffff80cf2c00 at trap_fatal+0x290 #3 0xffffffff80cf2f61 at trap_pfault+0x211 #4 0xffffffff80cf3514 at trap+0x344 #5 0xffffffff80cdc843 at calltrap+0x8 #6 0xffffffff80b715e5 at swapoff_all+0xc5 #7 0xffffffff8090dca5 at kern_reboot+0x805 #8 0xffffffff8090e06c at sys_reboot+0x6c #9 0xffffffff80cf23aa at amd64_syscall+0x5ea #10 0xffffffff80cdcb27 at Xfast_syscall+0xf7 Uptime: 8h16m49s Dumping 417 out of 3984 MB:..4%..12%..23%..31%..43%..54%..62%..73%..81%..92% ------------------------------------------------------------------------ kernel config options CONFIG_AUTOGENERATED ident GENERIC machine amd64 cpu HAMMER makeoptions WITH_CTF=1 makeoptions DEBUG=-g options USB_DEBUG options RDRAND_RNG options PADLOCK_RNG options AH_SUPPORT_AR5416 options IEEE80211_SUPPORT_MESH options IEEE80211_AMPDU_AGE options IEEE80211_DEBUG options SC_PIXEL_MODE options VESA options AHD_REG_PRETTY_PRINT options AHC_REG_PRETTY_PRINT options ATA_STATIC_ID options ATA_CAM options SMP options DDB_CTF options KDB_TRACE options KDB options INCLUDE_CONFIG_FILE options KDTRACE_HOOKS options KDTRACE_FRAME options MAC options AUDIT options HWPMC_HOOKS options KBD_INSTALL_CDEV options PRINTF_BUFR_SIZE=128 options _KPOSIX_PRIORITY_SCHEDULING options SYSVSEM options SYSVMSG options SYSVSHM options STACK options KTRACE options SCSI_DELAY=5000 options COMPAT_FREEBSD7 options COMPAT_FREEBSD6 options COMPAT_FREEBSD5 options COMPAT_FREEBSD4 options COMPAT_FREEBSD32 options GEOM_LABEL options GEOM_RAID options GEOM_PART_GPT options PSEUDOFS options PROCFS options CD9660 options MSDOSFS options NFS_ROOT options NFSLOCKD options NFSD options NFSCL options MD_ROOT options QUOTA options UFS_GJOURNAL options UFS_DIRHASH options UFS_ACL options SOFTUPDATES options FFS options SCTP options TCP_OFFLOAD options INET6 options INET options PREEMPTION options SCHED_ULE options NEW_PCIB options GEOM_PART_MBR options GEOM_PART_EBR_COMPAT options GEOM_PART_EBR options GEOM_PART_BSD device isa device mem device io device uart_ns8250 device cpufreq device acpi device pci device fdc device ahci device ata device mvs device siis device ahc device ahd device esp device hptiop device isp device mpt device mps device sym device trm device adv device adw device aic device bt device isci device scbus device ch device da device sa device cd device pass device ses device amr device arcmsr device ciss device dpt device hptmv device hptnr device hptrr device hpt27xx device iir device ips device mly device twa device tws device aac device aacp device aacraid device ida device mfi device mlx device twe device atkbdc device atkbd device psm device kbdmux device vga device splash device sc device agp device cbb device pccard device cardbus device uart device ppc device ppbus device lpt device plip device ppi device puc device bxe device de device em device igb device ixgbe device le device ti device txp device vx device miibus device ae device age device alc device ale device bce device bfe device bge device cas device dc device et device fxp device gem device hme device jme device lge device msk device nfe device nge device pcn device re device rl device sf device sge device sis device sk device ste device stge device tl device tx device vge device vr device wb device xl device cs device ed device ex device ep device fe device sn device xe device wlan device wlan_wep device wlan_ccmp device wlan_tkip device wlan_amrr device an device ath device ath_pci device ath_hal device ath_rate_sample device ipw device iwi device iwn device malo device mwl device ral device wi device wpi device loop device random device ether device vlan device tun device pty device md device gif device faith device firmware device bpf device uhci device ohci device ehci device xhci device usb device uhid device ukbd device ulpt device umass device ums device urio device u3g device uark device ubsa device uftdi device uipaq device uplcom device uslcom device uvisor device uvscom device aue device axe device cdce device cue device kue device rue device udav device rum device run device uath device upgt device ural device urtw device zyd device sound device snd_cmi device snd_csa device snd_emu10kx device snd_es137x device snd_hda device snd_ich device snd_uaudio device snd_via8233 device virtio device virtio_pci device vtnet device virtio_blk device virtio_scsi device virtio_balloon ------------------------------------------------------------------------ ddb capture buffer ddb: ddb_capture: kvm_nlist -- Marko Cupać From owner-freebsd-stable@FreeBSD.ORG Tue Sep 10 18:36:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 47D4BD76 for ; Tue, 10 Sep 2013 18:36:04 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 00916210F for ; Tue, 10 Sep 2013 18:36:03 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VJSn5-0008BS-RX for freebsd-stable@freebsd.org; Tue, 10 Sep 2013 20:35:55 +0200 Received: from dslb-088-073-173-072.pools.arcor-ip.net ([88.73.173.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Sep 2013 20:35:55 +0200 Received: from jsteckli by dslb-088-073-173-072.pools.arcor-ip.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Sep 2013 20:35:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Julian Stecklina Subject: Re: Intel 10Gb network card Date: Tue, 10 Sep 2013 20:35:45 +0200 Lines: 6 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: dslb-088-073-173-072.pools.arcor-ip.net User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 In-Reply-To: X-Enigmail-Version: 1.5.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Sep 2013 18:36:04 -0000 On 09/04/2013 08:25 AM, Daniel Braniss wrote: > Q: does the copper (10G Based T) version work? Works fine for me. Julian From owner-freebsd-stable@FreeBSD.ORG Tue Sep 10 19:36:19 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8C37040A for ; Tue, 10 Sep 2013 19:36:19 +0000 (UTC) (envelope-from Mark.Lawrence@jewbilation.org) Received: from noah.jewbilation.com (u16565493.onlinehome-server.com [74.208.153.146]) by mx1.freebsd.org (Postfix) with ESMTP id 5446625E8 for ; Tue, 10 Sep 2013 19:36:18 +0000 (UTC) Received: from [192.168.1.134] (cpe-74-64-120-74.nyc.res.rr.com [74.64.120.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: Mark.Lawrence@Jewbilation.org) by noah.jewbilation.com (Postfix) with ESMTPSA id 462854F3 for ; Tue, 10 Sep 2013 15:27:25 -0400 (EDT) Message-ID: <522F729A.7070602@jewbilation.org> Date: Tue, 10 Sep 2013 15:27:22 -0400 From: Mark Lawrence User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stable@freebsd.org Subject: Jewbilation Party Planning/Wedding/Event Directory: Free Listing Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Sep 2013 19:36:19 -0000 Hello, Jewbilation is one of the fastest growing directories and marketplaces for party planning, weddings, and more targeting the Jewish community, and includes a growing directory of everything from helping to find vendors for parties/events/entertainment to gifts for holidays and other events. We wanted to give you a */free/* opportunity to list and be promoted on our site for one year and appear in our growing directory including party planner, temples/synagogues, day camps, and more; or marketplace which already has over 5000 items listed! We hope to show you how we can help promote you to this specific market. We don't even take payment info, this is a /*free */trial as we continue to grow into one of the leading sites for our niche market. Already, we are one of the largest and this is an opportunity for us to help promote your company and you to see the value of our site. Anyone can sign up, and we can help plug your firm or organization into this niche market. We are providing this free trial to select vendors (the cost is normally only $99 per year)! As part of our model we donate a percent of our profits to charity. http://jewbilation.com/vendor/register_service_vendor?promo=MLW13FANDF Product vendors who sell actual items/gifts can sign up here: http://products.jewbilation.com/index.php?dispatch=companies.apply_for_vendor Jewbilation is unique in its foundation, in that it is positioned to capture and aggregate the diaspora of retailers, services and vendors that support and cater to the Jewish community and party planning community at large. Any vendor (party planner, caterer, venue, florist) can join. If interested you can go ahead and sign up here: http://jewbilation.com/vendor/register_service_vendor?promo=MLW13FANDF This offer will expire soon! Additionally, you can view our full website here at: www.jewbilation.com . If you know other vendors who may be interested please feel free to pass on our information. We're sorry if this reached you in error. We hope you decide to join. To unsubscribe click here . We apologize if this email reached you in error, and wanted to reach out once more to give you a free trial offer. The unsubscribe link is now working, and we sincerely apologize again if this reached you in error or multiple times. From owner-freebsd-stable@FreeBSD.ORG Wed Sep 11 00:09:49 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 329B1B1D for ; Wed, 11 Sep 2013 00:09:49 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm9-vm8.bullet.mail.gq1.yahoo.com (nm9-vm8.bullet.mail.gq1.yahoo.com [98.136.218.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CE86B283C for ; Wed, 11 Sep 2013 00:09:47 +0000 (UTC) Received: from [98.137.12.62] by nm9.bullet.mail.gq1.yahoo.com with NNFMP; 11 Sep 2013 00:09:40 -0000 Received: from [98.136.164.67] by tm7.bullet.mail.gq1.yahoo.com with NNFMP; 11 Sep 2013 00:09:40 -0000 Received: from [127.0.0.1] by smtp229.mail.gq1.yahoo.com with NNFMP; 11 Sep 2013 00:09:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1378858180; bh=HKQdpB7ompssXJfMgriKQ48WnS4O3qjwL+x0gfD54yk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=jXSoQq/w6UA6hahd0iRTIXXF7TUSCjpuQxdAOgK/BlHF97pY6SgEiZ9xa+99/sXIPp18K3R39yN3xpIxReZQcV1efKO12RJnBsG6YmGOYFWJEEef+HB5BqfrrorQY7WbpGNU1V91QVw6rHkTnhNb1DQCJIYK25Gom6fA/7JkJTg= X-Yahoo-Newman-Id: 957343.48944.bm@smtp229.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: oE2fvUQVM1no8HXG4AwRGAHZiXuOjCt2JNEzH5hS7V6RXo8 ZKryuypVnx2WQNn_Fd3pJAfrrazBGccO1qjRkOb08cR08tEzhJ8lVqNDgSwS KW2dPkdaj.sM8pLeOgs5pM.iM0F9fiobf9fTlSEhI8S6g5j3XPvevn7ZBO3M 85Ygqw9J44Jd7JNUm8wh2STzPvBq83h.iukkHh0iNys8GPE1D0_j6XpNrsft l9lBh5OKJLUo2kLMRxtiHF.Gba1mB5AXJn2mP00oSbqkDHs7AuUiGqEENtxf QOV2ISXCEGV_HVQpgq_5_0s5f9Pm63uwgXRooaRqmV17G.ByCOpuXY1cmHEE AbI1lsUPKnGFIsliyXn5mekFqe70ZHJXwdsfUjFXjsaDTaKXTPGeaZpIPe3t tfZIYwTrQUvVC5PPwmjjPw_CjihePNPNfB9w4i4a7d93B_973BPP3B_utSou MezPgjZ_Qf539ckU5E2AphyavVfjdqlPKLz8e3BYE9KM90yWPPQ7pRQzdSN8 scaarpeIxDLL1pCa7fYamEXVHln3XsuEhng-- X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with ) by smtp229.mail.gq1.yahoo.com with SMTP; 11 Sep 2013 00:09:40 +0000 UTC Subject: Re: Intel 10Gb network card From: Sean Bruno To: Daniel Braniss In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-L7Lz/jKMch1jLNuYAU6+" Date: Tue, 10 Sep 2013 17:09:40 -0700 Message-ID: <1378858180.95925.33.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: "stable@freebsd.org" , Luigi Rizzo , Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 00:09:49 -0000 --=-L7Lz/jKMch1jLNuYAU6+ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Wed, 2013-09-04 at 09:25 +0300, Daniel Braniss wrote: > no man ix, no mention of /dev/ix%d in man ixgbe If you have a moment, can you submit a diff on this fact? It seems REALLY confusing to me. Sean --=-L7Lz/jKMch1jLNuYAU6+ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJSL7TEAAoJEBkJRdwI6BaHNxIH/RrvmEsglPZhThZl9VCom7ll aqeEnwmNOglDwkepQ4jH/ZOS/x+Yreuj8FUpRMW2X6qK4OQAdgZwQhjAuGZHl2oS eM7tq6v6YLc7XMSTkNXxviUPX05deQA6ZKSt5t7c1tDIH+yJcniiqu2u2qqY0aev IB6p7fNoxSt5wSDoWwEcAEcobdIF5afbeBgplWFa03uaxhWQHnqEIm+PG9R4F0iR XiV0WRneezr8Mp/WrhR72T2KQDq2/Xy4GPp75cC4Y9cYtwDtdVL3VYGXx1n/eZ49 XUiamFil3enT1qxUD1nSA6ym7DU9dIuekrsLO1Rn2V0Xyn1ExHLlXe9JyxsKZeY= =uw+E -----END PGP SIGNATURE----- --=-L7Lz/jKMch1jLNuYAU6+-- From owner-freebsd-stable@FreeBSD.ORG Wed Sep 11 03:46:43 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C9B37B63 for ; Wed, 11 Sep 2013 03:46:43 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A57AE2266 for ; Wed, 11 Sep 2013 03:46:43 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 3BD4D1A3D7D; Tue, 10 Sep 2013 20:46:37 -0700 (PDT) Message-ID: <522FE79C.1000201@mu.org> Date: Tue, 10 Sep 2013 20:46:36 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ryan McIntosh Subject: Re: Looking for driver help References: <522C99AA.7010008@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Sep 2013 03:46:43 -0000 Hey Ryan, I really don't see much that I can help you with, giving FreeBSD current a shot might help, but after quite a bit of grep(1) I didn't seem to find support for this driver in -current so you may be SOL. -Alfred On 9/9/13 11:11 PM, Ryan McIntosh wrote: > Presently 9.1-RELEASE but I believe I searched HEAD for the driver which > came up with nothing. I'm all ears though if you find something. > > root@dev01:/root # pciconf -l > hostb0@pci0:0:0:0: class=0x060000 card=0xbc8015d9 chip=0x40038086 > rev=0x20 hdr=0x00 > pcib1@pci0:0:1:0: class=0x060400 card=0xbc8015d9 chip=0x40218086 > rev=0x20 hdr=0x01 > pcib2@pci0:0:5:0: class=0x060400 card=0xbc8015d9 chip=0x40258086 > rev=0x20 hdr=0x01 > pcib7@pci0:0:7:0: class=0x060400 card=0xbc8015d9 chip=0x40278086 > rev=0x20 hdr=0x01 > none0@pci0:0:15:0: class=0x088000 card=0xbc8015d9 chip=0x402f8086 > rev=0x20 hdr=0x00 > hostb1@pci0:0:16:0: class=0x060000 card=0xbc8015d9 chip=0x40308086 > rev=0x20 hdr=0x00 > hostb2@pci0:0:16:1: class=0x060000 card=0xbc8015d9 chip=0x40308086 > rev=0x20 hdr=0x00 > hostb3@pci0:0:16:2: class=0x060000 card=0xbc8015d9 chip=0x40308086 > rev=0x20 hdr=0x00 > hostb4@pci0:0:16:3: class=0x060000 card=0xbc8015d9 chip=0x40308086 > rev=0x20 hdr=0x00 > hostb5@pci0:0:16:4: class=0x060000 card=0xbc8015d9 chip=0x40308086 > rev=0x20 hdr=0x00 > hostb6@pci0:0:17:0: class=0x060000 card=0xbc8015d9 chip=0x40318086 > rev=0x20 hdr=0x00 > hostb7@pci0:0:21:0: class=0x060000 card=0xbc8015d9 chip=0x40358086 > rev=0x20 hdr=0x00 > hostb8@pci0:0:21:1: class=0x060000 card=0xbc8015d9 chip=0x40358086 > rev=0x20 hdr=0x00 > hostb9@pci0:0:22:0: class=0x060000 card=0xbc8015d9 chip=0x40368086 > rev=0x20 hdr=0x00 > hostb10@pci0:0:22:1: class=0x060000 card=0xbc8015d9 chip=0x40368086 > rev=0x20 hdr=0x00 > uhci0@pci0:0:29:0: class=0x0c0300 card=0xbc8015d9 chip=0x26888086 > rev=0x09 hdr=0x00 > uhci1@pci0:0:29:1: class=0x0c0300 card=0xbc8015d9 chip=0x26898086 > rev=0x09 hdr=0x00 > uhci2@pci0:0:29:2: class=0x0c0300 card=0xbc8015d9 chip=0x268a8086 > rev=0x09 hdr=0x00 > ehci0@pci0:0:29:7: class=0x0c0320 card=0xbc8015d9 chip=0x268c8086 > rev=0x09 hdr=0x00 > pcib8@pci0:0:30:0: class=0x060401 card=0xbc8015d9 chip=0x244e8086 > rev=0xd9 hdr=0x01 > isab0@pci0:0:31:0: class=0x060100 card=0xbc8015d9 chip=0x26708086 > rev=0x09 hdr=0x00 > ahci0@pci0:0:31:2: class=0x010601 card=0xbc8015d9 chip=0x26818086 > rev=0x09 hdr=0x00 > none1@pci0:0:31:3: class=0x0c0500 card=0xbc8015d9 chip=0x269b8086 > rev=0x09 hdr=0x00 > none2@pci0:1:0:0: class=0x020000 card=0x01264040 chip=0x01004040 > rev=0x42 hdr=0x00 > none3@pci0:1:0:1: class=0x020000 card=0x01264040 chip=0x01004040 > rev=0x42 hdr=0x00 > pcib3@pci0:3:0:0: class=0x060400 card=0xbc8015d9 chip=0x35008086 > rev=0x01 hdr=0x01 > pcib6@pci0:3:0:3: class=0x060400 card=0xbc8015d9 chip=0x350c8086 > rev=0x01 hdr=0x01 > pcib4@pci0:4:0:0: class=0x060400 card=0xbc8015d9 chip=0x35108086 > rev=0x01 hdr=0x01 > pcib5@pci0:4:2:0: class=0x060400 card=0xbc8015d9 chip=0x35188086 > rev=0x01 hdr=0x01 > em0@pci0:6:0:0: class=0x020000 card=0x109615d9 chip=0x10968086 rev=0x01 > hdr=0x00 > em1@pci0:6:0:1: class=0x020000 card=0x109615d9 chip=0x10968086 rev=0x01 > hdr=0x00 > none4@pci0:8:0:0: class=0x0c0600 card=0x627415b3 chip=0x627415b3 > rev=0x20 hdr=0x00 > vgapci0@pci0:9:1:0: class=0x030000 card=0xbc8015d9 chip=0x515e1002 > rev=0x02 hdr=0x00 > > - snip from pciconf -lv for the card in question (its a dual port) - > none2@pci0:1:0:0: class=0x020000 card=0x01264040 chip=0x01004040 > rev=0x42 hdr=0x00 > vendor = 'NetXen Incorporated' > device = 'NX3031 Multifunction 1/10-Gigabit Server Adapter' > class = network > subclass = ethernet > none3@pci0:1:0:1: class=0x020000 card=0x01264040 chip=0x01004040 > rev=0x42 hdr=0x00 > vendor = 'NetXen Incorporated' > device = 'NX3031 Multifunction 1/10-Gigabit Server Adapter' > class = network > subclass = ethernet > - end snip - > > root@dev01:/root # uname -a > FreeBSD dev01 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 > 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > amd64 > root@dev01:/root # > > I'll upgrade to whatever if there's a chance of a driver already existing > but so far I've found nothing. > > Thanks and sorry for the delay. > > Ryan > > > On Sun, Sep 8, 2013 at 11:37 AM, Alfred Perlstein wrote: > >> On 9/8/13 3:01 AM, Ryan McIntosh wrote: >> >>> I sent an email out to freebsd-net without a response, soo this is my last >>> attempt at getting any assistance here. >>> >>> I have a QLE3142-CU-CK (rebranded NetXen NX3-20GCU w/ NX3031 chipset) with >>> no driver support in *BSD from anything I saw. I came across solaris's >>> ntxn >>> driver which seems to work appropriately but I have no use for solaris as >>> a >>> host o/s. Naturally I'll attempt at trying to get the driver to work >>> myself, however I'm far from knowledgeable on the method to port a driver, >>> but I won't say no to making it work after the response Qlogic gave me. >>> Any >>> insight/assistance/pointers would be helpful, including which mailing list >>> might be best for this. >>> >>> Ryan >>> ______________________________**_________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@** >>> freebsd.org " >>> >>> What version of FreeBSD are you using? FreeBSD 10 has drivers for >> several qlogic 10gb cards. >> >> It would help to see output of "pciconf -l" on this machine as well >> knowing what version you are using. >> >> >> >> -- >> Alfred Perlstein >> >> > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Alfred Perlstein From owner-freebsd-stable@FreeBSD.ORG Wed Sep 11 06:32:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 877B9724 for ; Wed, 11 Sep 2013 06:32:30 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3AE1527E3 for ; Wed, 11 Sep 2013 06:32:29 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1VJdyO-000CKl-67; Wed, 11 Sep 2013 09:32:20 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Julian Stecklina Subject: Re: Intel 10Gb network card In-reply-to: References: Comments: In-reply-to Julian Stecklina message dated "Tue, 10 Sep 2013 20:35:45 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Sep 2013 09:32:20 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Sep 2013 06:32:30 -0000 > On 09/04/2013 08:25 AM, Daniel Braniss wrote: > > Q: does the copper (10G Based T) version work? > > Works fine for me. > Nice to know, danke, danny From owner-freebsd-stable@FreeBSD.ORG Wed Sep 11 10:09:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5ED82BD for ; Wed, 11 Sep 2013 10:09:25 +0000 (UTC) (envelope-from rmcintosh@nitemare.net) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1E3BD213B for ; Wed, 11 Sep 2013 10:09:24 +0000 (UTC) Received: by mail-qe0-f54.google.com with SMTP id cy11so5315664qeb.13 for ; Wed, 11 Sep 2013 03:09:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=taRO65qBuK99WYsWIYDwuQB6qP5+nDOb+SQWQyE3WDw=; b=an3pE8lr/3YMLZQceotgEMtFkFDtVBiaVmfE/JnQbVrxZCUyQjGOGsMFT4w/CYnObY 2zzyQ9/hXZlv7wkRTlWvYWeKH7xGBBo+VNAGW4my28w3lLhMwtGjhyNpdsttGZ0sr7xc Oqo7Cj7B6IzP287gHfJ8XKRVTlx4OsunSnvRUPPTBX+1NbHZJdi1mpwvXcr8kgfd0bc1 FfQNXfGYItaG7iQwPpiGeTc1wgDyEYPmBQf8hafsMmiNzEFRZEMgdfkEaQCAAmKLWQ2X pzu1Jd8OQnwRbGB/YgdsOnlGKPD+5d7lMcjLaB8DetAnq/Qj4QoZqVZtEa4r4CW6hL3k tTew== X-Gm-Message-State: ALoCoQn/eRcdNK8YMooC+mGPEv+guTdwCeOqOPe3dgkAU5pKPIMt0xf03uEnZ0Vdp/6rKp+bfjR7 MIME-Version: 1.0 X-Received: by 10.49.50.198 with SMTP id e6mr1623212qeo.76.1378894163319; Wed, 11 Sep 2013 03:09:23 -0700 (PDT) Received: by 10.49.60.10 with HTTP; Wed, 11 Sep 2013 03:09:23 -0700 (PDT) X-Originating-IP: [76.15.56.143] In-Reply-To: <522FE79C.1000201@mu.org> References: <522C99AA.7010008@mu.org> <522FE79C.1000201@mu.org> Date: Wed, 11 Sep 2013 06:09:23 -0400 Message-ID: Subject: Re: Looking for driver help From: Ryan McIntosh To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Sep 2013 10:09:25 -0000 Yeah this is the same conclusion I came to in essence of anything existing. I'm going to hit up the freebsd-drivers list however and see where I end up after that. The cards might wind up in the garbage can or sold off cheap unfortunately if I can't get them functional with FreeBSD, which is pretty sad for a bunch of dual 10g cards. Thanks for the effort though, I do appreciate it. Ryan On Tue, Sep 10, 2013 at 11:46 PM, Alfred Perlstein wrote: > Hey Ryan, > > I really don't see much that I can help you with, giving FreeBSD current a > shot might help, but after quite a bit of grep(1) I didn't seem to find > support for this driver in -current so you may be SOL. > > -Alfred > > > > > On 9/9/13 11:11 PM, Ryan McIntosh wrote: > >> Presently 9.1-RELEASE but I believe I searched HEAD for the driver which >> came up with nothing. I'm all ears though if you find something. >> >> root@dev01:/root # pciconf -l >> hostb0@pci0:0:0:0: class=0x060000 card=0xbc8015d9 chip=0x40038086 >> rev=0x20 hdr=0x00 >> pcib1@pci0:0:1:0: class=0x060400 card=0xbc8015d9 chip=0x40218086 >> rev=0x20 hdr=0x01 >> pcib2@pci0:0:5:0: class=0x060400 card=0xbc8015d9 chip=0x40258086 >> rev=0x20 hdr=0x01 >> pcib7@pci0:0:7:0: class=0x060400 card=0xbc8015d9 chip=0x40278086 >> rev=0x20 hdr=0x01 >> none0@pci0:0:15:0: class=0x088000 card=0xbc8015d9 chip=0x402f8086 >> rev=0x20 hdr=0x00 >> hostb1@pci0:0:16:0: class=0x060000 card=0xbc8015d9 chip=0x40308086 >> rev=0x20 hdr=0x00 >> hostb2@pci0:0:16:1: class=0x060000 card=0xbc8015d9 chip=0x40308086 >> rev=0x20 hdr=0x00 >> hostb3@pci0:0:16:2: class=0x060000 card=0xbc8015d9 chip=0x40308086 >> rev=0x20 hdr=0x00 >> hostb4@pci0:0:16:3: class=0x060000 card=0xbc8015d9 chip=0x40308086 >> rev=0x20 hdr=0x00 >> hostb5@pci0:0:16:4: class=0x060000 card=0xbc8015d9 chip=0x40308086 >> rev=0x20 hdr=0x00 >> hostb6@pci0:0:17:0: class=0x060000 card=0xbc8015d9 chip=0x40318086 >> rev=0x20 hdr=0x00 >> hostb7@pci0:0:21:0: class=0x060000 card=0xbc8015d9 chip=0x40358086 >> rev=0x20 hdr=0x00 >> hostb8@pci0:0:21:1: class=0x060000 card=0xbc8015d9 chip=0x40358086 >> rev=0x20 hdr=0x00 >> hostb9@pci0:0:22:0: class=0x060000 card=0xbc8015d9 chip=0x40368086 >> rev=0x20 hdr=0x00 >> hostb10@pci0:0:22:1: class=0x060000 card=0xbc8015d9 chip=0x40368086 >> rev=0x20 hdr=0x00 >> uhci0@pci0:0:29:0: class=0x0c0300 card=0xbc8015d9 chip=0x26888086 >> rev=0x09 hdr=0x00 >> uhci1@pci0:0:29:1: class=0x0c0300 card=0xbc8015d9 chip=0x26898086 >> rev=0x09 hdr=0x00 >> uhci2@pci0:0:29:2: class=0x0c0300 card=0xbc8015d9 chip=0x268a8086 >> rev=0x09 hdr=0x00 >> ehci0@pci0:0:29:7: class=0x0c0320 card=0xbc8015d9 chip=0x268c8086 >> rev=0x09 hdr=0x00 >> pcib8@pci0:0:30:0: class=0x060401 card=0xbc8015d9 chip=0x244e8086 >> rev=0xd9 hdr=0x01 >> isab0@pci0:0:31:0: class=0x060100 card=0xbc8015d9 chip=0x26708086 >> rev=0x09 hdr=0x00 >> ahci0@pci0:0:31:2: class=0x010601 card=0xbc8015d9 chip=0x26818086 >> rev=0x09 hdr=0x00 >> none1@pci0:0:31:3: class=0x0c0500 card=0xbc8015d9 chip=0x269b8086 >> rev=0x09 hdr=0x00 >> none2@pci0:1:0:0: class=0x020000 card=0x01264040 chip=0x01004040 >> rev=0x42 hdr=0x00 >> none3@pci0:1:0:1: class=0x020000 card=0x01264040 chip=0x01004040 >> rev=0x42 hdr=0x00 >> pcib3@pci0:3:0:0: class=0x060400 card=0xbc8015d9 chip=0x35008086 >> rev=0x01 hdr=0x01 >> pcib6@pci0:3:0:3: class=0x060400 card=0xbc8015d9 chip=0x350c8086 >> rev=0x01 hdr=0x01 >> pcib4@pci0:4:0:0: class=0x060400 card=0xbc8015d9 chip=0x35108086 >> rev=0x01 hdr=0x01 >> pcib5@pci0:4:2:0: class=0x060400 card=0xbc8015d9 chip=0x35188086 >> rev=0x01 hdr=0x01 >> em0@pci0:6:0:0: class=0x020000 card=0x109615d9 chip=0x10968086 rev=0x01 >> hdr=0x00 >> em1@pci0:6:0:1: class=0x020000 card=0x109615d9 chip=0x10968086 rev=0x01 >> hdr=0x00 >> none4@pci0:8:0:0: class=0x0c0600 card=0x627415b3 chip=0x627415b3 >> rev=0x20 hdr=0x00 >> vgapci0@pci0:9:1:0: class=0x030000 card=0xbc8015d9 chip=0x515e1002 >> rev=0x02 hdr=0x00 >> >> - snip from pciconf -lv for the card in question (its a dual port) - >> none2@pci0:1:0:0: class=0x020000 card=0x01264040 chip=0x01004040 >> rev=0x42 hdr=0x00 >> vendor = 'NetXen Incorporated' >> device = 'NX3031 Multifunction 1/10-Gigabit Server Adapter' >> class = network >> subclass = ethernet >> none3@pci0:1:0:1: class=0x020000 card=0x01264040 chip=0x01004040 >> rev=0x42 hdr=0x00 >> vendor = 'NetXen Incorporated' >> device = 'NX3031 Multifunction 1/10-Gigabit Server Adapter' >> class = network >> subclass = ethernet >> - end snip - >> >> root@dev01:/root # uname -a >> FreeBSD dev01 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 >> 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/** >> usr/obj/usr/src/sys/GENERIC >> amd64 >> root@dev01:/root # >> >> I'll upgrade to whatever if there's a chance of a driver already existing >> but so far I've found nothing. >> >> Thanks and sorry for the delay. >> >> Ryan >> >> >> On Sun, Sep 8, 2013 at 11:37 AM, Alfred Perlstein wrote: >> >> On 9/8/13 3:01 AM, Ryan McIntosh wrote: >>> >>> I sent an email out to freebsd-net without a response, soo this is my >>>> last >>>> attempt at getting any assistance here. >>>> >>>> I have a QLE3142-CU-CK (rebranded NetXen NX3-20GCU w/ NX3031 chipset) >>>> with >>>> no driver support in *BSD from anything I saw. I came across solaris's >>>> ntxn >>>> driver which seems to work appropriately but I have no use for solaris >>>> as >>>> a >>>> host o/s. Naturally I'll attempt at trying to get the driver to work >>>> myself, however I'm far from knowledgeable on the method to port a >>>> driver, >>>> but I won't say no to making it work after the response Qlogic gave me. >>>> Any >>>> insight/assistance/pointers would be helpful, including which mailing >>>> list >>>> might be best for this. >>>> >>>> Ryan >>>> ______________________________****_________________ >>>> freebsd-stable@freebsd.org mailing list >>>> http://lists.freebsd.org/****mailman/listinfo/freebsd-****stable >>>> >>>> > >>>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@** >>>> freebsd.org >>>> >" >>>> >>>> >>>> What version of FreeBSD are you using? FreeBSD 10 has drivers for >>>> >>> several qlogic 10gb cards. >>> >>> It would help to see output of "pciconf -l" on this machine as well >>> knowing what version you are using. >>> >>> >>> >>> -- >>> Alfred Perlstein >>> >>> >>> ______________________________**_________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/**mailman/listinfo/freebsd-**stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@** >> freebsd.org " >> >> > > -- > Alfred Perlstein > > From owner-freebsd-stable@FreeBSD.ORG Wed Sep 11 10:32:44 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 09D905D6 for ; Wed, 11 Sep 2013 10:32:44 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C87A4222E for ; Wed, 11 Sep 2013 10:32:43 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.90,883,1371106800"; d="asc'?scan'208";a="88590801" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx12-out.netapp.com with ESMTP; 11 Sep 2013 03:32:37 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.116]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Wed, 11 Sep 2013 03:32:36 -0700 From: "Eggert, Lars" To: "stable@freebsd.org" Subject: nfsd CPU usage? Thread-Topic: nfsd CPU usage? Thread-Index: AQHOrto706tE4yigQ0+JIY2X/OKgRA== Date: Wed, 11 Sep 2013 10:32:36 +0000 Message-ID: <404C967C-4BFB-424C-A5E0-6ACE6576249C@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_9B51DA49-75C5-4D74-953A-FCF572E18339"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Rick Macklem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Sep 2013 10:32:44 -0000 --Apple-Mail=_9B51DA49-75C5-4D74-953A-FCF572E18339 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I'm seeing extremely high CPU usage withssh-st the new nfsd: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 2280 root 102 0 9932K 1376K *nfs_c 0 320:11 100.00% = nfsd{nfsd: service} 2280 root 102 0 9932K 1376K CPU7 7 319:47 100.00% = nfsd{nfsd: service} 2280 root 102 0 9932K 1376K CPU5 5 318:25 100.00% = nfsd{nfsd: service} 2280 root 102 0 9932K 1376K CPU6 6 318:20 100.00% = nfsd{nfsd: service} 2280 root 52 0 9932K 1376K CPU0 0 317:32 100.00% = nfsd{nfsd: service} 2280 root 102 0 9932K 1376K *nfs_c 1 315:41 99.17% = nfsd{nfsd: service} 2280 root 52 0 9932K 1376K *nfs_c 4 320:22 98.78% = nfsd{nfsd: master} 2280 root 102 0 9932K 1376K *nfs_c 1 317:10 98.10% = nfsd{nfsd: service} And this is at a few hundred KB/s with only a few clients: ifstat -i igb1 10 igb1 =20 KB/s in KB/s out 796.56 208.66 431.19 232.36 316.11 280.31 1005.96 523.42 1077.74 342.25 340.63 217.73 1067.96 330.56 487.91 235.61 Any ideas? FreeBSD stanley.muccbc.hq.netapp.com 9.2-PRERELEASE FreeBSD = 9.2-PRERELEASE #7: Wed Sep 4 11:06:31 CEST 2013 = root@stanley.muccbc.hq.netapp.com:/usr/obj/usr/src/sys/STANLEY amd64 Thanks, Lars --Apple-Mail=_9B51DA49-75C5-4D74-953A-FCF572E18339 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 - http://gpgtools.org iQCVAwUBUjBGw9ZcnpRveo1xAQJfXwP9HbQpkpMsAmnoOUjWDNKQTlh4vmy/8klB mNU3CCrkSUu5pyyWk9d1H38NgErr6dvXDLwNCTvFNhfLq+a6I49oKuLdtyN4jO5l 8ydNtez58JetD72BywD8dT0nNOmVDk8QfG7sg2C9WePuNvFutMxEXLaR+Zc6OJs0 ia8/axiADTA= =h/l+ -----END PGP SIGNATURE----- --Apple-Mail=_9B51DA49-75C5-4D74-953A-FCF572E18339-- From owner-freebsd-stable@FreeBSD.ORG Wed Sep 11 11:54:17 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C4B82B79 for ; Wed, 11 Sep 2013 11:54:17 +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 8C3C5274A for ; Wed, 11 Sep 2013 11:54:17 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAMpYMFKDaFve/2dsb2JhbABbFoMpUoMqvzaBMnSCJQEBBSNWGxgCAg0ZAlkGE4gCDLJbkWmBKY4NNAeCaYE0A5kokEODPiCBbg X-IronPort-AV: E=Sophos;i="4.90,883,1371096000"; d="scan'208";a="51102365" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 11 Sep 2013 07:54:10 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id A39F1B3F49; Wed, 11 Sep 2013 07:54:10 -0400 (EDT) Date: Wed, 11 Sep 2013 07:54:10 -0400 (EDT) From: Rick Macklem To: Lars Eggert Message-ID: <995078453.21651811.1378900450650.JavaMail.root@uoguelph.ca> In-Reply-To: <404C967C-4BFB-424C-A5E0-6ACE6576249C@netapp.com> Subject: Re: nfsd CPU usage? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Sep 2013 11:54:17 -0000 Lars Eggert wrote: > Hi, > > I'm seeing extremely high CPU usage withssh-st the new nfsd: > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU > COMMAND > 2280 root 102 0 9932K 1376K *nfs_c 0 320:11 100.00% > nfsd{nfsd: service} > 2280 root 102 0 9932K 1376K CPU7 7 319:47 100.00% > nfsd{nfsd: service} > 2280 root 102 0 9932K 1376K CPU5 5 318:25 100.00% > nfsd{nfsd: service} > 2280 root 102 0 9932K 1376K CPU6 6 318:20 100.00% > nfsd{nfsd: service} > 2280 root 52 0 9932K 1376K CPU0 0 317:32 100.00% > nfsd{nfsd: service} > 2280 root 102 0 9932K 1376K *nfs_c 1 315:41 99.17% > nfsd{nfsd: service} > 2280 root 52 0 9932K 1376K *nfs_c 4 320:22 98.78% > nfsd{nfsd: master} > 2280 root 102 0 9932K 1376K *nfs_c 1 317:10 98.10% > nfsd{nfsd: service} > > And this is at a few hundred KB/s with only a few clients: > > ifstat -i igb1 10 > igb1 > KB/s in KB/s out > 796.56 208.66 > 431.19 232.36 > 316.11 280.31 > 1005.96 523.42 > 1077.74 342.25 > 340.63 217.73 > 1067.96 330.56 > 487.91 235.61 > > Any ideas? > > FreeBSD stanley.muccbc.hq.netapp.com 9.2-PRERELEASE FreeBSD > 9.2-PRERELEASE #7: Wed Sep 4 11:06:31 CEST 2013 > root@stanley.muccbc.hq.netapp.com:/usr/obj/usr/src/sys/STANLEY > amd64 > > Thanks, > Lars > There is a patch in head (r254337) that I believe handles this. It will be MFC'd to stable/9 in about a week, unless someone finds problems with it before then. If you want a semantically equivalent (but uglier code) patch, you can find it here: http://people.freebsd.org/~rmacklem/drc4-stable9.patch After applying the patch, you need to set sysctl variable(s), to avoid the aggressive trimming of stale DRC entries. Garrett Wollman suggests the following for a large server: vfs.nfsd.tcphighwater=100000 vfs.nfsd.tcpcachetimeout=300 (5 minutes instead of default of several hrs) You can also use the sysctl vfs.nfsd.cachetcp=0 to disable use of the DRC for TCP. The old nfs server did not use the DRC for TCP. The assumption being that TCP layer retransmits are good enough to maintain reliable RPC transport. Unfortuantely, you can get file corruption when the server reboots or there is a network partitioning, if the client chooses to redo the RPC over TCP (clients always do this after having to create a new TCP connection). In other words, vfs.nfsd.cachetcp=0 is roughly what the old nfsd did. If you don't want to patch the 9.2 code, you can edit the sources (sys/fs/nfsserver/nfs_nfsdcache.c) and change the line: static int nfsrc_tcpnonidempotent = 1; to static int nfsrc_tcpnonidempotent = 0; to do the same thing as vfs.nfsd.cachetcp=0 rick From owner-freebsd-stable@FreeBSD.ORG Wed Sep 11 12:12:42 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5F1C62A7 for ; Wed, 11 Sep 2013 12:12:42 +0000 (UTC) (envelope-from lars.engels@0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 216582879 for ; Wed, 11 Sep 2013 12:12:41 +0000 (UTC) Received: from 0x20.net (0x20.net [217.69.76.212]) (Authenticated sender: lala) by mail.0x20.net (Postfix) with ESMTPA id 8D8D96A6000 for ; Wed, 11 Sep 2013 14:12:39 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 11 Sep 2013 14:12:39 +0200 From: Lars Engels To: freebsd-stable@freebsd.org Subject: Re: Looking for driver help In-Reply-To: References: <522C99AA.7010008@mu.org> <522FE79C.1000201@mu.org> Message-ID: <88ed03a682093c1a67fa6af2695524df@mail.0x20.net> X-Sender: lars.engels@0x20.net User-Agent: Roundcube Webmail/0.7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Sep 2013 12:12:42 -0000 Am 11.09.2013 12:09, schrieb Ryan McIntosh: > Yeah this is the same conclusion I came to in essence of anything > existing. > I'm going to hit up the freebsd-drivers list however and see where I > end up > after that. The cards might wind up in the garbage can or sold off > cheap > unfortunately if I can't get them functional with FreeBSD, which is > pretty > sad for a bunch of dual 10g cards. Thanks for the effort though, I do > appreciate it. You can also donate it to FreeBSD, maybe you can find a developer who can write the driver but doesn't have the hardware. If you like to, drop a mail to donations@ Lars From owner-freebsd-stable@FreeBSD.ORG Wed Sep 11 12:51:19 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 551C2D1A for ; Wed, 11 Sep 2013 12:51:19 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2509C2A07 for ; Wed, 11 Sep 2013 12:51:18 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id 16so7742678iea.2 for ; Wed, 11 Sep 2013 05:51:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=Al5IQR7Ca/qVBB+TTmCRLU2f5QuiKjqe7zJOda+0Xfo=; b=PLVc/sc5R+4Gn1Holak6yA44PPEkb2JHVc6l69Yad2dpXFmel8KNrNn3touHiJN/9+ k8Mtg5zjaRb5rNLZhkhtG9DzVh+ijDnZ/9dO93yvHXCKnhiVUxG0BBIgNVg8B56gwmIL CDObTsW/EmzLISPETLeaWTwXlwuctjyF4QOkdBw/00fV6aN9fMO8GnMBFDkw0gr5Notf GV6U16sGPLaom5tDhyx25p2O3E3GBRM7gDOWyxVWN5+sazeSv1CV21ZoGB+ykWeuwvEF LBFr4ihoK7K75xxh3HnZCP4XIF6iX+WD0qo0BlMlqvc4QfmDkk8LHHu2UoLBAIvNyPi1 Hjhw== X-Gm-Message-State: ALoCoQns1gNx2NmGzKk01R/tx4DaU8zMiEG88ATm3gw4jS/z4wGLH4PCYTRLo8p8ppHIB1ncrQ+d X-Received: by 10.50.43.170 with SMTP id x10mr313162igl.45.1378903878038; Wed, 11 Sep 2013 05:51:18 -0700 (PDT) Received: from [97.61.211.27] (27.sub-97-61-211.myvzw.com. [97.61.211.27]) by mx.google.com with ESMTPSA id w4sm2955033igb.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Sep 2013 05:51:16 -0700 (PDT) References: <995078453.21651811.1378900450650.JavaMail.root@uoguelph.ca> Mime-Version: 1.0 (1.0) In-Reply-To: <995078453.21651811.1378900450650.JavaMail.root@uoguelph.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: Mark Saad Subject: Re: nfsd CPU usage? Date: Wed, 11 Sep 2013 08:51:05 -0400 To: Rick Macklem Cc: "stable@freebsd.org" , Lars Eggert X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Sep 2013 12:51:19 -0000 Rick Would this affect 9.2-RCn ?=20 --- Mark saad | mark.saad@longcount.org On Sep 11, 2013, at 7:54 AM, Rick Macklem wrote: > Lars Eggert wrote: >> Hi, >>=20 >> I'm seeing extremely high CPU usage withssh-st the new nfsd: >>=20 >> PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU >> COMMAND >> 2280 root 102 0 9932K 1376K *nfs_c 0 320:11 100.00% >> nfsd{nfsd: service} >> 2280 root 102 0 9932K 1376K CPU7 7 319:47 100.00% >> nfsd{nfsd: service} >> 2280 root 102 0 9932K 1376K CPU5 5 318:25 100.00% >> nfsd{nfsd: service} >> 2280 root 102 0 9932K 1376K CPU6 6 318:20 100.00% >> nfsd{nfsd: service} >> 2280 root 52 0 9932K 1376K CPU0 0 317:32 100.00% >> nfsd{nfsd: service} >> 2280 root 102 0 9932K 1376K *nfs_c 1 315:41 99.17% >> nfsd{nfsd: service} >> 2280 root 52 0 9932K 1376K *nfs_c 4 320:22 98.78% >> nfsd{nfsd: master} >> 2280 root 102 0 9932K 1376K *nfs_c 1 317:10 98.10% >> nfsd{nfsd: service} >>=20 >> And this is at a few hundred KB/s with only a few clients: >>=20 >> ifstat -i igb1 10 >> igb1 >> KB/s in KB/s out >> 796.56 208.66 >> 431.19 232.36 >> 316.11 280.31 >> 1005.96 523.42 >> 1077.74 342.25 >> 340.63 217.73 >> 1067.96 330.56 >> 487.91 235.61 >>=20 >> Any ideas? >>=20 >> FreeBSD stanley.muccbc.hq.netapp.com 9.2-PRERELEASE FreeBSD >> 9.2-PRERELEASE #7: Wed Sep 4 11:06:31 CEST 2013 >> root@stanley.muccbc.hq.netapp.com:/usr/obj/usr/src/sys/STANLEY >> amd64 >>=20 >> Thanks, >> Lars > There is a patch in head (r254337) that I believe handles this. > It will be MFC'd to stable/9 in about a week, unless someone finds > problems with it before then. > If you want a semantically equivalent (but uglier code) patch, > you can find it here: > http://people.freebsd.org/~rmacklem/drc4-stable9.patch > After applying the patch, you need to set sysctl variable(s), > to avoid the aggressive trimming of stale DRC entries. Garrett > Wollman suggests the following for a large server: > vfs.nfsd.tcphighwater=3D100000 > vfs.nfsd.tcpcachetimeout=3D300 (5 minutes instead of default of several hr= s) >=20 > You can also use the sysctl > vfs.nfsd.cachetcp=3D0 > to disable use of the DRC for TCP. >=20 > The old nfs server did not use the DRC for TCP. The assumption being that > TCP layer retransmits are good enough to maintain reliable RPC transport. > Unfortuantely, you can get file corruption when the server reboots or > there is a network partitioning, if the client chooses to redo the RPC > over TCP (clients always do this after having to create a new TCP connecti= on). > In other words, vfs.nfsd.cachetcp=3D0 is roughly what the old nfsd did. >=20 > If you don't want to patch the 9.2 code, you can edit the sources > (sys/fs/nfsserver/nfs_nfsdcache.c) and change the line: > static int nfsrc_tcpnonidempotent =3D 1; > to > static int nfsrc_tcpnonidempotent =3D 0; > to do the same thing as vfs.nfsd.cachetcp=3D0 >=20 > rick > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed Sep 11 13:08:35 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F2A6531C for ; Wed, 11 Sep 2013 13:08:34 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D49DC2AC7 for ; Wed, 11 Sep 2013 13:08:34 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.90,884,1371106800"; d="asc'?scan'208";a="88616596" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 11 Sep 2013 06:08:33 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.116]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Wed, 11 Sep 2013 06:08:33 -0700 From: "Eggert, Lars" To: Rick Macklem Subject: Re: nfsd CPU usage? Thread-Topic: nfsd CPU usage? Thread-Index: AQHOrto706tE4yigQ0+JIY2X/OKgRJnA4uQAgAAUxwA= Date: Wed, 11 Sep 2013 13:08:32 +0000 Message-ID: References: <995078453.21651811.1378900450650.JavaMail.root@uoguelph.ca> In-Reply-To: <995078453.21651811.1378900450650.JavaMail.root@uoguelph.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_CF323C75-B1FD-4113-8CF8-E23280450295"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Sep 2013 13:08:35 -0000 --Apple-Mail=_CF323C75-B1FD-4113-8CF8-E23280450295 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks, I will watch out for the MFC and test. Lars On Sep 11, 2013, at 13:54, Rick Macklem wrote: > Lars Eggert wrote: >> Hi, >>=20 >> I'm seeing extremely high CPU usage withssh-st the new nfsd: >>=20 >> PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU >> COMMAND >> 2280 root 102 0 9932K 1376K *nfs_c 0 320:11 100.00% >> nfsd{nfsd: service} >> 2280 root 102 0 9932K 1376K CPU7 7 319:47 100.00% >> nfsd{nfsd: service} >> 2280 root 102 0 9932K 1376K CPU5 5 318:25 100.00% >> nfsd{nfsd: service} >> 2280 root 102 0 9932K 1376K CPU6 6 318:20 100.00% >> nfsd{nfsd: service} >> 2280 root 52 0 9932K 1376K CPU0 0 317:32 100.00% >> nfsd{nfsd: service} >> 2280 root 102 0 9932K 1376K *nfs_c 1 315:41 99.17% >> nfsd{nfsd: service} >> 2280 root 52 0 9932K 1376K *nfs_c 4 320:22 98.78% >> nfsd{nfsd: master} >> 2280 root 102 0 9932K 1376K *nfs_c 1 317:10 98.10% >> nfsd{nfsd: service} >>=20 >> And this is at a few hundred KB/s with only a few clients: >>=20 >> ifstat -i igb1 10 >> igb1 >> KB/s in KB/s out >> 796.56 208.66 >> 431.19 232.36 >> 316.11 280.31 >> 1005.96 523.42 >> 1077.74 342.25 >> 340.63 217.73 >> 1067.96 330.56 >> 487.91 235.61 >>=20 >> Any ideas? >>=20 >> FreeBSD stanley.muccbc.hq.netapp.com 9.2-PRERELEASE FreeBSD >> 9.2-PRERELEASE #7: Wed Sep 4 11:06:31 CEST 2013 >> root@stanley.muccbc.hq.netapp.com:/usr/obj/usr/src/sys/STANLEY >> amd64 >>=20 >> Thanks, >> Lars >>=20 > There is a patch in head (r254337) that I believe handles this. > It will be MFC'd to stable/9 in about a week, unless someone finds > problems with it before then. > If you want a semantically equivalent (but uglier code) patch, > you can find it here: > http://people.freebsd.org/~rmacklem/drc4-stable9.patch > After applying the patch, you need to set sysctl variable(s), > to avoid the aggressive trimming of stale DRC entries. Garrett > Wollman suggests the following for a large server: > vfs.nfsd.tcphighwater=3D100000 > vfs.nfsd.tcpcachetimeout=3D300 (5 minutes instead of default of = several hrs) >=20 > You can also use the sysctl > vfs.nfsd.cachetcp=3D0 > to disable use of the DRC for TCP. >=20 > The old nfs server did not use the DRC for TCP. The assumption being = that > TCP layer retransmits are good enough to maintain reliable RPC = transport. > Unfortuantely, you can get file corruption when the server reboots or > there is a network partitioning, if the client chooses to redo the RPC > over TCP (clients always do this after having to create a new TCP = connection). > In other words, vfs.nfsd.cachetcp=3D0 is roughly what the old nfsd = did. >=20 > If you don't want to patch the 9.2 code, you can edit the sources > (sys/fs/nfsserver/nfs_nfsdcache.c) and change the line: > static int nfsrc_tcpnonidempotent =3D 1; > to > static int nfsrc_tcpnonidempotent =3D 0; > to do the same thing as vfs.nfsd.cachetcp=3D0 >=20 > rick --Apple-Mail=_CF323C75-B1FD-4113-8CF8-E23280450295 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 - http://gpgtools.org iQCVAwUBUjBrUNZcnpRveo1xAQJhNgQAhKrslgI4FseWob/uGeX9BBLHZkPEE2Tn mpz1wnIwiW8b/00ugi1R+mhJ2ZNxR8Srs8BYAvBCutbvOGrjXP8pGDsawyKZ2HpK zmDvDHj42guTEFMcHP31/uorZNJAbW3gHnMozd3ZhX0T90rGN/tEfde5rQNgoEGA pirG56xck2o= =KVli -----END PGP SIGNATURE----- --Apple-Mail=_CF323C75-B1FD-4113-8CF8-E23280450295-- From owner-freebsd-stable@FreeBSD.ORG Wed Sep 11 15:07:31 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BC3F799F for ; Wed, 11 Sep 2013 15:07:31 +0000 (UTC) (envelope-from olgeni@olgeni.com) Received: from olgeni.olgeni.com (host-156-246-171-31.cloudsigma.com [31.171.246.156]) by mx1.freebsd.org (Postfix) with ESMTP id 6D711223C for ; Wed, 11 Sep 2013 15:07:30 +0000 (UTC) Received: from olgeni.olgeni (unknown [82.84.82.178]) by olgeni.olgeni.com (Postfix) with ESMTPSA id 95BB517449C for ; Wed, 11 Sep 2013 17:07:12 +0200 (CEST) Date: Wed, 11 Sep 2013 17:07:10 +0200 (CEST) From: Jimmy Olgeni X-X-Sender: olgeni@olgeni.olgeni To: freebsd-stable@freebsd.org Subject: Possible kqueue related issue on STABLE/RC. Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Sep 2013 15:07:31 -0000 Hello, Perhaps I found something weird while running 9.2-RC3 FreeBSD 9.2-RC3 #0 r255393 (ZFS-only setup). Quick history of the problem: - Lately, using a very recent -STABLE, the host would hang randomly while building ports with poudriere (-J2) and using X11, without producing a core dump (solid deadlock, apparently). It works perfectly when using the console only, and it can run a large build overnight without hanging. Being on X11 I could not find out what was happening on the console; desktop PC does not have a proper serial port so there's not much I can see. In any case it does not reboot automatically. - To rule out recent -STABLE changes I moved to 9.2-RC3 using SVN, but the system kept hanging on the same conditions. - I also enabled DDB to get a minidump, but still I could only get solid locks. - I downgraded the nvidia-driver port, just in case it has something to do with the crashes, but the crashes continued. - I downgraded to a known-safe -STABLE of July, then June, but the host would still crash. The very weird thing is that I have been always building stuff while using X11, and it never hanged. After downgrading both the OS and nvidia-driver I effectively got back a configuration that did not hang at the time, but the issue persisted. - However, this time I managed to get a minidump from the old -STABLE. I saved it here: http://olgeni.olgeni.com/~olgeni/core.txt.0 - After seeing the reference to kqueue, I remembered another thing that changed when the crashes started: gio-fam-backend went away, and glib20 uses kqueue (r324037). - I tried the same workload while using X11 with openbox only, and it worked fine. - Then, I came back to Gnome but made sure that anything related to gvfsd was periodically killed by a script, and the system returned to normal (i.e. flawless builds). - I remember that the gamin implementation uses to open and poll a lot of files, even files that were not used by the X11 environment or Nautilus specifically, and the gamin daemon could steal a good 5% of CPU for polling; restarting it brought it to 0%. - Not sure if it is related in any way, but running a standard "buildworld" does not crash the host. The only difference that I could think of is that poudriere uses jails. Unfortunately I'm not able to get a minidump for the latest RC, but at this point I suspect that something is going on with glib20 and kqueue on both -STABLE and -RC. If anybody has any idea I can test it easily, as it usually takes only a few minutes to hang everything. -- jimmy From owner-freebsd-stable@FreeBSD.ORG Wed Sep 11 15:33:09 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5583E3BB for ; Wed, 11 Sep 2013 15:33:09 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-x22a.google.com (mail-bk0-x22a.google.com [IPv6:2a00:1450:4008:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E05C323C2 for ; Wed, 11 Sep 2013 15:33:08 +0000 (UTC) Received: by mail-bk0-f42.google.com with SMTP id my10so3725189bkb.29 for ; Wed, 11 Sep 2013 08:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=UKKNRa64XVRtSJrxDTww6ZxskLGuWP2OjKHdJjJ9P1I=; b=jE11D9ExACjcVPB4UrLbZjzslCy0rMx/BhNI1XES6Ep3gLX+DSX4KKnRW0tIBS0xVl 3eYbXHMAHuHzcKAdtNNyIk/GS64piszDmF+0RB4k9+OzlY4QMLKfXflYAJkDI4egzCwT Bb9Wk8E+PP1bOT5igbhcrinfDlqjvMXsjGjdyhjRNWvkwMhvMpEBkzFtSnUN8t3HlTI/ 1AbHwtKru/H7Alv1UB6uja+c56Et/ZiyJsrBmNi7rtcOPT90O4l8q9MrYrqWyBqBL1wf wufIEI8HGnzsEb5iKH0X9K0t14yt89xgAXLoXBgAxeCn4+QAnnLH0Upo4kLdd7CYyvFu fujw== X-Received: by 10.205.86.199 with SMTP id at7mr2082713bkc.9.1378913587209; Wed, 11 Sep 2013 08:33:07 -0700 (PDT) Received: from [192.168.1.126] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPSA id nv4sm7767333bkb.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Sep 2013 08:33:06 -0700 (PDT) Message-ID: <52308D30.6020502@gmail.com> Date: Wed, 11 Sep 2013 18:33:04 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130909 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jimmy Olgeni Subject: Re: Possible kqueue related issue on STABLE/RC. References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Sep 2013 15:33:09 -0000 11.09.2013 18:07, Jimmy Olgeni wrote: > Perhaps I found something weird while running 9.2-RC3 FreeBSD > 9.2-RC3 #0 r255393 (ZFS-only setup). > Unfortunately I'm not able to get a minidump for the latest RC, but at this > point I suspect that something is going on with glib20 and kqueue on both > -STABLE and -RC. Can you spare some more info on this? 1. What is your /etc/src.conf and /etc/make.conf files? 2. Does your copy of sources has some third-party patches applied? 3. Does this happens on more than one PC i.e. are you sure hardware is not involved? Can you try to build world WITH_CLANG_IS_CC? Clang generated code is known to produce an instant coredump in situations where gcc generated code hits a loop or becomes unresponsive. -- Sphinx of black quartz, judge my vow. From owner-freebsd-stable@FreeBSD.ORG Wed Sep 11 16:01:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 06D78576 for ; Wed, 11 Sep 2013 16:01:24 +0000 (UTC) (envelope-from olgeni@olgeni.com) Received: from olgeni.olgeni.com (host-156-246-171-31.cloudsigma.com [31.171.246.156]) by mx1.freebsd.org (Postfix) with ESMTP id B6C722589 for ; Wed, 11 Sep 2013 16:01:22 +0000 (UTC) Received: from [192.168.0.196] (93-62-212-84.ip24.fastwebnet.it [93.62.212.84]) by olgeni.olgeni.com (Postfix) with ESMTPSA id E8B24174482; Wed, 11 Sep 2013 18:01:15 +0200 (CEST) Date: Wed, 11 Sep 2013 18:01:13 +0200 (CEST) From: Jimmy Olgeni X-X-Sender: olgeni@localhost.my.domain To: Volodymyr Kostyrko Subject: Re: Possible kqueue related issue on STABLE/RC. In-Reply-To: <52308D30.6020502@gmail.com> Message-ID: References: <52308D30.6020502@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Sep 2013 16:01:24 -0000 On Wed, 11 Sep 2013, Volodymyr Kostyrko wrote: > 11.09.2013 18:07, Jimmy Olgeni wrote: > >> Perhaps I found something weird while running 9.2-RC3 FreeBSD >> 9.2-RC3 #0 r255393 (ZFS-only setup). > >> Unfortunately I'm not able to get a minidump for the latest RC, but at this >> point I suspect that something is going on with glib20 and kqueue on both >> -STABLE and -RC. > > Can you spare some more info on this? Sure, here it goes: > 1. What is your /etc/src.conf and /etc/make.conf files? My /etc/src.conf: === PORTS_MODULES=emulators/virtualbox-ose-kmod sysutils/fusefs-kmod sysutils/pefs-kmod x11/nvidia-driver === My /etc/make.conf: === APACHE_PORT=www/apache22 DEFAULT_PGSQL_VER=92 WITH_NEW_XORG=yes PERL_VERSION=5.14.4 .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) .if !defined(NOCCACHE) CC:= /usr/local/libexec/ccache/world/cc CXX:= /usr/local/libexec/ccache/world/c++ .endif .endif === > 2. Does your copy of sources has some third-party patches applied? No extra patches were applied. For the RC tests I also removed the whole /usr/src and checked it out from svn from scratch. Currently I have this kernel config: === include GENERIC ident RELENG_9 device crypto # core crypto support device cryptodev # /dev/crypto for access to h/w device enc # IPsec interface. options DDB # Enable the ddb debugger backend. options IPSEC # IP security (requires device crypto) options IPSEC_NAT_T # NAT-T support, UDP encap of ESP options IPSEC_FILTERTUNNEL # filter ipsec packets from a tunnel options SC_DFLT_FONT # compile font in makeoptions SC_DFLT_FONT=cp437 options SC_HISTORY_SIZE=512 # number of history buffer lines options VGA_WIDTH90 # support 90 column modes options RACCT # Resource Accounting options RCTL # Resource Limits # altq(9). Enable the base part of the hooks with the ALTQ option. # Individual disciplines must be built into the base system and can not be # loaded as modules at this point. In order to build a SMP kernel you must # also have the ALTQ_NOPCC option. options ALTQ options ALTQ_CBQ # Class Bases Queueing options ALTQ_RED # Random Early Detection options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler options ALTQ_CDNR # Traffic conditioner options ALTQ_PRIQ # Priority Queueing options ALTQ_NOPCC # Required for SMP build options TEKEN_UTF8 === Also, my loader.conf: === autoboot_delay="5" kern.cam.ada.legacy_aliases="0" kern.cam.scsi_delay="1500" net.inet.ip.fw.default_to_accept="1" vm.pmap.pg_ps_enabled="1" ahci_load="YES" ipmi_load="YES" zfs_load="YES" geom_uzip_load="YES" hw.memtest.tests="0" hw.usb.no_pf="1" vm.kmem_size_max="16G" vm.kmem_size="12G" vfs.root.mountfrom="zfs:rpool/zfsroot" vfs.zfs.write_limit_override="1536M" vfs.zfs.txg.synctime_ms="750" vfs.zfs.vdev.min_pending="1" vfs.zfs.vdev.max_pending="1" kern.ipc.semmns="512" kern.ipc.semmnu="256" kern.ipc.shmmni="256" kern.ipc.shmseg="256" nvidia_load="YES" vboxdrv_load="YES" amdtemp_load="YES" snd_hda_load="YES" hint.p4tcc.0.disabled="1" hint.acpi_throttle.0.disabled="1" === sysctl.conf: === debug.kdb.break_to_debugger=1 hw.snd.default_unit=2 kern.coredump=0 kern.ipc.shm_allow_removed=1 kern.ipc.somaxconn=4096 kern.maxfiles=25000 kern.maxvnodes=250000 kern.ps_arg_cache_limit=10000 kern.sched.preempt_thresh=224 machdep.kdb_on_nmi=0 machdep.panic_on_nmi=0 net.inet.icmp.log_redirect=0 net.inet6.ip6.v6only=0 net.link.ether.inet.log_arp_movements=0 vfs.hirunningspace=5242880 vfs.read_max=128 vfs.ufs.dirhash_maxmem=33554432 vfs.usermount=1 vfs.zfs.prefetch_disable=1 === > 3. Does this happens on more than one PC i.e. are you sure hardware > is not involved? First thing I thought of was either memory or the CPU temperature. Right now I have only one PC available to test it, but: - Memory looks ok, at least according to Memtest86/Memtest86+ (tested from Ultimate Boot CD) - CPU looks ok, meaning that it can process heavy workloads without a problem. I tried with dev.cpu.0.freq=2200 to avoid overheating, and by starting 4 different poudriere builds with -J2. I have CPU temperature in the prompt and it hovers aroung 50C during the builds. Without gvfs it works just fine. Running buildworld always seems to work; also running sysutils/stress (stress -v -t 5m --cpu 8 --io 4 --vm 2 --vm-bytes 128M --hdd 4) did not seem to bother the system. - ZFS scrub says that it's all OK on the storage side (initially I thought about something going wrong with ZFS due to bad tuning). > Can you try to build world WITH_CLANG_IS_CC? Clang generated code is > known to produce an instant coredump in situations where gcc > generated code hits a loop or becomes unresponsive. I'm rebuilding a r255473 using WITH_CLANG_IS_CC=yes right now (I also removed ccache which is the only suspicious thing I could see in my make.conf). I'll give it a try as soon as it's done building. -- jimmy From owner-freebsd-stable@FreeBSD.ORG Wed Sep 11 17:01:42 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 72588B56 for ; Wed, 11 Sep 2013 17:01:42 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:8:bdbe:0:1::]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2DA952906 for ; Wed, 11 Sep 2013 17:01:42 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=2001:41d0:8:bdbe:1:1::; helo=restart.be; envelope-from=hlh@restart.be; receiver=stable@freebsd.org DKIM-Filter: OpenDKIM Filter v2.8.3 tignes.restart.be 3cZqC074H5zSD8 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=restart.be; s=tignes; t=1378918893; bh=DQ1sQInANewF8LnbjtbKlmzIMIDqblrHp1AmaRRidUI=; h=Date:From:To:Subject; z=Date:=20Wed,=2011=20Sep=202013=2019:01:31=20+0200|From:=20Henri=2 0Hennebert=20|To:=20stable@freebsd.org|Subject:=20 Link=20error=20in=20usr.bin/dig=20if=20WITH_BIND_XML=3Dyes; b=2tuuzQieaj7UI2QADwHHvaSa88DKw/jMPtVGszPMC1BsKxN8478MeB4Bzo5P1505P DBMGZs0DjeeSiqWfp3WR/NHRW5q+3yrhjNXpLkEeQz6CBhSdte9/PvWXn5a4P7Tr5Q f9xAOZsE46pwX3+69RngvsqTCx8t2OEeStx69mhVRbwqHvZ2k9b9BtiQN8MDrKgxjT Ua/e3vdUn9haixkAnunYlvyLgNgn6gj2/00ZYAgNZGMn1wNZwUnAwV99a6rzUc0Gqo ihPI1o88LV4u5fAaYS/Yzah8SUn8BsH304MQJlQeW3w+U4AaoVWT5kozhZlQi14xXX lPKUIwr/CUH1w== Received: from restart.be (avoriaz.restart.be [IPv6:2001:41d0:8:bdbe:1:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3cZqC074H5zSD8 for ; Wed, 11 Sep 2013 19:01:32 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:8:bdbe:1:2::]) (authenticated bits=0) by restart.be (8.14.7/8.14.7) with ESMTP id r8BH1VUG027714 for ; Wed, 11 Sep 2013 19:01:32 +0200 (CEST) (envelope-from hlh@restart.be) X-Authentication-Warning: avoriaz.restart.bel: Host morzine.restart.be [IPv6:2001:41d0:8:bdbe:1:2::] claimed to be morzine.restart.bel Message-ID: <5230A1EB.9080201@restart.be> Date: Wed, 11 Sep 2013 19:01:31 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130820 Thunderbird/17.0.8 MIME-Version: 1.0 To: stable@freebsd.org Subject: Link error in usr.bin/dig if WITH_BIND_XML=yes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Sep 2013 17:01:42 -0000 Hello, Dig can't be linked if WITH_BIND_XML=yes is added to /etc/src.conf. [root@morzine src]# svn info Path: . Working Copy Root Path: /usr/src URL: http://svn.restart.bel/svn-FreeBSD-base/stable/9 Relative URL: ^/stable/9 Repository Root: http://svn.restart.bel/svn-FreeBSD-base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 255473 Node Kind: directory Schedule: normal Last Changed Author: des Last Changed Rev: 255443 Last Changed Date: 2013-09-10 12:07:21 +0200 (Tue, 10 Sep 2013) ===> usr.bin/dig (all) /usr/src/usr.bin/dig/../../contrib/bind9/bin/dig/dighost.c:4336:27: warning: passing 'const char *' to parameter of type 'void *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] isc_buffer_init(&buffer, str, len); ^~~ /usr/src/usr.bin/dig/../../contrib/bind9/lib/isc/include/isc/buffer.h:225:41: note: passing argument to parameter 'base' here isc__buffer_init(isc_buffer_t *b, void *base, unsigned int length); ^ 1 warning generated. /usr/local/lib/libxml2.a(xzlib.o): In function `__libxml2_xzclose': xzlib.c:(.text+0x69): undefined reference to `lzma_end' /usr/local/lib/libxml2.a(xzlib.o): In function `xz_decomp': xzlib.c:(.text+0x4a6): undefined reference to `lzma_code' /usr/local/lib/libxml2.a(xzlib.o): In function `xz_make': xzlib.c:(.text+0x8cd): undefined reference to `lzma_auto_decoder' xzlib.c:(.text+0xa04): undefined reference to `lzma_properties_decode' clang: error: linker command failed with exit code 1 (use -v to see invocation) *** [dig] Error code 1 Stop in /usr/src/usr.bin/dig. *** [all] Error code 1 Henri From owner-freebsd-stable@FreeBSD.ORG Wed Sep 11 17:19:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AD067377 for ; Wed, 11 Sep 2013 17:19:22 +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-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1E92229ED for ; Wed, 11 Sep 2013 17:19:21 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r8BHJDr2067195; Wed, 11 Sep 2013 20:19:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r8BHJDr2067195 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r8BHJDQG067194; Wed, 11 Sep 2013 20:19:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 11 Sep 2013 20:19:13 +0300 From: Konstantin Belousov To: Jimmy Olgeni Subject: Re: Possible kqueue related issue on STABLE/RC. Message-ID: <20130911171913.GG41229@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hf3PDeZ9a40C1ZbL" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Sep 2013 17:19:22 -0000 --hf3PDeZ9a40C1ZbL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 11, 2013 at 05:07:10PM +0200, Jimmy Olgeni wrote: > - However, this time I managed to get a minidump from the old -STABLE. I > saved it here: >=20 > http://olgeni.olgeni.com/~olgeni/core.txt.0 Could you list the lines around the the vfs_subr.c:4591 in your kernel ? Also, do you have all options listed at http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kernel= debug-deadlocks.html enabled ? > Unfortunately I'm not able to get a minidump for the latest RC, but at th= is > point I suspect that something is going on with glib20 and kqueue on both > -STABLE and -RC. Do you run software watchdog ? If not, try it. It might allow to get the dump if the problem is software. But if the problem is similar to what you have catched in core.0, this would be not helpful, while building the debugging kernel is. --hf3PDeZ9a40C1ZbL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSMKYQAAoJEJDCuSvBvK1Bz3AP/RJUDpebEjrSPaShUNoe6Tue +xWnwQdsnDAxBdG0mkbhbcQpBCBWCpx0wX+xot0sqGJKr8dk5kS0NZVS/NNT3iDG twxL/xEVUW8zaYm5KdCcLB3/Tyfza1Z2FbvJm1u1K9gjESlPaxS0iq8AJeQdPV4T UIb6hVwgOP/9njtVu+hynjWEMYQ9PcOLsE0glZD8u+z198Ez7x4U+0z9I3TiSuWB lCl7mT63CQnYKRtosZ9FP08UVb7ChxOtMC8ILMz1+2TdEzPudx9Mrsws0GHzXajF 5qKjeYPZtikgA/11JH8X11Z0GOVS5ksgAb5OOSHi7JMWsx5rSqf5FRSf8cCqeXjL kFBZH08bmRjzEvnV4dT4m2dYmpPlp2yzpEBsWxK8jxvVkFjU5Y5K5OOvaPbdU3WY YA+twSDz1beEQ7nrVwVxSkyX7C3YZNDe0ggOWCFcA7se2Z3pcCpRTBuXfVY/8Oi0 wu6oRRp34pmNNa+SXx9daJhH4WxiJtL5ra9b3Ue+TfCKr78L/c5JHh0V7qKIpXs5 vP3NOPfqBcBIaQWy4K6f3Y+yjfxwem/NMFsqIj7lrrwPMaGP9RwPJJw7huhM6e4/ JBGWmVydgYkETQxOtCzGz9X0QbzUeWRCgWtuw+bmqJpPWknAKhyIVaiPSSMI/C8a 3DB4y2nUAgDikGvikZNU =msEU -----END PGP SIGNATURE----- --hf3PDeZ9a40C1ZbL-- From owner-freebsd-stable@FreeBSD.ORG Wed Sep 11 19:38:14 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0327E4EA for ; Wed, 11 Sep 2013 19:38:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D005522D9 for ; Wed, 11 Sep 2013 19:38:13 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C66FCB9AE; Wed, 11 Sep 2013 15:38:12 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: 9.2-PRERELEASE #0 r254557 amd64: core dump on shutdown Date: Wed, 11 Sep 2013 11:11:24 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20130910165055.da25cd4234c283dafef39462@mimar.rs> In-Reply-To: <20130910165055.da25cd4234c283dafef39462@mimar.rs> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201309111111.24477.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 11 Sep 2013 15:38:12 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Sep 2013 19:38:14 -0000 On Tuesday, September 10, 2013 10:50:55 am Marko Cupa=C4=87 wrote: > My 9.2-PRERELEASE #0 r254557 amd64 just dumped core on shutdown. I > updated src to Last Changed Rev: 255395 two days ago but did not get > to rebuild world&kernel. Also I did not rebuild any ports since. > Virtualbox was not running. >=20 > pacija@kaa:/var/crash % uname -a > FreeBSD kaa.mimar.rs 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r254557: Su= n=20 Aug 25 22:44:52 CEST 2013 pacija@kaa.mimar.rs:/usr/obj/usr/src/sys/KAAG= EN =20 amd64 >=20 > pacija@kaa:/var/crash % sudo cat core.txt.2=20 > kaa.mimar.rs dumped core - see /var/crash/vmcore.2 >=20 > Tue Sep 10 16:41:45 CEST 2013 >=20 > FreeBSD kaa.mimar.rs 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r254557: Su= n=20 Aug 25 22:44:52 CEST 2013 pacija@kaa.mimar.rs:/usr/obj/usr/src/sys/KAAG= EN =20 amd64 >=20 > panic: page fault Is this reproducible? > #6 0xffffffff80cdc843 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:232 > #7 0xffffffff80b71085 in swapoff_one (sp=3D0xfffffe0006296600,=20 > cred=3D0xfffffe00037a0e00) at /usr/src/sys/vm/swap_pager.c:1753 Relevant line is: 1753 for (swap =3D swhash[i]; swap !=3D NULL; swap =3D swap->swb_hnext) { =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Sep 11 20:32:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CAC35B73 for ; Wed, 11 Sep 2013 20:32:13 +0000 (UTC) (envelope-from olgeni@olgeni.com) Received: from olgeni.olgeni.com (host-156-246-171-31.cloudsigma.com [31.171.246.156]) by mx1.freebsd.org (Postfix) with ESMTP id 9043A2669 for ; Wed, 11 Sep 2013 20:32:13 +0000 (UTC) Received: from olgeni.olgeni (unknown [82.84.82.178]) by olgeni.olgeni.com (Postfix) with ESMTPSA id 2C5C0174482; Wed, 11 Sep 2013 22:32:12 +0200 (CEST) Date: Wed, 11 Sep 2013 22:32:11 +0200 (CEST) From: Jimmy Olgeni X-X-Sender: olgeni@olgeni.olgeni To: Volodymyr Kostyrko Subject: Re: Possible kqueue related issue on STABLE/RC. In-Reply-To: <52308D30.6020502@gmail.com> Message-ID: References: <52308D30.6020502@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Konstantin Belousov , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Sep 2013 20:32:13 -0000 On Wed, 11 Sep 2013, Volodymyr Kostyrko wrote: > Can you try to build world WITH_CLANG_IS_CC? Clang generated code is known to > produce an instant coredump in situations where gcc generated code hits a > loop or becomes unresponsive. I removed ccache, rebuilt with WITH_CLANG_IS_CC and it worked for a while, but then I got a hard reset without even a core dump. I'm rebuilding with Konstantin's kernel debug options plus software watchdog and trying another round. -- jimmy From owner-freebsd-stable@FreeBSD.ORG Wed Sep 11 20:32:33 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2E5ACC78 for ; Wed, 11 Sep 2013 20:32:33 +0000 (UTC) (envelope-from olgeni@olgeni.com) Received: from olgeni.olgeni.com (host-156-246-171-31.cloudsigma.com [31.171.246.156]) by mx1.freebsd.org (Postfix) with ESMTP id E8F662672 for ; Wed, 11 Sep 2013 20:32:32 +0000 (UTC) Received: from olgeni.olgeni (unknown [82.84.82.178]) by olgeni.olgeni.com (Postfix) with ESMTPSA id 25707174482; Wed, 11 Sep 2013 22:32:32 +0200 (CEST) Date: Wed, 11 Sep 2013 22:32:31 +0200 (CEST) From: Jimmy Olgeni X-X-Sender: olgeni@olgeni.olgeni To: Konstantin Belousov Subject: Re: Possible kqueue related issue on STABLE/RC. In-Reply-To: <20130911171913.GG41229@kib.kiev.ua> Message-ID: References: <20130911171913.GG41229@kib.kiev.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Sep 2013 20:32:33 -0000 Hi, On Wed, 11 Sep 2013, Konstantin Belousov wrote: > Could you list the lines around the the vfs_subr.c:4591 in your kernel ? 4591 is the VI_LOCK(vp) in filt_vfsvnode: static int filt_vfsvnode(struct knote *kn, long hint) { struct vnode *vp = (struct vnode *)kn->kn_hook; int res; VI_LOCK(vp); if (kn->kn_sfflags & hint) kn->kn_fflags |= hint; if (hint == NOTE_REVOKE) { kn->kn_flags |= EV_EOF; VI_UNLOCK(vp); return (1); } res = (kn->kn_fflags != 0); VI_UNLOCK(vp); return (res); } Next test with INVARIANTS & C as soon as the build is done. -- jimmy From owner-freebsd-stable@FreeBSD.ORG Wed Sep 11 21:18:36 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AD9E3834 for ; Wed, 11 Sep 2013 21:18:36 +0000 (UTC) (envelope-from olgeni@olgeni.com) Received: from olgeni.olgeni.com (host-156-246-171-31.cloudsigma.com [31.171.246.156]) by mx1.freebsd.org (Postfix) with ESMTP id 73FEA291C for ; Wed, 11 Sep 2013 21:18:35 +0000 (UTC) Received: from olgeni.olgeni (unknown [82.84.82.178]) by olgeni.olgeni.com (Postfix) with ESMTPSA id C6B60174482; Wed, 11 Sep 2013 23:18:34 +0200 (CEST) Date: Wed, 11 Sep 2013 23:18:34 +0200 (CEST) From: Jimmy Olgeni X-X-Sender: olgeni@olgeni.olgeni To: Konstantin Belousov Subject: Re: Possible kqueue related issue on STABLE/RC. In-Reply-To: <20130911171913.GG41229@kib.kiev.ua> Message-ID: References: <20130911171913.GG41229@kib.kiev.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Sep 2013 21:18:36 -0000 Hi, On Wed, 11 Sep 2013, Konstantin Belousov wrote: > Also, do you have all options listed at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > enabled ? This time I tried with clang + these options and I got something more interesting. All works fine until the lock violation below: acquiring duplicate lock of same type: "os.lock_mtx" 1st os.lock_mtx @ nvidia_os.c:748 2nd os.lock_mtx @ nvidia_os.c:748 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff8360e1e2f0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8360e1e3a0 witness_checkorder() at witness_checkorder+0xc0a/frame 0xffffff8360e1e420 _mtx_lock_flags() at _mtx_lock_flags+0x74/frame 0xffffff8360e1e460 os_acquire_spinlock() at os_acquire_spinlock+0x17/frame 0xffffff8360e1e470 _nv012281rm() at _nv012281rm+0x9/frame 0xffffff800cfadec0 lock order reversal: 1st 0xfffffe003603c098 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1240 2nd 0xfffffe003603b848 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2335 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff8360bf3660 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8360bf3710 witness_checkorder() at witness_checkorder+0xc0a/frame 0xffffff8360bf3790 __lockmgr_args() at __lockmgr_args+0x744/frame 0xffffff8360bf38b0 vop_stdlock() at vop_stdlock+0x3c/frame 0xffffff8360bf38d0 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbe/frame 0xffffff8360bf3900 _vn_lock() at _vn_lock+0x63/frame 0xffffff8360bf3960 vputx() at vputx+0x34b/frame 0xffffff8360bf39c0 dounmount() at dounmount+0x282/frame 0xffffff8360bf3a30 sys_unmount() at sys_unmount+0x3a6/frame 0xffffff8360bf3b20 amd64_syscall() at amd64_syscall+0x259/frame 0xffffff8360bf3c30 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff8360bf3c30 --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x801918a7c, rsp = 0x7fffffffbf18, rbp = 0x802818800 --- KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff83611df6b0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff83611df760 assert_vop_elocked() at assert_vop_elocked+0x6a/frame 0xffffff83611df790 fifo_open() at fifo_open+0x38/frame 0xffffff83611df810 VOP_OPEN_APV() at VOP_OPEN_APV+0xd1/frame 0xffffff83611df840 vn_open_cred() at vn_open_cred+0x532/frame 0xffffff83611df9b0 kern_openat() at kern_openat+0x1c1/frame 0xffffff83611dfb20 amd64_syscall() at amd64_syscall+0x259/frame 0xffffff83611dfc30 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff83611dfc30 Here it goes: --- syscall (5, FreeBSD ELF64, sys_open), rip = 0x800db3d3c, rsp = 0x7fffffffc968, rbp = 0 --- fifo_open: 0xfffffe0063251cd0 is not exclusive locked but should be KDB: enter: lock violation 0xfffffe0063251cd0: tag zfs, type VFIFO usecount 2, writecount 0, refcount 2 mountedhere 0xfffffe005048cc00 flags (VI_ACTIVE) lock type zfs: SHARED (count 1) #0 0xffffffff808b22fa at __lockmgr_args+0xeba #1 0xffffffff8095df4c at vop_stdlock+0x3c #2 0xffffffff80d7f6ae at VOP_LOCK1_APV+0xbe #3 0xffffffff80980153 at _vn_lock+0x63 #4 0xffffffff8096e321 at vget+0xa1 #5 0xffffffff80959921 at cache_lookup_times+0x591 #6 0xffffffff8095aa7d at vfs_cache_lookup+0x9d #7 0xffffffff80d7c881 at VOP_LOOKUP_APV+0xd1 #8 0xffffffff80963aff at lookup+0x6bf #9 0xffffffff80963029 at namei+0x589 #10 0xffffffff8097fa0f at vn_open_cred+0x27f #11 0xffffffff80978031 at kern_openat+0x1c1 #12 0xffffffff80ccce49 at amd64_syscall+0x259 #13 0xffffffff80cb5e9b at Xfast_syscall+0xfb , fifo with 0 readers and 1 writers 0xfffffe00a21d3000: tag zfs, type VREG usecount 4, writecount 0, refcount 5 mountedhere 0 flags (VI_ACTIVE) v_object 0xfffffe00a0f71bc8 ref 3 pages 150 lock type zfs: SHARED (count 1) #0 0xffffffff808b22fa at __lockmgr_args+0xeba #1 0xffffffff8095df4c at vop_stdlock+0x3c #2 0xffffffff80d7f6ae at VOP_LOCK1_APV+0xbe #3 0xffffffff80980153 at _vn_lock+0x63 #4 0xffffffff8096e321 at vget+0xa1 #5 0xffffffff80b4e1de at vm_fault_hold+0x5ee #6 0xffffffff80b4dba7 at vm_fault+0x77 #7 0xffffffff80ccc85b at trap_pfault+0x1bb #8 0xffffffff80ccbf92 at trap+0x512 #9 0xffffffff80cb5bb2 at calltrap+0x8 0xfffffe0195389290: tag zfs, type VREG usecount 4, writecount 0, refcount 5 mountedhere 0 flags (VI_ACTIVE) v_object 0xfffffe000f2df740 ref 3 pages 223 lock type zfs: SHARED (count 1) #0 0xffffffff808b22fa at __lockmgr_args+0xeba #1 0xffffffff8095df4c at vop_stdlock+0x3c #2 0xffffffff80d7f6ae at VOP_LOCK1_APV+0xbe #3 0xffffffff80980153 at _vn_lock+0x63 #4 0xffffffff8096e321 at vget+0xa1 #5 0xffffffff80b4e1de at vm_fault_hold+0x5ee #6 0xffffffff80b4dba7 at vm_fault+0x77 #7 0xffffffff80ccc85b at trap_pfault+0x1bb #8 0xffffffff80ccbf92 at trap+0x512 #9 0xffffffff80cb5bb2 at calltrap+0x8 0xfffffe00a2207000: tag zfs, type VREG usecount 4, writecount 0, refcount 5 mountedhere 0 flags (VI_ACTIVE) v_object 0xfffffe000f0b8d98 ref 3 pages 201 lock type zfs: SHARED (count 1) #0 0xffffffff808b22fa at __lockmgr_args+0xeba #1 0xffffffff8095df4c at vop_stdlock+0x3c #2 0xffffffff80d7f6ae at VOP_LOCK1_APV+0xbe #3 0xffffffff80980153 at _vn_lock+0x63 #4 0xffffffff8096e321 at vget+0xa1 #5 0xffffffff80b4e1de at vm_fault_hold+0x5ee #6 0xffffffff80b4dba7 at vm_fault+0x77 #7 0xffffffff80ccc85b at trap_pfault+0x1bb #8 0xffffffff80ccbf92 at trap+0x512 #9 0xffffffff80cb5bb2 at calltrap+0x8 -- jimmy From owner-freebsd-stable@FreeBSD.ORG Wed Sep 11 22:39:04 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5173CFCC for ; Wed, 11 Sep 2013 22:39:04 +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 185472D6C for ; Wed, 11 Sep 2013 22:39:03 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAF/wMFKDaFve/2dsb2JhbABbFoMpUoMqvFyBM3SCJQEBAQQBAQEgKyALGw4KAgINGQIpAQkmBggHBAEcBIdhDK1ekXCBKY0IgQU0B4JpgTQDlS6DepBDgz4gMoEDOQ X-IronPort-AV: E=Sophos;i="4.90,887,1371096000"; d="scan'208";a="52098179" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 11 Sep 2013 18:38:48 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id EF402B3EE1; Wed, 11 Sep 2013 18:38:48 -0400 (EDT) Date: Wed, 11 Sep 2013 18:38:48 -0400 (EDT) From: Rick Macklem To: Mark Saad Message-ID: <852861204.22141010.1378939128966.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: nfsd CPU usage? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: stable@freebsd.org, Lars Eggert X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Sep 2013 22:39:04 -0000 Mark Saad wrote: > Rick > Would this affect 9.2-RCn ? > Yes (and 9.2 when it is released). If the CPU overheads (same as 9.0, 9.1) are an issue for your server, you can apply the patch or switch to the old nfs server or disable the DRC for TCP by editting the sources and setting nfsrc_tcpnonidempotent = 0; as explained below. rick > --- > Mark saad | mark.saad@longcount.org > > > On Sep 11, 2013, at 7:54 AM, Rick Macklem > wrote: > > > Lars Eggert wrote: > >> Hi, > >> > >> I'm seeing extremely high CPU usage withssh-st the new nfsd: > >> > >> PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU > >> COMMAND > >> 2280 root 102 0 9932K 1376K *nfs_c 0 320:11 100.00% > >> nfsd{nfsd: service} > >> 2280 root 102 0 9932K 1376K CPU7 7 319:47 100.00% > >> nfsd{nfsd: service} > >> 2280 root 102 0 9932K 1376K CPU5 5 318:25 100.00% > >> nfsd{nfsd: service} > >> 2280 root 102 0 9932K 1376K CPU6 6 318:20 100.00% > >> nfsd{nfsd: service} > >> 2280 root 52 0 9932K 1376K CPU0 0 317:32 100.00% > >> nfsd{nfsd: service} > >> 2280 root 102 0 9932K 1376K *nfs_c 1 315:41 99.17% > >> nfsd{nfsd: service} > >> 2280 root 52 0 9932K 1376K *nfs_c 4 320:22 98.78% > >> nfsd{nfsd: master} > >> 2280 root 102 0 9932K 1376K *nfs_c 1 317:10 98.10% > >> nfsd{nfsd: service} > >> > >> And this is at a few hundred KB/s with only a few clients: > >> > >> ifstat -i igb1 10 > >> igb1 > >> KB/s in KB/s out > >> 796.56 208.66 > >> 431.19 232.36 > >> 316.11 280.31 > >> 1005.96 523.42 > >> 1077.74 342.25 > >> 340.63 217.73 > >> 1067.96 330.56 > >> 487.91 235.61 > >> > >> Any ideas? > >> > >> FreeBSD stanley.muccbc.hq.netapp.com 9.2-PRERELEASE FreeBSD > >> 9.2-PRERELEASE #7: Wed Sep 4 11:06:31 CEST 2013 > >> root@stanley.muccbc.hq.netapp.com:/usr/obj/usr/src/sys/STANLEY > >> amd64 > >> > >> Thanks, > >> Lars > > There is a patch in head (r254337) that I believe handles this. > > It will be MFC'd to stable/9 in about a week, unless someone finds > > problems with it before then. > > If you want a semantically equivalent (but uglier code) patch, > > you can find it here: > > http://people.freebsd.org/~rmacklem/drc4-stable9.patch > > After applying the patch, you need to set sysctl variable(s), > > to avoid the aggressive trimming of stale DRC entries. Garrett > > Wollman suggests the following for a large server: > > vfs.nfsd.tcphighwater=100000 > > vfs.nfsd.tcpcachetimeout=300 (5 minutes instead of default of > > several hrs) > > > > You can also use the sysctl > > vfs.nfsd.cachetcp=0 > > to disable use of the DRC for TCP. > > > > The old nfs server did not use the DRC for TCP. The assumption > > being that > > TCP layer retransmits are good enough to maintain reliable RPC > > transport. > > Unfortuantely, you can get file corruption when the server reboots > > or > > there is a network partitioning, if the client chooses to redo the > > RPC > > over TCP (clients always do this after having to create a new TCP > > connection). > > In other words, vfs.nfsd.cachetcp=0 is roughly what the old nfsd > > did. > > > > If you don't want to patch the 9.2 code, you can edit the sources > > (sys/fs/nfsserver/nfs_nfsdcache.c) and change the line: > > static int nfsrc_tcpnonidempotent = 1; > > to > > static int nfsrc_tcpnonidempotent = 0; > > to do the same thing as vfs.nfsd.cachetcp=0 > > > > rick > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to > > "freebsd-stable-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://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 Sep 12 05:29:51 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 647736B; Thu, 12 Sep 2013 05:29:51 +0000 (UTC) (envelope-from marko.cupac@mimar.rs) Received: from www.mimar.rs (www.mimar.rs [193.53.106.101]) by mx1.freebsd.org (Postfix) with ESMTP id 1E2B32096; Thu, 12 Sep 2013 05:29:50 +0000 (UTC) Received: from kaa.mimar.rs (178-221-85-142.dynamic.isp.telekom.rs [178.221.85.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marko.cupac@mimar.rs) by www.mimar.rs (Postfix) with ESMTPSA id 15DC9B902C; Thu, 12 Sep 2013 07:29:42 +0200 (CEST) Date: Thu, 12 Sep 2013 07:29:40 +0200 From: Marko =?UTF-8?B?Q3VwYcSH?= To: freebsd-stable@freebsd.org Subject: Re: 9.2-PRERELEASE #0 r254557 amd64: core dump on shutdown Message-Id: <20130912072940.440a452d22aa2415c1226ca1@mimar.rs> In-Reply-To: <201309111111.24477.jhb@freebsd.org> References: <20130910165055.da25cd4234c283dafef39462@mimar.rs> <201309111111.24477.jhb@freebsd.org> Organization: Mimar X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; amd64-portbld-freebsd9.2) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Sep 2013 05:29:51 -0000 On Wed, 11 Sep 2013 11:11:24 -0400 John Baldwin wrote: > Is this reproducible? It happened a few times before (maybe 3-4 times this year), but I can't reproduce it intentionally. -- Marko Cupać From owner-freebsd-stable@FreeBSD.ORG Thu Sep 12 07:36:53 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9C8903E0 for ; Thu, 12 Sep 2013 07:36:53 +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-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2011F2705 for ; Thu, 12 Sep 2013 07:36:52 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r8C7ahRW048261; Thu, 12 Sep 2013 10:36:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r8C7ahRW048261 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r8C7ahAk048260; Thu, 12 Sep 2013 10:36:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 12 Sep 2013 10:36:43 +0300 From: Konstantin Belousov To: Jimmy Olgeni Subject: Re: Possible kqueue related issue on STABLE/RC. Message-ID: <20130912073643.GM41229@kib.kiev.ua> References: <20130911171913.GG41229@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dhq2JOS40XFo2g0l" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Sep 2013 07:36:53 -0000 --dhq2JOS40XFo2g0l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 11, 2013 at 11:18:34PM +0200, Jimmy Olgeni wrote: >=20 > Hi, >=20 > On Wed, 11 Sep 2013, Konstantin Belousov wrote: >=20 > > Also, do you have all options listed at > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ke= rneldebug-deadlocks.html > > enabled ? >=20 > This time I tried with clang + these options and I got something more=20 > interesting. All works fine until the lock violation below: Clang is, well, not relevant there. >=20 > acquiring duplicate lock of same type: "os.lock_mtx" > 1st os.lock_mtx @ nvidia_os.c:748 > 2nd os.lock_mtx @ nvidia_os.c:748 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff8360e= 1e2f0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8360e1e3a0 > witness_checkorder() at witness_checkorder+0xc0a/frame 0xffffff8360e1e420 > _mtx_lock_flags() at _mtx_lock_flags+0x74/frame 0xffffff8360e1e460 > os_acquire_spinlock() at os_acquire_spinlock+0x17/frame 0xffffff8360e1e470 > _nv012281rm() at _nv012281rm+0x9/frame 0xffffff800cfadec0 > lock order reversal: > 1st 0xfffffe003603c098 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1240 > 2nd 0xfffffe003603b848 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2= 335 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff8360b= f3660 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8360bf3710 > witness_checkorder() at witness_checkorder+0xc0a/frame 0xffffff8360bf3790 > __lockmgr_args() at __lockmgr_args+0x744/frame 0xffffff8360bf38b0 > vop_stdlock() at vop_stdlock+0x3c/frame 0xffffff8360bf38d0 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbe/frame 0xffffff8360bf3900 > _vn_lock() at _vn_lock+0x63/frame 0xffffff8360bf3960 > vputx() at vputx+0x34b/frame 0xffffff8360bf39c0 > dounmount() at dounmount+0x282/frame 0xffffff8360bf3a30 > sys_unmount() at sys_unmount+0x3a6/frame 0xffffff8360bf3b20 > amd64_syscall() at amd64_syscall+0x259/frame 0xffffff8360bf3c30 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff8360bf3c30 > --- syscall (22, FreeBSD ELF64, sys_unmount), rip =3D 0x801918a7c, rsp = =3D 0x7fffffffbf18, rbp =3D 0x802818800 --- > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff83611= df6b0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff83611df760 > assert_vop_elocked() at assert_vop_elocked+0x6a/frame 0xffffff83611df790 > fifo_open() at fifo_open+0x38/frame 0xffffff83611df810 > VOP_OPEN_APV() at VOP_OPEN_APV+0xd1/frame 0xffffff83611df840 > vn_open_cred() at vn_open_cred+0x532/frame 0xffffff83611df9b0 > kern_openat() at kern_openat+0x1c1/frame 0xffffff83611dfb20 > amd64_syscall() at amd64_syscall+0x259/frame 0xffffff83611dfc30 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff83611dfc30 >=20 >=20 > Here it goes: >=20 >=20 > --- syscall (5, FreeBSD ELF64, sys_open), rip =3D 0x800db3d3c, rsp =3D 0x= 7fffffffc968, rbp =3D 0 --- > fifo_open: 0xfffffe0063251cd0 is not exclusive locked but should be > KDB: enter: lock violation >=20 > 0xfffffe0063251cd0: tag zfs, type VFIFO > usecount 2, writecount 0, refcount 2 mountedhere 0xfffffe005048cc00 > flags (VI_ACTIVE) > lock type zfs: SHARED (count 1) > #0 0xffffffff808b22fa at __lockmgr_args+0xeba > #1 0xffffffff8095df4c at vop_stdlock+0x3c > #2 0xffffffff80d7f6ae at VOP_LOCK1_APV+0xbe > #3 0xffffffff80980153 at _vn_lock+0x63 > #4 0xffffffff8096e321 at vget+0xa1 > #5 0xffffffff80959921 at cache_lookup_times+0x591 > #6 0xffffffff8095aa7d at vfs_cache_lookup+0x9d > #7 0xffffffff80d7c881 at VOP_LOOKUP_APV+0xd1 > #8 0xffffffff80963aff at lookup+0x6bf > #9 0xffffffff80963029 at namei+0x589 > #10 0xffffffff8097fa0f at vn_open_cred+0x27f > #11 0xffffffff80978031 at kern_openat+0x1c1 > #12 0xffffffff80ccce49 at amd64_syscall+0x259 > #13 0xffffffff80cb5e9b at Xfast_syscall+0xfb > , fifo with 0 readers and 1 writers It seems you edited the kernel output, at least rearranging large blocks of text. I tried to interpret what I see in a useful way. Might be, your issue is that some filesystems do not care about proper locking mode for the fifos. UFS carefully disables shared locking for VFIFO, but it seems ZFS is not. I can propose the following band-aid, which could help you. I have no idea is it the same issue as the kqueue panic. diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c index c53030a..00bd998 100644 --- a/sys/kern/vfs_vnops.c +++ b/sys/kern/vfs_vnops.c @@ -267,6 +267,8 @@ vn_open_vnode(struct vnode *vp, int fmode, struct ucred= *cred, return (error); } } + if (vp->v_type =3D=3D VFIFO && VOP_ISLOCKED(vp) !=3D LK_EXCLUSIVE) + vn_lock(vp, LK_UPGRADE | LK_RETRY); if ((error =3D VOP_OPEN(vp, fmode, cred, td, fp)) !=3D 0) return (error); =20 @@ -358,7 +360,7 @@ vn_close(vp, flags, file_cred, td) struct mount *mp; int error, lock_flags; =20 - if (!(flags & FWRITE) && vp->v_mount !=3D NULL && + if (vp->v_type !=3D VFIFO && !(flags & FWRITE) && vp->v_mount !=3D NULL && vp->v_mount->mnt_kern_flag & MNTK_EXTENDED_SHARED) lock_flags =3D LK_SHARED; else --dhq2JOS40XFo2g0l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSMW8KAAoJEJDCuSvBvK1B2UUP/2i9sQ15vwor1+Uiiz/W9IFt 2II3kbht/Mtexoxd24OU0SDor9owVrVzpimWbS+h5BL3SGfD8+y3PQSmf64Rv5qZ 5jOr4XwTpn27YEVLE/ep8nJthuClYgK8e/5TojlroYOVe/O3Ib4AggrWJ6IqLKvH HjUFFqdTQ4jIr8KtwPJCzoz0uQyGzSL+3HEA8wZKoMON1wDxjh4oMZuYjk10EnSA oVZbpJCgohwRo3jjwSSiFPvCUrJNrICK7uEjUK89sE37bFwf9NaQLBINm5EOO6sy V726Zfsi8YT5cuoZpgbzljw8WZgbcsi+MGOi9fOav3GOQZ+oorijuDQaF+dRNQVw oD4pm/X1LDPH9OvJ81KtA8d2iL88dzdBkbQ0yUQm9639f2UfSWqo6JgMvNCajob2 RWXKMgI0aUk5Ogk4eGo/fZEe/idKsi02uCXD3SA83CO2bODQmAq6sdHgqa5/HNR8 W5BQOmdapjr8EUw3K5BnJHr/W+KEw6Makk2KxEYJKQ8JXWFxijCjRKblxmOif0g4 yLrtts9LBu4heWHg3/rm1qAwFDN2uTldvuNgSwoP3hf1gmx8UKJbiv/Wk3C11Yi9 JYoq23DOKlwEI4Kxs2b7Ba2tTRMNhiX0o6TRg92idbM9TfEqcabIaa2gLy+z5MB0 b24TvhONzstOW134hPdz =7S8r -----END PGP SIGNATURE----- --dhq2JOS40XFo2g0l-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 12 07:37:19 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 193A04E6 for ; Thu, 12 Sep 2013 07:37:19 +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-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7D13E2717 for ; Thu, 12 Sep 2013 07:37:18 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r8C7bE92048277; Thu, 12 Sep 2013 10:37:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r8C7bE92048277 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r8C7bEZr048276; Thu, 12 Sep 2013 10:37:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 12 Sep 2013 10:37:14 +0300 From: Konstantin Belousov To: Jimmy Olgeni Subject: Re: Possible kqueue related issue on STABLE/RC. Message-ID: <20130912073714.GN41229@kib.kiev.ua> References: <20130911171913.GG41229@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="R2Ly8POFKoO+8OH1" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Sep 2013 07:37:19 -0000 --R2Ly8POFKoO+8OH1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 11, 2013 at 10:32:31PM +0200, Jimmy Olgeni wrote: >=20 > Hi, >=20 > On Wed, 11 Sep 2013, Konstantin Belousov wrote: >=20 > > Could you list the lines around the the vfs_subr.c:4591 in your kernel ? >=20 > 4591 is the VI_LOCK(vp) in filt_vfsvnode: >=20 > static int > filt_vfsvnode(struct knote *kn, long hint) > { > struct vnode *vp =3D (struct vnode *)kn->kn_hook; > int res; >=20 > VI_LOCK(vp); > if (kn->kn_sfflags & hint) > kn->kn_fflags |=3D hint; > if (hint =3D=3D NOTE_REVOKE) { > kn->kn_flags |=3D EV_EOF; > VI_UNLOCK(vp); > return (1); > } > res =3D (kn->kn_fflags !=3D 0); > VI_UNLOCK(vp); > return (res); > } Which line is 4591 ? >=20 >=20 > Next test with INVARIANTS & C as soon as the build is done. >=20 > --=20 > jimmy --R2Ly8POFKoO+8OH1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSMW8pAAoJEJDCuSvBvK1Bg+gP/iPT1/2rFPQ58eONd3MFM9gu hU+ngDV/AFuBDNcV5usdEbEV0Zq7OITt0WBJqZsM/ghVyDaLXQ62LOljwpneWImw XhKaPmj9/jZ13BBgmD9ybBwFhrAsYhsSIJGJe5urpi/Z9cjIncIE4q6GDseafUH3 zKKgi89BmgcH2Vba5tVJMWOKjSjYzyBKCVNuzyHpprNrKPWTw08iLWAKydi+tYgB vkQXPS9JGWQCKRE8bDyOjpWyc2RuaA3OEn89GvVjpHl+77W0eUiYonLcFy5OIIbh yDEw94wcw1EUIE77dYpP3eBSxkoa8unxoe/Rmj+7wJwoYSgBxxV08ASN4W/hsKQW 2RYfWeIz0ynAIYhqSJ/iAxyow39AYYuy4nT0b7Ac+8YRuVPYAiMd5FBY9kD4Cczv Gza8LIftZ40NGc7JnKTe65UjGhS0LK48CbFgxHBFXqlWBo5O/nVPF2I/mjxWrm6F 4Qfw5p09yd2XbVcXfi3anbM7wHxfzSaWyZPqaI5kbPGs0YgQao7ghBAPt+EUwzz7 wq/INpiQel/c1L2RQDAZRxoloU0Ps6/oOYfKAz8arS0oDafRELQEqlVgUvhPiRK+ vb10z8XpV9jjaK0EUd/tbiByCTzrsD53sms853m9A1sMj6phcGgO1M26Zg2X7rIU HGxYdl21m9gAkkRYnJ8D =M2kJ -----END PGP SIGNATURE----- --R2Ly8POFKoO+8OH1-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 12 07:45:52 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5ADD08FE for ; Thu, 12 Sep 2013 07:45:52 +0000 (UTC) (envelope-from olgeni@olgeni.com) Received: from olgeni.olgeni.com (host-156-246-171-31.cloudsigma.com [31.171.246.156]) by mx1.freebsd.org (Postfix) with ESMTP id 1FF78280F for ; Thu, 12 Sep 2013 07:45:51 +0000 (UTC) Received: from [192.168.0.196] (93-62-212-84.ip24.fastwebnet.it [93.62.212.84]) by olgeni.olgeni.com (Postfix) with ESMTPSA id 43101174482; Thu, 12 Sep 2013 09:45:49 +0200 (CEST) Date: Thu, 12 Sep 2013 09:45:48 +0200 (CEST) From: Jimmy Olgeni X-X-Sender: olgeni@localhost.my.domain To: Konstantin Belousov Subject: Re: Possible kqueue related issue on STABLE/RC. In-Reply-To: <20130912073643.GM41229@kib.kiev.ua> Message-ID: References: <20130911171913.GG41229@kib.kiev.ua> <20130912073643.GM41229@kib.kiev.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Sep 2013 07:45:52 -0000 On Thu, 12 Sep 2013, Konstantin Belousov wrote: >> This time I tried with clang + these options and I got something more >> interesting. All works fine until the lock violation below: > Clang is, well, not relevant there. Still, with clang I could get a hard reset rather than a hang. But maybe there are two different issues. I'll run more tests and see if the fifo problem goes away with your patch below. > It seems you edited the kernel output, at least rearranging large blocks > of text. I tried to interpret what I see in a useful way. I got the message buffer from a minidump, here: http://olgeni.olgeni.com/~olgeni/textdump.tar.1 > Might be, your issue is that some filesystems do not care about proper > locking mode for the fifos. UFS carefully disables shared locking for > VFIFO, but it seems ZFS is not. I can propose the following band-aid, > which could help you. Thanks a lot! I'll give it a run when I get back home. -- jimmy From owner-freebsd-stable@FreeBSD.ORG Thu Sep 12 07:47:00 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 09644A43 for ; Thu, 12 Sep 2013 07:47:00 +0000 (UTC) (envelope-from olgeni@olgeni.com) Received: from olgeni.olgeni.com (host-156-246-171-31.cloudsigma.com [31.171.246.156]) by mx1.freebsd.org (Postfix) with ESMTP id C29B42836 for ; Thu, 12 Sep 2013 07:46:59 +0000 (UTC) Received: from [192.168.0.196] (93-62-212-84.ip24.fastwebnet.it [93.62.212.84]) by olgeni.olgeni.com (Postfix) with ESMTPSA id B639C1744A7; Thu, 12 Sep 2013 09:46:58 +0200 (CEST) Date: Thu, 12 Sep 2013 09:46:58 +0200 (CEST) From: Jimmy Olgeni X-X-Sender: olgeni@localhost.my.domain To: Konstantin Belousov Subject: Re: Possible kqueue related issue on STABLE/RC. In-Reply-To: <20130912073714.GN41229@kib.kiev.ua> Message-ID: References: <20130911171913.GG41229@kib.kiev.ua> <20130912073714.GN41229@kib.kiev.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Sep 2013 07:47:00 -0000 On Thu, 12 Sep 2013, Konstantin Belousov wrote: >> 4591 is the VI_LOCK(vp) in filt_vfsvnode: >> >> static int >> filt_vfsvnode(struct knote *kn, long hint) >> { >> struct vnode *vp = (struct vnode *)kn->kn_hook; >> int res; >> >> VI_LOCK(vp); ^^^^^^^^^^^ >> if (kn->kn_sfflags & hint) >> kn->kn_fflags |= hint; >> if (hint == NOTE_REVOKE) { >> kn->kn_flags |= EV_EOF; >> VI_UNLOCK(vp); >> return (1); >> } >> res = (kn->kn_fflags != 0); >> VI_UNLOCK(vp); >> return (res); >> } > Which line is 4591 ? "VI_LOCK(vp);" which bumps into the assertion. -- jimmy From owner-freebsd-stable@FreeBSD.ORG Thu Sep 12 11:07:05 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D0F1F9A4 for ; Thu, 12 Sep 2013 11:07:05 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 26C082907 for ; Thu, 12 Sep 2013 11:07:04 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA28753; Thu, 12 Sep 2013 14:06:54 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VK4je-000K4y-7b; Thu, 12 Sep 2013 14:06:54 +0300 Message-ID: <5231A016.7060906@FreeBSD.org> Date: Thu, 12 Sep 2013 14:05:58 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Possible kqueue related issue on STABLE/RC. References: <20130911171913.GG41229@kib.kiev.ua> <20130912073643.GM41229@kib.kiev.ua> In-Reply-To: <20130912073643.GM41229@kib.kiev.ua> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, Jimmy Olgeni X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Sep 2013 11:07:05 -0000 on 12/09/2013 10:36 Konstantin Belousov said the following: > UFS carefully disables shared locking for > VFIFO, but it seems ZFS is not. In fact, ZFS should do that since r253603 (MFC-ed to stables as r254694 and r254695): http://svnweb.freebsd.org/changeset/base/253603 If it still doesn't then it's a bug. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Sep 12 16:00:00 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 411504B2 for ; Thu, 12 Sep 2013 16:00:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1A17D2CAE for ; Thu, 12 Sep 2013 16:00:00 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1E637B977; Thu, 12 Sep 2013 11:59:59 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: 9.2-PRERELEASE #0 r254557 amd64: core dump on shutdown Date: Thu, 12 Sep 2013 10:15:28 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20130910165055.da25cd4234c283dafef39462@mimar.rs> <201309111111.24477.jhb@freebsd.org> <20130912072940.440a452d22aa2415c1226ca1@mimar.rs> In-Reply-To: <20130912072940.440a452d22aa2415c1226ca1@mimar.rs> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201309121015.28884.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 12 Sep 2013 11:59:59 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Sep 2013 16:00:00 -0000 On Thursday, September 12, 2013 1:29:40 am Marko Cupa=C4=87 wrote: > On Wed, 11 Sep 2013 11:11:24 -0400 > John Baldwin wrote: >=20 > > Is this reproducible? >=20 > It happened a few times before (maybe 3-4 times this year), but I can't > reproduce it intentionally. Hmm, I'm tempted to chalk this up to a hardware failure then. =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Sep 12 17:19:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E2185DF7 for ; Thu, 12 Sep 2013 17:19:23 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6D25921E0 for ; Thu, 12 Sep 2013 17:19:23 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id hm2so110932wib.6 for ; Thu, 12 Sep 2013 10:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=NMJP6m23r4sRlL3g9g8cvdBfYV9VFDjL24CYUNZMXe0=; b=QF+q4ph/CcJNYUNAytHTrC+cJOwnlFaTZuIM+78HJJUcSdxeZhHuHo/i8CrKy0tutf /DFA+Pw7d0dQ+m4mbW+/JdrA76Dd7GSVmUdpxwSqcqoz4oovLYdVHsShJ1PPsPH+5TCK prFMzRsZpFogjp66JG82XJ9ooH5zRlyndeCFgos6MZl5TBXr1mLwsLmc+bpI958DDMk+ /VRlQAePHzL9WzkmJ2w1smYGKUaYGHn8AWcU8UHHBB39V7wLZtkDpoceqt21tNYyEn2u SyUTDOunAoGiy6jzyuTctkvbRQfsd58LPL4Zi4fkxTaPFXsSMWklRJmpsyXIMtyK5yTg oaGA== X-Received: by 10.180.91.16 with SMTP id ca16mr6684414wib.57.1379006361602; Thu, 12 Sep 2013 10:19:21 -0700 (PDT) Received: from [192.168.0.10] (201.66.91.91.rev.sfr.net. [91.91.66.201]) by mx.google.com with ESMTPSA id mz14sm19209044wic.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Sep 2013 10:19:21 -0700 (PDT) Message-ID: <5231F796.5090000@gmail.com> Date: Thu, 12 Sep 2013 19:19:18 +0200 From: David Demelier User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130830 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: 9.2-RC1 panic at shutdown Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Sep 2013 17:19:23 -0000 Hello folks, I have a panic at shutdown related to FUSE. #0 doadump (textdump=) at pcpu.h:234 234 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt full #0 doadump (textdump=) at pcpu.h:234 No locals. #1 0xffffffff8090d9a6 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 _ep = (struct eventhandler_entry *) 0x0 _el = (struct eventhandler_list *) 0xfffffe0004813880 first_buf_printf = 1 #2 0xffffffff8090dea7 in panic (fmt=0x1
) at /usr/src/sys/kern/kern_shutdown.c:637 td = (struct thread *) 0x1 bootopt = newpanic = ap = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0xffffff80e7d402b0, reg_save_area = 0xffffff80e7d401d0}} panic_cpu = 0 buf = "privileged instruction fault", '\0' #3 0xffffffff80cf2c20 in trap_fatal (frame=0x1, eva=) at /usr/src/sys/amd64/amd64/trap.c:879 code = ss = 40 type = 1 esp = softseg = {ssd_base = 0, ssd_limit = 1048575, ssd_type = 27, ssd_dpl = 0, ssd_p = 1, ssd_long = 1, ssd_def32 = 0, ssd_gran = 1} msg = #4 0xffffffff80cf3431 in trap (frame=0xffffff80e7d40510) at /usr/src/sys/amd64/amd64/trap.c:605 td = (struct thread *) 0xfffffe008be0b000 p = (struct proc *) 0xfffffe0034073000 i = ucode = code = 0 type = 1 addr = ksi = {ksi_link = {tqe_next = 0xffffff80e7d408dc, tqe_prev = 0x60}, ksi_info = {si_signo = 96, si_errno = 0, si_code = 0, si_pid = 0, si_uid = 41125008, si_status = -512, si_addr = 0xfffffe00027388f0, si_value = {sival_int = 3, sival_ptr = 0x3, sigval_int = 3, sigval_ptr = 0x3}, _reason = {_fault = {_trapno = 40}, _timer = {_timerid = 40, _overrun = 0}, _mesgq = {_mqd = 40}, _poll = {_band = 40}, __spare__ = {__spare1__ = 40, __spare2__ = {-405535488, -128, -2137810668, -1, 3, 0, 0}}}}, ksi_flags = 2147483647, ksi_sigq = 0xfffffe00000002d1} #5 0xffffffff80cdc863 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 No locals. #6 0xffffffff81afd551 in M_FUSEFH () from /usr/local/modules/fuse.ko No symbol table info available. #7 0xffffff80e7d405d8 in ?? () No symbol table info available. #8 0xffffffff80d97858 in VOP_UNSET_TEXT_APV (vop=0xffffffff81afd3eb, a=0xffffff80e7d40610) at vnode_if.c:4110 _enable_stops = 0 rc = #9 0xffffffff80b9476e in vnode_pager_dealloc (object=0xfffffe004c3060e8) at vnode_if.h:1745 vp = refs = 0 #10 0xffffffff80b86739 in vm_object_terminate (object=0xfffffe004c3060e8) at /usr/src/sys/vm/vm_object.c:766 p = 0xfffffe0035273000 p_next = 0xfffffe0035273000 #11 0xffffffff80b937f9 in vnode_destroy_vobject (vp=0xfffffe0035273000) at /usr/src/sys/vm/vnode_pager.c:168 obj = (struct vm_object *) 0xfffffe004c3060e8 #12 0xffffffff81af78a1 in fuse_reclaim () from /usr/local/modules/fuse.ko No symbol table info available. #13 0xffffffff80d99998 in VOP_RECLAIM_APV (vop=0xfffffe008be0b000, a=0xfffffe0035273000) at vnode_if.c:1988 _enable_stops = 0 rc = #14 0xffffffff809aacd4 in vgonel (vp=0xfffffe0035273000) at vnode_if.h:830 td = (struct thread *) 0xfffffe008be0b000 active = 1 mp = (struct mount *) 0x0 #15 0xffffffff809ae1de in vflush (mp=0xfffffe00048ae338, rootrefs=1, flags=2, td=0xfffffe008be0b000) at /usr/src/sys/kern/vfs_subr.c:2687 _rc = vp = (struct vnode *) 0xfffffe0035273000 mvp = (struct vnode *) 0xfffffe008bc36800 rootvp = (struct vnode *) 0xfffffe0035273000 vattr = {va_type = 2175779674, va_mode = 65535, va_nlink = -1, va_uid = 689, va_gid = 0, va_fsid = 3889432544, va_fileid = -2133215974, va_size = 4, va_blocksize = 525312, va_atime = {tv_sec = -2198131494912, tv_nsec = 689}, va_mtime = {tv_sec = -545866381232, tv_nsec = -2137280809}, va_ctime = {tv_sec = -2127027808, tv_nsec = -2198131494912}, va_birthtime = {tv_sec = -2199022730240, tv_nsec = -2119187622}, va_gen = 18446743523953738417, va_flags = 0, va_rdev = 3889432736, va_bytes = 18446741875578056904, va_filerev = 0, va_vaflags = 2175779700, va_spare = 219043332096} busy = 0 error = 0 #16 0xffffffff81af623b in fuse_unmount () from /usr/local/modules/fuse.ko No symbol table info available. #17 0xfffffe00048ae338 in ?? () No symbol table info available. #18 0xfffffe008bdb7d50 in ?? () No symbol table info available. #19 0xfffffe008be0b000 in ?? () No symbol table info available. #20 0x0000000000000000 in ?? () No symbol table info available. I've read somewhere "FreeBSD is stable, more than linux", I agree but during this year I've got something like 10-15 panics on my laptop. On Linux never since 2004. Just my 2 cens. I'm not sure if the panic is reproductible, I will tell you tomorrow. Warm regards, From owner-freebsd-stable@FreeBSD.ORG Thu Sep 12 17:27:11 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 273633CC for ; Thu, 12 Sep 2013 17:27:11 +0000 (UTC) (envelope-from florent@peterschmitt.fr) Received: from peterschmitt.fr (peterschmitt.fr [5.135.177.31]) by mx1.freebsd.org (Postfix) with ESMTP id E297D226C for ; Thu, 12 Sep 2013 17:27:10 +0000 (UTC) Received: from [192.168.0.128] (4ab54-4-88-163-248-31.fbx.proxad.net [88.163.248.31]) by peterschmitt.fr (Postfix) with ESMTPSA id CCCFF62A8 for ; Thu, 12 Sep 2013 19:21:14 +0200 (CEST) Message-ID: <5231F809.9080200@peterschmitt.fr> Date: Thu, 12 Sep 2013 19:21:13 +0200 From: Florent Peterschmitt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 9.2-RC1 panic at shutdown References: <5231F796.5090000@gmail.com> In-Reply-To: <5231F796.5090000@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dX32jp0sd4m25sM7tGNwGlj7mdH95mSaL" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Sep 2013 17:27:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dX32jp0sd4m25sM7tGNwGlj7mdH95mSaL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le 12/09/2013 19:19, David Demelier a =E9crit : > Hello folks, >=20 > I have a panic at shutdown related to FUSE. > #16 0xffffffff81af623b in fuse_unmount () from /usr/local/modules/fuse.= ko Yes, then, did you rebuilt the kernel module after an upgrade? --=20 Florent Peterschmitt | Please: florent@peterschmitt.fr | * Avoid HTML/RTF in E-mail. +33 (0)6 64 33 97 92 | * Send PDF for documents. http://florent.peterschmitt.fr | * Trim your quotations. Really. Proudly powered by Open Source | Thank you :) --dX32jp0sd4m25sM7tGNwGlj7mdH95mSaL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSMfgKAAoJEFr01BkajbiBL+0P+wXYef1icJtXElJjy5fmvA9R pgt9F3QAIlnaO9RiztxTTt9TaJg8Bp+znchCAKiv2ofY0g8TUV9G2HMn8d6Uqdqx 2JkARP/lxtFgoZpdsFZev5e7GviHCMZSEAPz41VET1qIq+dIW2R/nh9VvH5+6RuR Xd2/epfmjoNC/5Z1CdCCUH+9BUTx8cgiXiZ4qUCGW/YVKbtLxm8UTi1T9CezNu8b /YnMVTSw3d6/sT4nZsn/0r2GZVsxfVmO7HQ3TVIW1W3mgUBWQxq6bUIJn2I4foVV 44uN97whklc8iuFOcxAcP9eMR2Z3OGUlAQG72sKgYoihMRQ84icU6koTQUWkak8p RWroYyOH96JASuPKNsqI6TjOFMtFfh5+54Sh8cBieikGwF2BNoaEKXCuvDUkXBaJ XpylqbLna0/mIviJi65rJ1arP2g63o1CB8Ktw4UNsAemVUdB2Cl4cvswcy6n/nPd gaxo/xir0jtfYmH2lewLez+gN7/kOMRU11pLhGgEzstHhaq8KwGb8rsQDl10yup6 iyogaQlig9UWMztWypOD++RqzlYouZhave8z26npyurpB65A0W94FbOQFeiqo+rV meYCs8Z923+CTvzOq4J7XsdZR4o1TBUYYyKQ44qJwbCiqzEUeoE0k1vYYYJv1yZa 25cP6qJ/7PNxi9ZNEv8Y =1ReO -----END PGP SIGNATURE----- --dX32jp0sd4m25sM7tGNwGlj7mdH95mSaL-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 12 17:38:44 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D0EC88EA; Thu, 12 Sep 2013 17:38:44 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A29002354; Thu, 12 Sep 2013 17:38:44 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 5094BAF72; Thu, 12 Sep 2013 17:38:43 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 5094BAF72 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Thu, 12 Sep 2013 13:38:41 -0400 From: Glen Barber To: freebsd-stable@FreeBSD.org Subject: 9.2-RC4 Now Available Message-ID: <20130912173841.GC2404@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pAwQNkOnpTn9IO2O" Content-Disposition: inline X-Operating-System: FreeBSD 10.0-ALPHA1 amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Release Engineering Team X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Sep 2013 17:38:44 -0000 --pAwQNkOnpTn9IO2O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The fourth release candidate builds of the 9.2-RELEASE release cycle are now available on the FTP servers for the amd64, i386, ia64, powerpc, powerpc64, and sparc64 architectures. This is expected to be the final release candidate for the 9.2-RELEASE cycle. The image checksums follow at the end of this email. ISO images and, for architectures that support it, the memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.2/ (or any of the FreeBSD mirror sites). If you notice problems you can report them through the normal GNATS PR system or here on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system use "releng/9.2". Please be aware that cvsup and CVS are both deprecated, and are not supported methods of updating the src/ tree. Changes between -RC3 and -RC4 include: o Revert the tribute boot loader logo as the default logo. o Fix a filesystem bug that would cause removed files to fail to dereference vnodes until the filesystem was forcibly unmounted and remounted. o Fix a rtadvd(8) segmentation fault on service reload. o Create and correct ownership and permissions of /var/authpf in the standard mtree. o Fix a NFS deadlock. o Stop SIOCSIFADDR, SIOCSIFBRDADDR, SIOCSIFDSTADDR and SIOCSIFNETMASK at the socket layer rather than pass them on to the link layer without validation or credential checks. [SA-13:12] o Prevent cross-mount hardlinks between different nullfs mounts of the same underlying filesystem. [SA-13:13] o Fix the length calculation for the final block of a sendfile(2) transmission which could be tricked into rounding up to the nearest page size, leaking up to a page of kernel memory. [SA-13:11] The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 9.2-RC4 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 8.x. Alternatively, the user can install misc/compat8x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install Checksums: amd64: SHA256 (FreeBSD-9.2-RC4-amd64-bootonly.iso) = 472ad60bbb8f48da4f1799204ccf5900888b03dd6ab392123f14daf927895941 SHA256 (FreeBSD-9.2-RC4-amd64-disc1.iso) = 9379c1466b4b4d5c0a31a71f051dec7dae50e9d18379b58e5efd3ec59f8a6b40 SHA256 (FreeBSD-9.2-RC4-amd64-dvd1.iso) = d38f70b44626910b1361c4beaff0da7eda76f9168b67d6601fd4674236a51f26 SHA256 (FreeBSD-9.2-RC4-amd64-memstick.img) = d93e243f1eb47718611afeba89538f44db5a0425849baec9e9bfd5f6a7fe56f6 MD5 (FreeBSD-9.2-RC4-amd64-bootonly.iso) = 2e519a524502a971f3667fbe52552426 MD5 (FreeBSD-9.2-RC4-amd64-disc1.iso) = 70d793d41ee1d0b9c26997a1c907c796 MD5 (FreeBSD-9.2-RC4-amd64-dvd1.iso) = 476f952715f5003704fe1a1c0ab7ccad MD5 (FreeBSD-9.2-RC4-amd64-memstick.img) = 13351aa0bb24af94bfe53783aa3c969f i386: SHA256 (FreeBSD-9.2-RC4-i386-bootonly.iso) = 50156c4638b06c75c05a6552b5ce00c2468ea8727afe38bf75587bf446b75e5a SHA256 (FreeBSD-9.2-RC4-i386-disc1.iso) = b24ee49bc8e6dc1066601ec786f58e564cc2f6644e3deca0c8d66a309b499d1a SHA256 (FreeBSD-9.2-RC4-i386-dvd1.iso) = e7250ee4398c29fe7b14ba221220e7539d7571b77731972995dab2be5b5d718f SHA256 (FreeBSD-9.2-RC4-i386-memstick.img) = b3e8e15f0667197ef49093147e16b6f0d69fd627028534952234cacb148886ba MD5 (FreeBSD-9.2-RC4-i386-bootonly.iso) = 97b6a0bc8ee1f4bb7383b0d0c8ea097c MD5 (FreeBSD-9.2-RC4-i386-disc1.iso) = eb515715da6fd13d951fdb02f097d778 MD5 (FreeBSD-9.2-RC4-i386-dvd1.iso) = 6860a9c9d5b7533a74883a8acbdc1048 MD5 (FreeBSD-9.2-RC4-i386-memstick.img) = ce10919cbec90699bd74ed6ac56696cd ia64: SHA256 (FreeBSD-9.2-RC4-ia64-bootonly.iso) = 61f68b822005262a36fba3e8d856727791619abbf4ee3dcb1f5cfe864ebc4a50 SHA256 (FreeBSD-9.2-RC4-ia64-disc1.iso) = 8e6a94cafaf6499dc07210dfd0ea0590d7e8ecaab1a8de28999354a0b66ccae5 SHA256 (FreeBSD-9.2-RC4-ia64-memstick.img) = 4a38e15b09f96d2bdeb6b95599f89eab4a6288b7badfce7d5fbe06b062e3f651 MD5 (FreeBSD-9.2-RC4-ia64-bootonly.iso) = 1ec1a2e28dcada9194c65bbfbf565282 MD5 (FreeBSD-9.2-RC4-ia64-disc1.iso) = dfef10be2f74fca908c984760438db48 MD5 (FreeBSD-9.2-RC4-ia64-memstick.img) = 60deb6fe578babf50c826db954f5ebbe powerpc: SHA256 (FreeBSD-9.2-RC4-powerpc-bootonly.iso) = 0edf42f96c73ba53bfb2a2559e681364c3a82237dfd480eacdebf262db5347e1 SHA256 (FreeBSD-9.2-RC4-powerpc-disc1.iso) = 3485f40f2bf3a62337e4011970c281a5c5eb24d59d87dd111c05884339125fee SHA256 (FreeBSD-9.2-RC4-powerpc-memstick.img) = bf1b90099b7a7ec10118e441826c5618c0452af5067ead8ec5e1aaccb5872743 MD5 (FreeBSD-9.2-RC4-powerpc-bootonly.iso) = 97c9d73efcb07ce5031c14be85725157 MD5 (FreeBSD-9.2-RC4-powerpc-disc1.iso) = b22e1ec036bab2f1654347ba62deae31 MD5 (FreeBSD-9.2-RC4-powerpc-memstick.img) = 012b36327e77e73e89093967cdd7156a powerpc64: SHA256 (FreeBSD-9.2-RC4-powerpc-powerpc64-bootonly.iso) = 266c4a2081cb4bd5c0f2a06507271784d7da19ae16e5c828374fc4909f807f4f SHA256 (FreeBSD-9.2-RC4-powerpc-powerpc64-disc1.iso) = 43a812cebe0d56aabe31d3621f65bf00bf1f0f9aa654177d3652a4d45eab9cba SHA256 (FreeBSD-9.2-RC4-powerpc-powerpc64-memstick.img) = dc9b83343eac001d1191b0d2e90195e2b95b1dd5d047bdb7a5e959470ed1c698 MD5 (FreeBSD-9.2-RC4-powerpc-powerpc64-bootonly.iso) = 17744bc71f240450e8b3a930b2913cc3 MD5 (FreeBSD-9.2-RC4-powerpc-powerpc64-disc1.iso) = b092e191bb325dbd488eaf703b96c883 MD5 (FreeBSD-9.2-RC4-powerpc-powerpc64-memstick.img) = 076e875720760db3db23b29fe3d05e2f sparc64: SHA256 (FreeBSD-9.2-RC4-sparc64-bootonly.iso) = 19bf12eabf90d5f9e67b39aa7dc053a6295765d5db2742338a737d207059783e SHA256 (FreeBSD-9.2-RC4-sparc64-disc1.iso) = 953d0bcb7525c83fca1c7181d9519c12cb56a16837dd7285b3ea39bcce5f4275 MD5 (FreeBSD-9.2-RC4-sparc64-bootonly.iso) = a3cef609a6495644ed685549efd8faae MD5 (FreeBSD-9.2-RC4-sparc64-disc1.iso) = 0df9e41f26ddcfb74f3e2cf273e6489f Glen --pAwQNkOnpTn9IO2O Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBCAAGBQJSMfwhAAoJEFJPDDeguUajy4gH/1jQxJGmvXFnAcqjMcfirbOD iGB0gyR2hjsCMQKDEVGb1T8cMXmESXSrDLTTDZflkykt2e9wSvTffH3rxEn7wqxX IIsxIDPqTE5H2382xxwfF2Js8o6PbklUkH23U8UHXih7UoGVjmkxEMD1xlDniZi7 3AOMnrxP386YVe0T5GxJFrOsr51zHHD6a69cID1Vdx8A+6BG0xIWI1hRNUzmYWjC oaQoibpy+4Up9oPtJdmfX203LN1sRkwG0Mm/2g/ShRUQONwZRmDKbCATcgYiJOS4 xxaGIGb4NBOEDppFO/GTB8mePN3DixkEswyPFj0iZJYuNX0Vqd+vV9gOXoeC+mY= =tx1N -----END PGP SIGNATURE----- --pAwQNkOnpTn9IO2O-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 12 18:07:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1DCA1839 for ; Thu, 12 Sep 2013 18:07:39 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AB552257A for ; Thu, 12 Sep 2013 18:07:38 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id m15so854864wgh.3 for ; Thu, 12 Sep 2013 11:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gc8NOtmWp4idWZi9HfF6ELLIO9PotsO1siZCZWbeS2E=; b=JK3drCd+4JO70Q7OZaahifQFQscOdi6viPb6TRmn3oLvJWsAqtU53MGkkctKRmu0Al GeBJTCghx9iGeAS5P+I3l8q2BwshcM3vgtK8B0h8vIjQqudLOgQPtWcXZi8fE/rKCCpQ 60nTzhb5cMrgAM8CSpEHk0/EAUAfOf7MP17xQMfdihxABE2hoGj6rI4GuBLZsmsFs+ad uOMOlH8l9UhNKHwk37PnKemu/IP6b2YQVjRj7KHt05F5In5G0rMwiFJyT5i5jvCZfm5A KdhvjplHJEWNF1bRucqjE8RIPBHxZLz8qrdxumVvOjwQBzbGLlfA1jaP/8AsOOy+f5Tv B1AA== X-Received: by 10.180.86.103 with SMTP id o7mr6995751wiz.16.1379009256965; Thu, 12 Sep 2013 11:07:36 -0700 (PDT) Received: from [192.168.0.10] (201.66.91.91.rev.sfr.net. [91.91.66.201]) by mx.google.com with ESMTPSA id b11sm19484513wik.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Sep 2013 11:07:36 -0700 (PDT) Message-ID: <523202E6.7030307@gmail.com> Date: Thu, 12 Sep 2013 20:07:34 +0200 From: David Demelier User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130830 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 9.2-RC1 panic at shutdown References: <5231F796.5090000@gmail.com> <5231F809.9080200@peterschmitt.fr> In-Reply-To: <5231F809.9080200@peterschmitt.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Sep 2013 18:07:39 -0000 On 12.09.2013 19:21, Florent Peterschmitt wrote: > Le 12/09/2013 19:19, David Demelier a écrit : >> Hello folks, >> >> I have a panic at shutdown related to FUSE. >> #16 0xffffffff81af623b in fuse_unmount () from /usr/local/modules/fuse.ko > > Yes, then, did you rebuilt the kernel module after an upgrade? > > Yes it should, I have PORTS_MODULES set in my make.conf which should, but I will try to be sure! From owner-freebsd-stable@FreeBSD.ORG Thu Sep 12 18:28:56 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9A800318 for ; Thu, 12 Sep 2013 18:28:56 +0000 (UTC) (envelope-from olgeni@olgeni.com) Received: from olgeni.olgeni.com (host-156-246-171-31.cloudsigma.com [31.171.246.156]) by mx1.freebsd.org (Postfix) with ESMTP id 5EE9727E0 for ; Thu, 12 Sep 2013 18:28:55 +0000 (UTC) Received: from olgeni.olgeni (unknown [82.84.82.178]) by olgeni.olgeni.com (Postfix) with ESMTPSA id 0B1F9174488; Thu, 12 Sep 2013 20:28:48 +0200 (CEST) Date: Thu, 12 Sep 2013 20:28:48 +0200 (CEST) From: Jimmy Olgeni X-X-Sender: olgeni@olgeni.olgeni To: Konstantin Belousov Subject: Re: Possible kqueue related issue on STABLE/RC. In-Reply-To: <20130912073643.GM41229@kib.kiev.ua> Message-ID: References: <20130911171913.GG41229@kib.kiev.ua> <20130912073643.GM41229@kib.kiev.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Sep 2013 18:28:56 -0000 On Thu, 12 Sep 2013, Konstantin Belousov wrote: > Might be, your issue is that some filesystems do not care about proper > locking mode for the fifos. UFS carefully disables shared locking for > VFIFO, but it seems ZFS is not. I can propose the following band-aid, > which could help you. This certainly seems to improve things. I have been running builds for the past couple of hours without any critical problem. I spotted a few LORs but nothing bad happened so far: http://olgeni.olgeni.com/~olgeni/dmesg-2013-09-12 If it keeps working this way I hope there's still some time to fit it into an -RC. -- jimmy From owner-freebsd-stable@FreeBSD.ORG Thu Sep 12 18:49:05 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C57ADEB0 for ; Thu, 12 Sep 2013 18:49:05 +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-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 360E82A84 for ; Thu, 12 Sep 2013 18:49:05 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r8CIn0ea090417; Thu, 12 Sep 2013 21:49:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r8CIn0ea090417 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r8CIn05r090416; Thu, 12 Sep 2013 21:49:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 12 Sep 2013 21:49:00 +0300 From: Konstantin Belousov To: Jimmy Olgeni Subject: Re: Possible kqueue related issue on STABLE/RC. Message-ID: <20130912184900.GD41229@kib.kiev.ua> References: <20130911171913.GG41229@kib.kiev.ua> <20130912073643.GM41229@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="plHD7dANMMm1ZgTj" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Sep 2013 18:49:05 -0000 --plHD7dANMMm1ZgTj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 12, 2013 at 08:28:48PM +0200, Jimmy Olgeni wrote: >=20 > On Thu, 12 Sep 2013, Konstantin Belousov wrote: >=20 > > Might be, your issue is that some filesystems do not care about proper > > locking mode for the fifos. UFS carefully disables shared locking for > > VFIFO, but it seems ZFS is not. I can propose the following band-aid, > > which could help you. >=20 > This certainly seems to improve things. I have been running builds > for the past couple of hours without any critical problem. Ok, so it is ZFS indeed. I think I will commit the band-aid to head shortly. >=20 > I spotted a few LORs but nothing bad happened so far: >=20 > http://olgeni.olgeni.com/~olgeni/dmesg-2013-09-12 Out of curiousity, please look up the line for vm_object_terminate+0x1d8. >=20 > If it keeps working this way I hope there's still some time to fit it=20 > into an -RC. For 10.0 yes, 9.2 is sealed (hopefully). --plHD7dANMMm1ZgTj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSMgybAAoJEJDCuSvBvK1BMbcP/0pEDgA7t8BHsR+ozvfBZMUA zo9egoWPdug/LPndkppPZDIGjr2O1XSelY647sfD9YGAFP2cMZel2GLj+zFlUr1h UB2IZ5gDi7GzVRflFDb3fzb+BIrMttvS/Dl2GvG6/Y11h/LG8KIU6QemVkiAJJFe PEo18k7ODOt1z+ZXYWG0B2cCNLSPqRTIZEmxf6wd5mDE8aWh3yL166atRrvbryh2 zr00gmuEgGvPJsmVyIBkTOEyOjZm9FgZVBA8gG+JLTLzkETZTCEnNKqHM4SwBSbj 84YVPfHv6xq8OPmhfZuDjBHe36fWX/N7Nv2By7N16Opdb0O8ZCDMfxQcL24o7/xH UJDZI21/ocAhQuZevBZEC1tI6k8uzfYeu4TWbK+BqmI3arzXT38Aw9GdOoNk8Rhn AGQeoT+9Jc+mLiKH2rrtoDF/IL2KsqcyVB80pWomXcFy+6LGHAg0GoXoHQ49smrn vCsfszPaLFAerjGgLKNlA9IC2zUVpZFXif314G631UoWJCnPkZLg9fMG4zCUbzI9 rKXBuYM8blvwLGHWr5nmVlAY5XW6x3uczYD3CycLBpAw5/UrGKlJ3dCVyoi5KvLN 1tsq/TYGt8vX1Mdu8Ww0cHH/2ddtF40PljUSy7SKO8Zl6hdTth7BYx+DePk0hRiS xadXpCWfSepqlq6rHjXG =sX/B -----END PGP SIGNATURE----- --plHD7dANMMm1ZgTj-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 12 20:10:27 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0FFC2814 for ; Thu, 12 Sep 2013 20:10:27 +0000 (UTC) (envelope-from olgeni@olgeni.com) Received: from olgeni.olgeni.com (host-156-246-171-31.cloudsigma.com [31.171.246.156]) by mx1.freebsd.org (Postfix) with ESMTP id C95E723F0 for ; Thu, 12 Sep 2013 20:10:25 +0000 (UTC) Received: from olgeni.olgeni (unknown [82.84.82.178]) by olgeni.olgeni.com (Postfix) with ESMTPSA id 6AFB717449C; Thu, 12 Sep 2013 22:10:24 +0200 (CEST) Date: Thu, 12 Sep 2013 22:10:23 +0200 (CEST) From: Jimmy Olgeni X-X-Sender: olgeni@olgeni.olgeni To: Konstantin Belousov Subject: Re: Possible kqueue related issue on STABLE/RC. In-Reply-To: <20130912184900.GD41229@kib.kiev.ua> Message-ID: References: <20130911171913.GG41229@kib.kiev.ua> <20130912073643.GM41229@kib.kiev.ua> <20130912184900.GD41229@kib.kiev.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Sep 2013 20:10:27 -0000 On Thu, 12 Sep 2013, Konstantin Belousov wrote: >> This certainly seems to improve things. I have been running builds >> for the past couple of hours without any critical problem. > Ok, so it is ZFS indeed. I think I will commit the band-aid to head > shortly. Thank you! >> I spotted a few LORs but nothing bad happened so far: >> >> http://olgeni.olgeni.com/~olgeni/dmesg-2013-09-12 > Out of curiousity, please look up the line for vm_object_terminate+0x1d8. Here it is, VM_OBJECT_UNLOCK: (kgdb) list *vm_object_terminate+0x1d8 0xffffffff80b5cc58 is in vm_object_terminate (/usr/src/sys/vm/vm_object.c:767). 762 763 /* 764 * Let the pager know object is dead. 765 */ 766 vm_pager_deallocate(object); 767 VM_OBJECT_UNLOCK(object); 768 769 vm_object_destroy(object); 770 } 771 -- jimmy From owner-freebsd-stable@FreeBSD.ORG Thu Sep 12 21:41:29 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 865825A2 for ; Thu, 12 Sep 2013 21:41:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D1DFD29AB for ; Thu, 12 Sep 2013 21:41:28 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA05330; Fri, 13 Sep 2013 00:41:24 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VKEdg-000KrT-Fm; Fri, 13 Sep 2013 00:41:24 +0300 Message-ID: <523234CC.7030004@FreeBSD.org> Date: Fri, 13 Sep 2013 00:40:28 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Possible kqueue related issue on STABLE/RC. References: <20130911171913.GG41229@kib.kiev.ua> <20130912073643.GM41229@kib.kiev.ua> <20130912184900.GD41229@kib.kiev.ua> In-Reply-To: <20130912184900.GD41229@kib.kiev.ua> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, Jimmy Olgeni X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Sep 2013 21:41:29 -0000 on 12/09/2013 21:49 Konstantin Belousov said the following: > On Thu, Sep 12, 2013 at 08:28:48PM +0200, Jimmy Olgeni wrote: >> >> On Thu, 12 Sep 2013, Konstantin Belousov wrote: >> >>> Might be, your issue is that some filesystems do not care about proper >>> locking mode for the fifos. UFS carefully disables shared locking for >>> VFIFO, but it seems ZFS is not. I can propose the following band-aid, >>> which could help you. >> >> This certainly seems to improve things. I have been running builds >> for the past couple of hours without any critical problem. > Ok, so it is ZFS indeed. I think I will commit the band-aid to head > shortly. I am not sure if my message <5231A016.7060906@FreeBSD.org> was intercepted by NSA and didn't reach you... At least I haven't seen any reaction to it. So, ZFS does not need this band-aid. If you think that it may be needed for other filesystems or is useful in general, then okay. Just in case, r254694 is not in releng/9.2 and I haven't seen any evidence that Jimmy has tested a tree that included that commit. >> I spotted a few LORs but nothing bad happened so far: >> >> http://olgeni.olgeni.com/~olgeni/dmesg-2013-09-12 > Out of curiousity, please look up the line for vm_object_terminate+0x1d8. > >> >> If it keeps working this way I hope there's still some time to fit it >> into an -RC. > > For 10.0 yes, 9.2 is sealed (hopefully). > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Sep 13 05:34:27 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1423CDD2; Fri, 13 Sep 2013 05:34:27 +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-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7ABDA27A0; Fri, 13 Sep 2013 05:34:26 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r8D5YH7Q030790; Fri, 13 Sep 2013 08:34:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r8D5YH7Q030790 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r8D5YHZi030789; Fri, 13 Sep 2013 08:34:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 13 Sep 2013 08:34:17 +0300 From: Konstantin Belousov To: Andriy Gapon Subject: Re: Possible kqueue related issue on STABLE/RC. Message-ID: <20130913053417.GI41229@kib.kiev.ua> References: <20130911171913.GG41229@kib.kiev.ua> <20130912073643.GM41229@kib.kiev.ua> <20130912184900.GD41229@kib.kiev.ua> <523234CC.7030004@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Z58pRedRDwOEwTeD" Content-Disposition: inline In-Reply-To: <523234CC.7030004@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-stable@FreeBSD.org, Jimmy Olgeni X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Sep 2013 05:34:27 -0000 --Z58pRedRDwOEwTeD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 13, 2013 at 12:40:28AM +0300, Andriy Gapon wrote: > on 12/09/2013 21:49 Konstantin Belousov said the following: > > Ok, so it is ZFS indeed. I think I will commit the band-aid to head > > shortly. >=20 > I am not sure if my message <5231A016.7060906@FreeBSD.org> was intercepte= d by > NSA and didn't reach you... At least I haven't seen any reaction to it. > So, ZFS does not need this band-aid. If you think that it may be needed = for > other filesystems or is useful in general, then okay. >=20 > Just in case, r254694 is not in releng/9.2 and I haven't seen any evidenc= e that > Jimmy has tested a tree that included that commit. Good to know, thank you. My change does not conflict with ZFS fix, and more, the cost of the change for well-behaved filesystem is zero, since upgrade is only initiated when needed. I think both fixes can coexist usefully. --Z58pRedRDwOEwTeD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSMqPYAAoJEJDCuSvBvK1BClQP/1fI+3oZ/uPgtLMOp6tr89yf jdGw29erN4xAyy+CTmn80mZTma6+lWWn2SpYi470cDY1f1wSACQ10FhSfUjHR0Ek w37JhuFJNZ7/Scm1lHQ4x/2J8whLgAD42INC5rEZJdKqmbRP9DJxCTS6QXd8qVlt wERmy1gj0GQ0KobARNmj1/g8dBFBdDfW6b0qNNYMcPUWB8wjdOszQL2fCg4cfdFv 3ZHAfO5CHpA7r2LgejeBUJFCuF3U59+YreOhWr7rpryypsoXGLGauAyQffBcnte5 1Ww2Dkd8S4AgDTKiAXXNTgL/K8Ihai5iX48YKZvHUP/kjq7iKm9o/durV0wtNp3w 0mYw6tkSXpG5bilY7YNAI2/UUSgegXCYOeV4jcsud3QUCiVHBIhhegrHepSD/hz1 AHAZ7HnRerXNkOx7bV4WoEYshGaEkbzym9L9dwZ22S7iOfS+bBGO/9Vn1qe/wyAg OMIT1JoY4acyXcRXrNXoIeby63yNGpuqU7MewswDhjxDhVPIP0knRYFBv4z9hSxL p0BDQ87VpvydQgdJ1cC54xS//AzlT0u+g8FLGz9m5jK/TfkEAql146OeafzgkdZr RGF9bVDpOqR3ezzlSSwIdBgHbFENsG+HCUbu38SKcW5UpX+ibFe3CI7HAB/WysWZ nFc6gqaOL6Df6Q3fd+Hg =tnXX -----END PGP SIGNATURE----- --Z58pRedRDwOEwTeD-- From owner-freebsd-stable@FreeBSD.ORG Fri Sep 13 05:43:15 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 779DEFEB for ; Fri, 13 Sep 2013 05:43:15 +0000 (UTC) (envelope-from frank_s@bellsouth.net) Received: from fmailhost05.isp.att.net (fmailhost05.isp.att.net [207.115.11.55]) by mx1.freebsd.org (Postfix) with ESMTP id 649632801 for ; Fri, 13 Sep 2013 05:43:14 +0000 (UTC) Received: from ace.nina.org (adsl-74-178-52-115.gnv.bellsouth.net[74.178.52.115]) by isp.att.net (frfwmhc05) with SMTP id <20130913053306H05008q5a8e>; Fri, 13 Sep 2013 05:33:06 +0000 X-Originating-IP: [74.178.52.115] Date: Fri, 13 Sep 2013 01:33:05 -0400 (EDT) From: Frank Seltzer X-X-Sender: frank_s@Ace.nina.org To: freebsd-stable@freebsd.org Subject: expr error in 9-STABLE Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Sep 2013 05:43:15 -0000 Posting because I haven't seen this yet. I have been getting this error on 2 boxes for the last 2 days. Both boxes: root@Shop:/usr/src # svn info /usr/src/ Path: . Working Copy Root Path: /usr/src URL: svn://kryten.nina.org/src/stable/9 Relative URL: ^/stable/9 Repository Root: svn://kryten.nina.org/src Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 255501 Node Kind: directory Schedule: normal Last Changed Author: mckusick Last Changed Rev: 255494 Last Changed Date: 2013-09-12 15:36:04 -0400 (Thu, 12 Sep 2013) ===> bin/expr (all) cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c expr.c cc1: warnings being treated as errors expr.c:812: warning: redundant redeclaration of 'yyparse' /usr/src/bin/expr/expr.y:77: warning: previous declaration of 'yyparse' was here *** [expr.o] Error code 1 Stop in /usr/src/bin/expr. *** [all] Error code 1 Stop in /usr/src/bin. *** [bin.all__D] Error code 1 Stop in /usr/src. *** [everything] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. Thanks, Frank From owner-freebsd-stable@FreeBSD.ORG Fri Sep 13 06:58:42 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C6B98FB8; Fri, 13 Sep 2013 06:58:42 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3EF2F2B7D; Fri, 13 Sep 2013 06:58:42 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id n12so733712wgh.27 for ; Thu, 12 Sep 2013 23:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/VS0/L1EmDXFK/l8b8S8kzfJ/CGVktSRZskmYT1Sxz4=; b=Y7q5E+mTHxnZPbmzXqx+HtqBjR+h/itHQ0wGsggFxWd/aAUCF4VD0WUVEOxathTtaN B2gvFGf6RzW57N2I1ERbZnbeY7/A2y0f+lHAqXySFFKzE6vi5WsjKDNTcE3m204YSJyA L/ZJpI3B73fGu6kau7dUwEnOqI6wmQW7ycACnwHXD0nyCj13C3Xvlmg4fpxt3bCosioZ ErN3jsTX3EhnbyowbD8lVpS6UYLbSaMZtgaJ/Ex/hddjGmVQyzPfhzutxP+xvV2igNdQ jFSojmsjkA4LNE+t/O02WdTqfr271CgCfvPEbuYJWCMSVckb/0ib6aiYsawNsk7/DAse lZQA== MIME-Version: 1.0 X-Received: by 10.180.85.65 with SMTP id f1mr1212271wiz.33.1379055520489; Thu, 12 Sep 2013 23:58:40 -0700 (PDT) Received: by 10.194.157.69 with HTTP; Thu, 12 Sep 2013 23:58:40 -0700 (PDT) In-Reply-To: <20130910093009.GA25595@lyxys.ka.sub.org> References: <20130828131017.GA89499@lyxys.ka.sub.org> <20130910093009.GA25595@lyxys.ka.sub.org> Date: Fri, 13 Sep 2013 08:58:40 +0200 Message-ID: Subject: Re: State of Unicode collation support in FreeBSD? From: David Demelier To: Wolfgang Zenker Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org, freebsd-i18n@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Sep 2013 06:58:42 -0000 2013/9/10 Wolfgang Zenker : > * David Demelier [130910 10:26]: >> 2013/8/28 Wolfgang Zenker : >>> [crossposted to -stable and -i18n] >>> could someone point me to infos regarding Unicode collation support in FreeBSD? >>> All I could find was https://wiki.freebsd.org/KonradJankowski/Collation but >>> that page has not been changed in more than two years. Looking at sources of >>> -current it doesn't look like those changes made it into the source tree yet. > >> I think no one is really interested to add real UTF-8 support to >> Syscons. Currently you can get UTF-8 output by using Syscons xterm >> ttys (which is default) and set your appropriate locales. For input >> it's currently (unfortunately) not supported. > >> If you use X.Org, then your fine using UTF-8. > > There might be a misunderstanding: Collation is about ordering characters and > sorting strings. What we have in FreeBSD right now is support for input and > output of utf-8 characters, and with X11 and the right set of fonts they > display ok, and at least using vim editing utf-8 text works ok. But sorting > utf-8 strings yields "interesting" results as soon as you have non-ascii > characters in your strings. > Aaah, okay sorry I really did misunderstanding the question yes ;-). Regards, -- Demelier David From owner-freebsd-stable@FreeBSD.ORG Fri Sep 13 13:20:37 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D4DCFEE5; Fri, 13 Sep 2013 13:20:37 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D660A21F5; Fri, 13 Sep 2013 13:20:36 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA16552; Fri, 13 Sep 2013 16:20:27 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VKTIR-000OyW-Ga; Fri, 13 Sep 2013 16:20:27 +0300 Message-ID: <523310E2.4050702@FreeBSD.org> Date: Fri, 13 Sep 2013 16:19:30 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: J David Subject: Re: zfs_enable vs zfs_load in loader.conf (but neither works) References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "freebsd-fs@freebsd.org" , freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Sep 2013 13:20:38 -0000 First, a note that below I try to reply not only to this specific message but to the whole thread. on 09/09/2013 04:02 J David said the following: > After setting up a new machine to boot from a ZFS root using the 9.1 > install, it worked fine, but when the kernel & world was updated to > releng/9.2, it stopped booting. The pool is called "data" and the > root partition is "data/root." > > Under 9.1 it had in loader.conf: > > zfs_load="YES" > vfs.root.mountfrom="zfs:data/root" > > Under 9.2-RC3, the same config results in a panic: > > Trying to mount root from zfs:data/root []… > init: not found in path > /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/sysinstall > panic: no init This is a very weird error. It means that kernel was able to mount data/root as a root filesystem, but couldn't find /sbin/init in it. Which can mean at least two different things: (1) some other filesystem was mounted instead of data/root because of some bug; (2) your data/root didn't actually contain valid FreeBSD installation. I set up a test system exactly the way you described above and I can not reproduce this behavior. Just in case, I used mfsbsd zfsinstall and that's how it creates and configures a pool by default. > If this is changed (as many Google hits recommend) to: > > zfs_enable="YES" I think that this was discussed enough in the thread and the right conclusions have been already reached. I just have two general comments: - you don't have to trust everything that is written "on the internet". Prefer to use more or less authoritative sources: FreeBSD documentation, FreeBSD wiki, posts by FreeBSD developers and alike - it surprises me how many people who don't understand how the code works feel that they can give advices to other people - when *I* used the following query https://www.google.com/search?q=%22zfs_enable%22+%22loader.conf%22 I could not find a single suggestion to put zfs_enable into loader.conf in the first dozen of results (references to this thread excluded) > vfs.root.mountfrom="zfs:data/root" > > It seems like ZFS doesn't get loaded, so it fails instead with: > > Trying to mount root from zfs:data/root []… > Mounting from zfs:data/root failed with error 2: unknown file system. > > If the "?" mountroot> option is used, 50 devices are listed, none of > which are ZFS. And the "unknown file system" response comes from > vfs_byname returning NULL for zfs. Obvious (as already established). > (If both zfs_enable and zfs_load are set to "YES" then it fails as the > zfs_load case.) Obvious (as already established). > The system is using update-to-date zpool (v5000 / feature flags), and > all the updated bootblocks from the releng/9.2 build. zpool.cache is > correct, the zpool imports fine from the 9.2-RC3 live cd. The zpool's > bootfs is set correctly, the zfs mountpoint of data/root is / . And, > of course, init is present and health in data/root. The system booted > fine until updating to 9.2. I just wish that I could reproduce this problem using exactly the same setup... But I can't. Perhaps there are any other special things about your configuration - like having other pools or other disks/partitions that are not used by 'data' pool. Any other non-standard things... -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Sep 13 13:22:59 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D53801B5; Fri, 13 Sep 2013 13:22:59 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DCB41224D; Fri, 13 Sep 2013 13:22:58 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA16588; Fri, 13 Sep 2013 16:22:57 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VKTKr-000Oyv-1U; Fri, 13 Sep 2013 16:22:57 +0300 Message-ID: <52331179.4030201@FreeBSD.org> Date: Fri, 13 Sep 2013 16:22:01 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: "freebsd-fs@freebsd.org" , freebsd-stable Subject: Re: zfs_enable vs zfs_load in loader.conf (but neither works) References: <523310E2.4050702@FreeBSD.org> In-Reply-To: <523310E2.4050702@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: J David X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Sep 2013 13:22:59 -0000 Now some high level information on how ZFS boot works and a little bit more detailed information on how a root filesystem is chosen in ZFS case. The information is applicable to recent versions of FreeBSD in head, stable/9 (including upcoming 9.2) and stable/8 (including 8.4). - boot0-like stage always takes boot2-like stage from the same disk using simple rules - boot2-like stage probes all disks and partitions it can understand for ZFS pools - default pool is the first pool detected by probing which starts at boot disk - default filesystem is determined by bootfs property - boot2-like stage allows to select a different pool, a specific filesystem in the pool and a specific loader boot0-like stage is pmbr in the case of GPT partitioning. boot0-like stage is the first block of zfsboot in the case of whole-disk ZFS. boot2-like stage is either gptzfsboot or zfsboot correspondingly. - loader uses boot pool and filesystem information passed by boot2-like stage - loader exposes loaddev and currdev variables, initially they point to the pool and filesystem obtained from boot2-like stage - currdev can be changed (e.g. at the prompt) while loaddev is read only - kernel and modules are loaded from currdev by default - kernel mounts root from a filesystem specified by vfs.root.mountfrom variable that is passed by loader to kenv - value of the variable is determined as follows: - loader tries to set this variable based on "/" entry, if any, in /etc/fstab, if any, in the filesystem specified by currdev - the variable can be explicitly set in loader.conf or at the prompt; the explicit assignment overrides the fstab-based auto-detected value - for ZFS, if the above methods do not produce any value, vfs.root.mountfrom is set based on currdev So, you can see that all three methods mentioned in this thread can work equally well. You can either specify a root entry in fstab, or set vfs.root.mountfrom in loader.conf, or simply set bootfs property. The above information also describes precedence rules if more than one knob is used: vfs.root.mountfrom is the most significant, fstab is after it, bootfs plays role in root filesystem selection only if neither of the previous is set. Thus, it's completely up to you which method to use. Whichever is more convenient. I prefer to just set bootfs. Another piece of information is that neither mountpoint nor canmount property affects ZFS root mounting. They of course have their usual effect in other contexts like importing a pool on a different system or when a different filesystem is selected to be a root filesystem. So, again, you can set these properties to whatever is most convenient for you. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Sep 13 19:29:52 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 964D1423 for ; Fri, 13 Sep 2013 19:29:52 +0000 (UTC) (envelope-from hskuhra@eumx.net) Received: from owm.eumx.net (eumx.net [91.82.101.43]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4D9052C72 for ; Fri, 13 Sep 2013 19:29:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=eumx.net; h=date :message-id:from:to:cc:subject:in-reply-to:references :mime-version:content-type; s=default; bh=UBGWbXejbZo7bbmtbJoaJz KUlDU=; b=0QlBg6HBHCncyJV7UeSgSwxVSuhmJYvXr2SMA2c2PliKwD3Em+N//f zm+a76bHoiT2gPD0UpgDbwcrSn3C+6mnQtgfVm3ltwIOUPDARw/Ek853P4glpHn5 CplhBXrOiXkOXuU8SbDx3EaqALtBe0Xs21eOV8Ye0PK4X1buFcsms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=eumx.net; h=date:message-id :from:to:cc:subject:in-reply-to:references:mime-version :content-type; q=dns; s=default; b=GZQsg1wSC9kE4gK8ZENcyDB5o03Hs Q6pHNXrTOJ38ZurzsopyYFEtG1z10Kht1GGP102VFKTD+jqgaPib5HmtwvbbSKVz 8I618hOzNDupn/e2qosjTpO6TIUO7LnTQyjpmPX8iINy4TQcTPZ9fdsMbPh+4oa3 JpfHPwv6nG0M8c= Date: Fri, 13 Sep 2013 21:04:53 +0200 Message-ID: <87li30tuei.wl%hskuhra@eumx.net> From: "Herbert J. Skuhra" To: Frank Seltzer Subject: Re: expr error in 9-STABLE In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.3.50 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Sep 2013 19:29:52 -0000 On Fri, 13 Sep 2013 01:33:05 -0400 (EDT) Frank Seltzer wrote: > Posting because I haven't seen this yet. I have been getting this > error on 2 boxes for the last 2 days. This has been answered before: -- Herbert From owner-freebsd-stable@FreeBSD.ORG Sat Sep 14 06:04:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 090A3890 for ; Sat, 14 Sep 2013 06:04:23 +0000 (UTC) (envelope-from bblister@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DFA6323DB for ; Sat, 14 Sep 2013 06:04:22 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VKixr-0003ZL-RJ for freebsd-stable@freebsd.org; Fri, 13 Sep 2013 23:04:15 -0700 Date: Fri, 13 Sep 2013 23:04:15 -0700 (PDT) From: BBlister To: freebsd-stable@freebsd.org Message-ID: <1379138655839-5843931.post@n5.nabble.com> Subject: fsck_ufs always exits on signal 11 on a VPS (virtio) with SU+J 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.14 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, 14 Sep 2013 06:04:23 -0000 HI, On a VPS machine with virtio drivers, whenever the fsck_ufs is iniated to check a filesystem in autoboot that has softupdates journaling SU+J , from /etc/rc.d/fsck the fsck_ufs exits with SIGNAL 11, and has the very bad consequent, that the reboot is unable to be completed. I have to connect the console, press enter at /bin/sh prompt and issue the fsck /dev/vtbd0s1? by hand. Of course I have to press 'N' to the prompt of using the journal file. This happens on 2 out of 5 partitions every time (on /tmp and on /var, which I believe carry the most write tasks). Because it is very annoying for a headless server that should be up 24/7, I removed all journaling from all filesystems (tunefs -j disable ...) and from then I do not have any problem, during the automatic fsck. Currently, I cannot do many experiments with this system, because it is a production server. But if you have something to propose that wont affect the uptime of it, I could do it. I will do the 9.2 upgrade when we have the release (perhaps this fixes it?). I do not have any other VPS yet, so I cannot do extensive experiments. I am just informing that something wrong exist with virtio drivers and fsck journal. On all other physical servers journaling works as expected. My system is: FreeBSD XXXXX 9.1-STABLE FreeBSD 9.1-STABLE #1 r252094: Sat Jun 22 13:01:50 EEST 2013 root@XXX:/usr/obj/usr/src/sys/arch amd64 while my dmesg is: Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-STABLE #1 r252094: Sat Jun 22 13:01:50 EEST 2013 root@aXXXXXX:/usr/obj/usr/src/sys/arch amd64 gcc version 4.2.1 20070831 patched [FreeBSD] CPU: QEMU Virtual CPU version 0.12.5 (2266.75-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x623 Family = 0x6 Model = 0x2 Stepping = 3 Features=0x783fbfd Features2=0x80802001 AMD Features=0x20100800 AMD Features2=0x1 real memory = 536870912 (512 MB) avail memory = 503635968 (480 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 100000000 Hz quality 950 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci_link4: Unable to route IRQs: AE_NOT_FOUND isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc000-0xc00f at device 1.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 uhci0: port 0xc020-0xc03f irq 11 at device 1.2 on pci0 usbus0: controller did not stop usbus0 on uhci0 pci0: at device 1.3 (no driver attached) vgapci0: mem 0xf0000000-0xf1ffffff,0xf2000000-0xf2000fff at device 2.0 on pci0 virtio_pci0: port 0xc040-0xc05f mem 0xf2020000-0xf2020fff irq 11 at device 3.0 on pci0 vtnet0: on virtio_pci0 virtio_pci0: host features: 0x511fffa3 virtio_pci0: negotiated features: 0x110fbba3 vtnet0: Ethernet address: de:db:ee:d9:35:32 virtio_pci1: port 0xc080-0xc0bf mem 0xf2030000-0xf2030fff irq 11 at device 4.0 on pci0 vtblk0: on virtio_pci1 virtio_pci1: host features: 0x51000294 virtio_pci1: negotiated features: 0x10000214 vtblk0: 80000MB (163840000 512 byte sectors) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] orm0: at iomem 0xc9000-0xd0fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 attimer0: at port 0x40 on isa0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 wbwd0: HEFRAS and EFER do not align: EFER 0x2e DevID 0xff DevRev 0xff CR26 0xff Timecounters tick every 10.000 msec ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to accept, logging disabled usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 pass0 at ata1 bus 0 scbus1 target 0 lun 0 pass0: Removable CD-ROM SCSI-0 device pass0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes) Timecounter "TSC-low" frequency 1133374638 Hz quality 800 Root mount waiting for: usbus0 uhub0: 2 ports with 2 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 Trying to mount root from ufs:/dev/vtbd0s1a [rw]... -- View this message in context: http://freebsd.1045724.n5.nabble.com/fsck-ufs-always-exits-on-signal-11-on-a-VPS-virtio-with-SU-J-tp5843931.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Sat Sep 14 08:28:19 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 06FA1DF8 for ; Sat, 14 Sep 2013 08:28:19 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8533E28E5 for ; Sat, 14 Sep 2013 08:28:18 +0000 (UTC) Received: by mail-ea0-f169.google.com with SMTP id k11so1023565eaj.0 for ; Sat, 14 Sep 2013 01:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=rVxq+Y2lg0Eq4befmEx+o4HT3OXwZYOtYBUiQ7YJ5eU=; b=jLxl6Kgr+//a86zmCuKLict59uK5PnL/w0lwHlaAKQ3DsYKzaeh07fgVJB1N8k3+U1 wGg7n6EPEsg4MSGMkDp8VxG1IKXfl2XoeUcM5VscNEjfFlgmXJGEO6lCgyI/+Ss6kLJV joyTHWGz88gOMMeqp9rEG7NuSbzh2noN0FpVAvBAEYkr0rfTZnJQsX8JTr/qs2HMyFkg huY9aQySHR0/9qYnL1dfpUkNe2hvwSXrZ7rJDOVBV/uZBZzHh/YQWJLUrgghkeipNIFq 4ZaLQW4oadcjlknlEec6S7EZKeeCztvD7e3ndf+DyzczRcAOnMZSkGTscGFRqhzPK2cB tzBw== X-Received: by 10.15.26.136 with SMTP id n8mr160767eeu.65.1379147296819; Sat, 14 Sep 2013 01:28:16 -0700 (PDT) Received: from limbo.b1t.lan (ratatosk.b1t.name. [46.150.100.6]) by mx.google.com with ESMTPSA id x47sm21946067eea.16.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Sep 2013 01:28:16 -0700 (PDT) Message-ID: <52341E1F.4080602@gmail.com> Date: Sat, 14 Sep 2013 11:28:15 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130909 Thunderbird/17.0.8 MIME-Version: 1.0 To: stable@freebsd.org Subject: LOR's in 9.2-RC4, anyone? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Sep 2013 08:28:19 -0000 Hello. That's from one of my machines running RC4: Sep 14 11:19:36 slylandro kernel: lock order reversal: Sep 14 11:19:36 slylandro kernel: 1st 0xfffffe002e41b878 tmpfs (tmpfs) @ /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1907 Sep 14 11:19:36 slylandro kernel: 2nd 0xfffffe019b06c680 zfs (zfs) @ /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1938 Sep 14 11:19:36 slylandro kernel: KDB: stack backtrace: Sep 14 11:19:36 slylandro kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff9f8492d2d0 Sep 14 11:19:36 slylandro kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff9f8492d380 Sep 14 11:19:36 slylandro kernel: witness_checkorder() at witness_checkorder+0xc0a/frame 0xffffff9f8492d400 Sep 14 11:19:36 slylandro kernel: __lockmgr_args() at __lockmgr_args+0x744/frame 0xffffff9f8492d520 Sep 14 11:19:36 slylandro kernel: vop_stdlock() at vop_stdlock+0x3c/frame 0xffffff9f8492d540 Sep 14 11:19:36 slylandro kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbe/frame 0xffffff9f8492d570 Sep 14 11:19:36 slylandro kernel: unionfs_lock() at unionfs_lock+0x4c6/frame 0xffffff9f8492d600 Sep 14 11:19:36 slylandro kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbe/frame 0xffffff9f8492d630 Sep 14 11:19:36 slylandro kernel: _vn_lock() at _vn_lock+0x54/frame 0xffffff9f8492d690 Sep 14 11:19:36 slylandro kernel: unionfs_root() at unionfs_root+0x43/frame 0xffffff9f8492d6c0 Sep 14 11:19:36 slylandro kernel: lookup() at lookup+0x99d/frame 0xffffff9f8492d750 Sep 14 11:19:36 slylandro kernel: namei() at namei+0x589/frame 0xffffff9f8492d800 Sep 14 11:19:36 slylandro kernel: unp_connect() at unp_connect+0x1b3/frame 0xffffff9f8492da60 Sep 14 11:19:36 slylandro kernel: uipc_connect() at uipc_connect+0x47/frame 0xffffff9f8492da90 Sep 14 11:19:36 slylandro kernel: kern_connect() at kern_connect+0xdb/frame 0xffffff9f8492dae0 Sep 14 11:19:36 slylandro kernel: sys_connect() at sys_connect+0x96/frame 0xffffff9f8492db20 Sep 14 11:19:36 slylandro kernel: amd64_syscall() at amd64_syscall+0x259/frame 0xffffff9f8492dc30 Sep 14 11:19:36 slylandro kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff9f8492dc30 Sep 14 11:19:36 slylandro kernel: --- syscall (98, FreeBSD ELF64, sys_connect), rip = 0x801f4d8ac, rsp = 0x7fffffff6c18, rbp = 0x7fffffff6c40 --- Sep 14 11:19:39 slylandro kernel: lock order reversal: Sep 14 11:19:39 slylandro kernel: 1st 0xfffffe0089d87878 zfs (zfs) @ /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:312 Sep 14 11:19:39 slylandro kernel: 2nd 0xfffffe0280cc9680 unionfs (unionfs) @ /usr/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:366 Sep 14 11:19:39 slylandro kernel: 3rd 0xfffffe002e3ec098 zfs (zfs) @ /usr/src/sys/kern/vfs_subr.c:2335 Sep 14 11:19:39 slylandro kernel: KDB: stack backtrace: Sep 14 11:19:39 slylandro kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff9f835fe120 Sep 14 11:19:39 slylandro kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff9f835fe1d0 Sep 14 11:19:39 slylandro kernel: witness_checkorder() at witness_checkorder+0xc0a/frame 0xffffff9f835fe250 Sep 14 11:19:39 slylandro kernel: __lockmgr_args() at __lockmgr_args+0x744/frame 0xffffff9f835fe370 Sep 14 11:19:39 slylandro kernel: vop_stdlock() at vop_stdlock+0x3c/frame 0xffffff9f835fe390 Sep 14 11:19:39 slylandro kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbe/frame 0xffffff9f835fe3c0 Sep 14 11:19:39 slylandro kernel: _vn_lock() at _vn_lock+0x54/frame 0xffffff9f835fe420 Sep 14 11:19:39 slylandro kernel: vputx() at vputx+0x21b/frame 0xffffff9f835fe480 Sep 14 11:19:39 slylandro kernel: unionfs_noderem() at unionfs_noderem+0x1cf/frame 0xffffff9f835fe4f0 Sep 14 11:19:39 slylandro kernel: unionfs_reclaim() at unionfs_reclaim+0x14/frame 0xffffff9f835fe500 Sep 14 11:19:39 slylandro kernel: VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xb9/frame 0xffffff9f835fe530 Sep 14 11:19:39 slylandro kernel: vgonel() at vgonel+0x16e/frame 0xffffff9f835fe5a0 Sep 14 11:19:39 slylandro kernel: vrecycle() at vrecycle+0x3e/frame 0xffffff9f835fe5d0 Sep 14 11:19:39 slylandro kernel: unionfs_inactive() at unionfs_inactive+0x23/frame 0xffffff9f835fe5e0 Sep 14 11:19:39 slylandro kernel: VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xb9/frame 0xffffff9f835fe610 Sep 14 11:19:39 slylandro kernel: vinactive() at vinactive+0xc6/frame 0xffffff9f835fe660 Sep 14 11:19:39 slylandro kernel: vputx() at vputx+0x263/frame 0xffffff9f835fe6c0 Sep 14 11:19:39 slylandro kernel: lookup() at lookup+0xd2c/frame 0xffffff9f835fe750 Sep 14 11:19:39 slylandro kernel: namei() at namei+0x589/frame 0xffffff9f835fe800 Sep 14 11:19:39 slylandro kernel: unp_connect() at unp_connect+0x1b3/frame 0xffffff9f835fea60 Sep 14 11:19:39 slylandro kernel: uipc_connect() at uipc_connect+0x47/frame 0xffffff9f835fea90 Sep 14 11:19:39 slylandro kernel: kern_connect() at kern_connect+0xdb/frame 0xffffff9f835feae0 Sep 14 11:19:39 slylandro kernel: sys_connect() at sys_connect+0x96/frame 0xffffff9f835feb20 Sep 14 11:19:39 slylandro kernel: amd64_syscall() at amd64_syscall+0x259/frame 0xffffff9f835fec30 Sep 14 11:19:39 slylandro kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff9f835fec30 Sep 14 11:19:39 slylandro kernel: --- syscall (98, FreeBSD ELF64, sys_connect), rip = 0x801f4d8ac, rsp = 0x7fffffff7628, rbp = 0x7fffffff7650 --- -- Sphinx of black quartz judge my vow. From owner-freebsd-stable@FreeBSD.ORG Sat Sep 14 10:46:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A1409811 for ; Sat, 14 Sep 2013 10:46:25 +0000 (UTC) (envelope-from frank_s@bellsouth.net) Received: from fmailhost05.isp.att.net (fmailhost05.isp.att.net [204.127.217.105]) by mx1.freebsd.org (Postfix) with ESMTP id 8C2752F1C for ; Sat, 14 Sep 2013 10:46:25 +0000 (UTC) Received: from ace.nina.org (adsl-74-178-52-115.gnv.bellsouth.net[74.178.52.115]) by isp.att.net (frfwmhc05) with SMTP id <20130914104616H05008pt24e>; Sat, 14 Sep 2013 10:46:17 +0000 X-Originating-IP: [74.178.52.115] Date: Sat, 14 Sep 2013 06:46:14 -0400 (EDT) From: Frank Seltzer X-X-Sender: frank_s@Ace.nina.org To: "Herbert J. Skuhra" Subject: Re: expr error in 9-STABLE In-Reply-To: <87li30tuei.wl%hskuhra@eumx.net> Message-ID: References: <87li30tuei.wl%hskuhra@eumx.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Sep 2013 10:46:25 -0000 On Fri, 13 Sep 2013, Herbert J. Skuhra wrote: > On Fri, 13 Sep 2013 01:33:05 -0400 (EDT) > Frank Seltzer wrote: > >> Posting because I haven't seen this yet. I have been getting this >> error on 2 boxes for the last 2 days. > > This has been answered before: > > > > -- > Herbert Any reason this isn't in /usr/src/UPDATING? Frank From owner-freebsd-stable@FreeBSD.ORG Sat Sep 14 13:06:01 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 049E8D97; Sat, 14 Sep 2013 13:06:01 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (mail.ismobile.com [IPv6:2a00:f680:101:11::4]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AF64925E1; Sat, 14 Sep 2013 13:06:00 +0000 (UTC) Received: from mail.ismobile.com (localhost [127.0.0.1]) by dkim.mail.ismobile.com (Postfix) with ESMTP id 068B42B549F; Sat, 14 Sep 2013 13:05:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ismobile.com; h=date:from :reply-to:to:cc:subject:message-id:mime-version:content-type :content-transfer-encoding; s=selector1; bh=pE19mGFuPbvdIoFVeTK3 13sitEA=; b=Pa+nXiuvnjkwkyQUcshcuNkHFwwkkPeQ+lD0t6Fnuj9yZY/91vwO m9HjyrUv8sVbxmNFdvyhUVgHLmrR53olGR+szJXRa4M7nTkHG/SSZaEIhTw2qd2Z sORln2KfI7rvLLGbR4e1kBS8205IWBqRzJYb+wv3YZfpj+7HydAmx40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=ismobile.com; h=date:from :reply-to:to:cc:subject:message-id:mime-version:content-type :content-transfer-encoding; q=dns; s=selector1; b=esNBtLsI1twJOD jkDhs9U2r6sEvkL+b1psIwdiqavpLOWvn4iKMcgBuXR6ACTh0zTzBhKNi42f4B7c 9MsGDYFR7MF9mi4J6s4JCjm/Ds/xn3K2c2StVTF/Qv5Hvg4iwlP7qIJWuTmLN2Nn yflPXD+tdMxeaEx76bWjySbVinuO0= Received: from [10.255.253.2] (h77-53-100-26.dynamic.se.alltele.net [77.53.100.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ismobile.com (Postfix) with ESMTPSA id C4FC42B549D; Sat, 14 Sep 2013 13:05:56 +0000 (UTC) Date: Sat, 14 Sep 2013 15:05:56 +0200 From: goran.lowkrantz@ismobile.com, "glz@"@ismobile.com To: Alexander Motin Subject: VIMAGE kernel broken after 255541 Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Goran Lowkrantz List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 13:06:01 -0000 Hi, After 255541 I can't compile a VIMAGE kernel: cc1: warnings being treated as errors /usr/src/sys/kern/sched_ule.c: In function 'cpu_search': /usr/src/sys/kern/sched_ule.c:638: warning: implicit declaration of function 'CPU_FFS' /usr/src/sys/kern/sched_ule.c:638: warning: nested extern declaration of 'CPU_FFS' [-Wnested-externs] *** [sched_ule.o] Error code 1 Kernconf: VSERVER: # # VSERVER --A VIMAGE kernel configuration file for FreeBSD/amd64 # # $FreeBSD: stable/9/sys/amd64/conf/XENHVM 239412 2012-08-20 11:34:49Z cperciva $ # include SERVER ident VSERVER # VIMAGE config option VIMAGE SERVER: # # SERVER -- General server # include GENERIC ident SERVER # Update resources for PostgreSQL options SHMMAXPGS=65536 options SEMMNI=40 options SEMMNS=240 options SEMUME=40 options SEMMNU=120 # # Compile with kernel debugger related code. # options KDB options KDB_TRACE options KDB_UNATTENDED options DDB #options INVARIANTS #options INVARIANT_SUPPORT #options WITNESS #options DEBUG_LOCKS #options DEBUG_VFS_LOCKS # Include Apple Talk support options NETATALK /glz From owner-freebsd-stable@FreeBSD.ORG Sat Sep 14 13:41:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4F7F5719 for ; Sat, 14 Sep 2013 13:41:28 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id CE9A027CD for ; Sat, 14 Sep 2013 13:41:27 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 9F9A94FEF; Sat, 14 Sep 2013 13:41:26 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 1E3654A0C9; Sat, 14 Sep 2013 15:40:44 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Patrick Lamaiziere Subject: Reproducible panic in 9.2-RC4 (was: Re: (9.2) panic under disk load (gam_server / knlist_remove_kq)) References: <20130714115953.1afd6e90@davenulle.org> Date: Sat, 14 Sep 2013 15:40:43 +0200 In-Reply-To: <20130714115953.1afd6e90@davenulle.org> (Patrick Lamaiziere's message of "Sun, 14 Jul 2013 11:59:53 +0200") Message-ID: <86vc23ldwk.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Sep 2013 13:41:28 -0000 Patrick Lamaiziere writes: > I'm seeing a panic while trying to build a poudriere repository. > [...] A related panic still occurs in 9.2-RC4. It is 100% reproducible: just start a poudriere build while Gnome is running. The culprit this time seems to be gvfsd-trash. Killing it doesn't work, because Gnome will restart it, but stopping it (pkill -STOP gvfsd-trash) does. I merged r254024 from stable/9 to see if it would help; it didn't. I get the following core.txt: Fatal trap 12: page fault while in kernel mode cpuid =3D 2; apic id =3D 02 fault virtual address =3D 0x368 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff808f920d stack pointer =3D 0x28:0xffffff825217c770 frame pointer =3D 0x28:0xffffff825217c7e0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 1707 (gvfsd-trash) trap number =3D 12 panic: page fault cpuid =3D 2 KDB: stack backtrace: #0 0xffffffff80947986 at kdb_backtrace+0x66 #1 0xffffffff8090d9ae at panic+0x1ce #2 0xffffffff80cf2110 at trap_fatal+0x290 #3 0xffffffff80cf2471 at trap_pfault+0x211 #4 0xffffffff80cf2a24 at trap+0x344 #5 0xffffffff80cdbd53 at calltrap+0x8 #6 0xffffffff809ab5e3 at filt_vfsvnode+0xf3 #7 0xffffffff808d1d46 at kqueue_register+0x3e6 #8 0xffffffff808d2396 at kern_kevent+0x106 #9 0xffffffff808d2ed0 at sys_kevent+0x90 #10 0xffffffff80cf18ba at amd64_syscall+0x5ea #11 0xffffffff80cdc037 at Xfast_syscall+0xf7 but gdb gives a slightly different backtrace: #0 doadump (textdump=3D) at pcpu.h:234 #1 0xffffffff8090d486 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0xffffffff8090d987 in panic (fmt=3D0x1
) at /usr/src/sys/kern/kern_shutdown.c:637 #3 0xffffffff80cf2110 in trap_fatal (frame=3D0xc, eva=3D) at /usr/src/sys/amd64/amd64/trap.c:879 #4 0xffffffff80cf2471 in trap_pfault (frame=3D0xffffff825217c6c0, usermode= =3D0) at /usr/src/sys/amd64/amd64/trap.c:795 #5 0xffffffff80cf2a24 in trap (frame=3D0xffffff825217c6c0) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0xffffffff80cdbd53 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #7 0xffffffff808f920d in _mtx_lock_sleep (m=3D0xfffffe01068564b8,=20 tid=3D18446741882246426624, opts=3D,=20 file=3D, line=3D0) at /usr/src/sys/kern/kern_mutex= .c:388 #8 0xffffffff809ab5e3 in filt_vfsvnode (kn=3D0xfffffe0136e11d00, hint=3D0) at /usr/src/sys/kern/vfs_subr.c:4600 #9 0xffffffff808d1d46 in kqueue_register (kq=3D0xfffffe001a73ec00,=20 kev=3D0xffffff825217c980, td=3D0xfffffe01c29e7000, waitok=3D1) at /usr/src/sys/kern/kern_event.c:1136 #10 0xffffffff808d2396 in kern_kevent (td=3D0xfffffe01c29e7000,=20 fd=3D, nchanges=3D7, nevents=3D1, k_ops=3D0xffffff= 825217caa0,=20 timeout=3D0x0) at /usr/src/sys/kern/kern_event.c:847 #11 0xffffffff808d2ed0 in sys_kevent (td=3D0xfffffe01c29e7000,=20 uap=3D0xffffff825217cbb0) at /usr/src/sys/kern/kern_event.c:768 #12 0xffffffff80cf18ba in amd64_syscall (td=3D0xfffffe01c29e7000, traced=3D= 0) at subr_syscall.c:135 #13 0xffffffff80cdc037 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #14 0x0000000802e84d8c in ?? () Previous frame inner to this frame (corrupt stack?) This is GENERIC built from the latest releng/9.2 sources with no other modifications than the addition of r254024. With the stock kernel (from freebsd-update), I get #0 0xffffffff80947986 at kdb_backtrace+0x66 #1 0xffffffff8090d9ae at panic+0x1ce #2 0xffffffff80cf20d0 at trap_fatal+0x290 #3 0xffffffff80cf2431 at trap_pfault+0x211 #4 0xffffffff80cf29e4 at trap+0x344 #5 0xffffffff80cdbd13 at calltrap+0x8 #6 0xffffffff808d2396 at kern_kevent+0x106 #7 0xffffffff808d2ed0 at sys_kevent+0x90 #8 0xffffffff80cf187a at amd64_syscall+0x5ea #9 0xffffffff80cdbff7 at Xfast_syscall+0xf7 but kgdb is useless - it doesn't see past calltrap(). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Sat Sep 14 13:12:57 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1E97C1EA for ; Sat, 14 Sep 2013 13:12:57 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AA9022663 for ; Sat, 14 Sep 2013 13:12:56 +0000 (UTC) Received: by mail-ea0-f169.google.com with SMTP id k11so1112762eaj.14 for ; Sat, 14 Sep 2013 06:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=bWKvWliH+q7FSU3woehRrCY63FJGP86IWF0EV8Mh3Zs=; b=tz90z2MY1wht5hA0CXBsZBr9EElhvWFdvT0HqrBoOMD9U7VJGJN4+Hc8VW+bbXw4/B QYOBh6AodboLkk+4SWEDBzzohmr0mRYqGk6tfecifMPU4bNivFzxRCavswfQkxLGrX/F nME7rGs9t+7xmNEEDyWs1DiUQDp3S1LGIIRNZ2NSotKyDzF36rx3qKyFdwjecSrjWkrt xWQ+iXmqkpzPMK09o4N+wI0LUnZYWoxFsGItIRqKX1NusjNCo9Bs1uvmfxccVq9pxGUk lxpimr2shkpccfOEeNGeTrtwuAHuO9NV/nqPUfDzK9xGYXZ4eu//3xdPpulvECcrEMcu 0yXw== X-Received: by 10.14.45.70 with SMTP id o46mr26288578eeb.19.1379164375154; Sat, 14 Sep 2013 06:12:55 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([5.248.115.71]) by mx.google.com with ESMTPSA id h52sm24049548eez.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Sep 2013 06:12:54 -0700 (PDT) Sender: Alexander Motin Message-ID: <523460D4.7040404@FreeBSD.org> Date: Sat, 14 Sep 2013 16:12:52 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130616 Thunderbird/17.0.6 MIME-Version: 1.0 To: Goran Lowkrantz Subject: Re: VIMAGE kernel broken after 255541 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 14 Sep 2013 18:35:07 +0000 Cc: ", @@ismobile.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Sep 2013 13:12:57 -0000 Hi. The change is reverted. Sorry. On 14.09.2013 16:05, goran.lowkrantz@ismobile.com wrote: > Hi, > > After 255541 I can't compile a VIMAGE kernel: > cc1: warnings being treated as errors > /usr/src/sys/kern/sched_ule.c: In function 'cpu_search': > /usr/src/sys/kern/sched_ule.c:638: warning: implicit declaration of > function 'CPU_FFS' > /usr/src/sys/kern/sched_ule.c:638: warning: nested extern declaration of > 'CPU_FFS' [-Wnested-externs] > *** [sched_ule.o] Error code 1 > > Kernconf: > VSERVER: > # > # VSERVER --A VIMAGE kernel configuration file for FreeBSD/amd64 > # > # $FreeBSD: stable/9/sys/amd64/conf/XENHVM 239412 2012-08-20 11:34:49Z > cperciva $ > # > include SERVER > ident VSERVER > > # VIMAGE config > option VIMAGE > > SERVER: > # > # SERVER -- General server > # > > include GENERIC > > ident SERVER > > # Update resources for PostgreSQL > options SHMMAXPGS=65536 > options SEMMNI=40 > options SEMMNS=240 > options SEMUME=40 > options SEMMNU=120 > > # > # Compile with kernel debugger related code. > # > options KDB > options KDB_TRACE > options KDB_UNATTENDED > options DDB > > #options INVARIANTS > #options INVARIANT_SUPPORT > #options WITNESS > > #options DEBUG_LOCKS > #options DEBUG_VFS_LOCKS > > # Include Apple Talk support > options NETATALK > > > /glz -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Sat Sep 14 16:53:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7B7B8226; Sat, 14 Sep 2013 16:53:23 +0000 (UTC) (envelope-from thomas@gibfest.dk) Received: from mail.tyknet.dk (mail.tyknet.dk [176.9.9.186]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 332262F6A; Sat, 14 Sep 2013 16:53:22 +0000 (UTC) Received: from [10.10.1.214] (217.71.4.82.static.router4.bolignet.dk [217.71.4.82]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id E92B619BFC4; Sat, 14 Sep 2013 18:43:54 +0200 (CEST) X-DKIM: OpenDKIM Filter v2.5.2 mail.tyknet.dk E92B619BFC4 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1379177035; bh=/0FjT7AboV+FCnQ5L52bPk+nrauPBsiJSKa8rjd/znc=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=MoVkvfXWDJ+vFOafvSyqRWU23nC/+yy8KMOdWLnCgHpTMlLKcTd7Jhwy1QgLXuOlF LPEVjwu0/EybskIxoGBTMbFbzrNNliN7fGvpYUwxs3u+XZNDunt/hQ8R+Uv2/j0LZq WsCh6nFAA/mHQLp8JetIc/vnH+oKPfrGXpZ0niHQ= Message-ID: <52349247.1060203@gibfest.dk> Date: Sat, 14 Sep 2013 18:43:51 +0200 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Goran Lowkrantz Subject: Re: VIMAGE kernel broken after 255541 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 14 Sep 2013 19:46:27 +0000 Cc: Alexander Motin , ", @@ismobile.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Sep 2013 16:53:23 -0000 On 14-09-2013 15:05, goran.lowkrantz@ismobile.com wrote: > Hi, > > After 255541 I can't compile a VIMAGE kernel: > cc1: warnings being treated as errors > /usr/src/sys/kern/sched_ule.c: In function 'cpu_search': > /usr/src/sys/kern/sched_ule.c:638: warning: implicit declaration of > function 'CPU_FFS' > /usr/src/sys/kern/sched_ule.c:638: warning: nested extern declaration > of 'CPU_FFS' [-Wnested-externs] > *** [sched_ule.o] Error code 1 > Hello, This is not related to VIMAGE and it was fixed in this commit: http://svnweb.freebsd.org/base?view=revision&revision=255569 Best regards, Thomas Steen Rasmussen