From owner-freebsd-stable@FreeBSD.ORG Sun Jul 27 09:22:19 2014 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 ESMTPS id 215AE125; Sun, 27 Jul 2014 09:22:19 +0000 (UTC) Received: from thetys.cloudzeeland.nl (webrz.xs4all.nl [83.161.133.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloudzeeland.nl", Issuer "PositiveSSL CA 2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A52F27A5; Sun, 27 Jul 2014 09:22:17 +0000 (UTC) Received: from thetys.cloudzeeland.nl (thetys.cloudzeeland.nl [10.10.10.31]) by thetys.cloudzeeland.nl (Postfix) with ESMTP id DF2001689C32; Sun, 27 Jul 2014 11:17:34 +0200 (CEST) Received: from [10.10.10.70] (daedalus.cloudzeeland.nl [10.10.10.70]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by thetys.cloudzeeland.nl (Postfix) with ESMTPSA id A6E811689B5F; Sun, 27 Jul 2014 11:17:34 +0200 (CEST) Message-ID: <53D4C450.6010001@webrz.net> Date: Sun, 27 Jul 2014 11:20:16 +0200 From: Jos Chrispijn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: Kevin Oberman , Baptiste Daroussin Subject: Re: [ANNOUNCEMENT] pkg 1.3.0 out! References: <20140723144249.GD69907@ivaldir.etoilebsd.net> In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP on thetys.cloudzeeland.nl MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "ports@FreeBSD.org" , FreeBSD Stable ML , "current@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 09:22:19 -0000 Just tried to update the port: ===>>> Creating a backup package for old version pkg-1.3.0 Creating package for pkg-1.3.0 Checking integrity... done (0 conflicting) Deinstallation has been requested for the following 1 packages (of 1 packages in the universe): Installed packages to be REMOVED: pkg-1.3.0 The operation will free 7 MB [1/1] Deleting pkg-1.3.0: 100% ===>>> Starting check for runtime dependencies ===>>> Gathering dependency list for ports-mgmt/pkg from ports ===>>> No dependencies for ports-mgmt/pkg ===> Installing for pkg-1.3.1 ===> Checking if ports-mgmt/pkg already installed Child process pid=82376 terminated abnormally: Segmentation fault: 11 *** [check-already-installed] Error code 245 Stop in /usr/ports/ports-mgmt/pkg. *** [/usr/ports/ports-mgmt/pkg/work/.install_done.pkg._usr_local] Error code 1 Stop in /usr/ports/ports-mgmt/pkg. ===>>> A backup package for pkg-1.3.0 should be located in /usr/ports/packages/portmaster-backup ===>>> Installation of pkg-1.3.1 (ports-mgmt/pkg) failed ===>>> Aborting update ===>>> Update for ports-mgmt/pkg failed ===>>> Aborting update Any suggestion to solve this? Perhaps I am doing something wrong here - pls advise. thanks, Jos Chrispijn Kevin Oberman: On Wed, Jul 23, 2014 at 7:42 AM, Baptiste Daroussin [1] wrote: Hi all, I'm very please to announce the release of pkg 1.3.0 This version is the result of almost 9 month of hard work Here are the statistics for the version: - 373 files changed, 66973 insertions(+), 38512 deletions(-) - 29 different contributors Please not that for the first time I'm not the main contributor, and I would like to particularly thanks Vsevold Stakhov for all the hard work he has done to allow us to get this release out. I would like also to give a special thanks to Andrej Zverev for the tons of hours spending on testing and cleaning the bug tracker! So much has happened that it is hard to summarize so I'll try to highlight the major points: - New solver, now pkg has a real SAT solver able to automatically handle conflicts and dynamically discover them. (yes pkg set -o is deprecated now) - pkg install now able to install local files as well and resolve their dependencies from the remote repositories - Lots of parts of the code has been sandboxed - Lots of rework to improve portability - Package installation process has been reworked to be safer and handle properly the schg flags - Important modification of the locking system for finer grain locks - Massive usage of libucl - Simplification of the API - Lots of improvements on the UI to provide a better user experience. - Lots of improvements in multi repository mode - pkg audit code has been moved into the library - pkg -o A=B that will overwrite configuration file from cli - The ui now support long options - The unicity of a package is not anymore origin - Tons of bug fixes - Tons of behaviours fixes - Way more! Thank you to all contributors: Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad Davis, Bryan Drewery, Dag-Erling Smørgrav, Dmitry Marakasov, Elvira Khabirova, Jamie Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Arnold, Matthew Seaman, Maximilian GaÃY, Michael Gehring, Michael Gmelin, Nicolas Szalay, Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. Putrya, Vsevolod Stakhov, Xin Li, coctic Regards, Bapt on behalf of the pkg@ Really, really great news! Congrats to Bapt and all of the contributors, large and small, for doing the work to make this happen. The real, live, provable solver is something that was desperately needed. Thaqt is followed closely with multi-repository mode. All of the rest is great, too. I think one bullet was a bit mangled in French->English translation, though. What does "The unicity of a package is not anymore origin" mean? I have a couple of guesses, but I am not really sure. Ithink the best translations would be "The unicity of a package is no longer the origin", but I am unsure of "unicity". "Uniqueness"? That would make sense, but I am not quite sure that is what was meant. -- R. Kevin Oberman, Network Engineer, Retired E-mail: [2]rkoberman@gmail.com _______________________________________________ [3]freebsd-ports@freebsd.org mailing list [4]http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [5]"freebsd-ports-unsubscribe@freebsd.org" References 1. mailto:bapt@freebsd.org 2. mailto:rkoberman@gmail.com 3. mailto:freebsd-ports@freebsd.org 4. http://lists.freebsd.org/mailman/listinfo/freebsd-ports 5. mailto:freebsd-ports-unsubscribe@freebsd.org From owner-freebsd-stable@FreeBSD.ORG Sun Jul 27 14:44:54 2014 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 ESMTPS id 0540E1B7 for ; Sun, 27 Jul 2014 14:44:54 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CB6C222F for ; Sun, 27 Jul 2014 14:44:53 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s6REioSU097753; Sun, 27 Jul 2014 16:44:50 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 36F7D3C7A; Sun, 27 Jul 2014 16:44:49 +0200 (CEST) Message-ID: <53D5105A.6040204@omnilan.de> Date: Sun, 27 Jul 2014 16:44:42 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: panic/lock on 9.3-RELEASE with nullfs/nfs/zfs combination References: <53D12973.3010805@omnilan.de> <20140724165917.GT93733@kib.kiev.ua> <53D1503B.2030200@omnilan.de> <20140724193048.GU93733@kib.kiev.ua> <53D2006C.7090207@omnilan.de> <20140725151448.GY93733@kib.kiev.ua> <53D380B2.2080700@omnilan.de> <20140726114839.GF93733@kib.kiev.ua> In-Reply-To: <20140726114839.GF93733@kib.kiev.ua> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig09804AF5039DD5A9FD7ABF27" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Sun, 27 Jul 2014 16:44:50 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 14:44:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig09804AF5039DD5A9FD7ABF27 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Konstantin Belousov's Nachricht vom 26.07.2014 13:48 (localtime): > On Sat, Jul 26, 2014 at 12:19:30PM +0200, Harald Schmalzbauer wrote: >> vnode vnode 0xfffffe006cb86bd0: 0xfffffe006cb86bd0: tag null, type VDI= R >> tag null, type VDIR >> usecount 1, writecount 0, refcount 1 mountedhere 0 >> usecount 1, writecount 0, refcount 1 mountedhere 0 >> flags (VV_ROOT|VI_ACTIVE) >> flags (VV_ROOT|VI_ACTIVE) >> v_object 0xfffffe006c8d30e8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 >> v_object 0xfffffe006c8d30e8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 >> lock type zfs: EXCL by thread 0xfffffe0033498920 (pid 1668) >> lock type zfs: EXCL by thread 0xfffffe0033498920 (pid 1668) >> vp=3D0xfffffe006cb86bd0, lowervp=3D0xfffffe001dbc53f0 >> vp=3D0xfffffe006cb86bd0, lowervp=3D0xfffffe001dbc53f0 >> > It is useful, but still requires more work to get to the issue. From th= e > data you posted, I see that the problem was already reported sometime > this winter. We did not come to any conclusion that time. > > Please, do the following. First, apply this debugging patch and obtain > the same data as you did right now. Hopefully, the assert below would > trigger. > > diff --git a/sys/fs/nullfs/null_vnops.c b/sys/fs/nullfs/null_vnops.c > index 70402e3..bc9772c 100644 > --- a/sys/fs/nullfs/null_vnops.c > +++ b/sys/fs/nullfs/null_vnops.c > @@ -372,6 +372,10 @@ null_lookup(struct vop_lookup_args *ap) > */ > ldvp =3D NULLVPTOLOWERVP(dvp); > vp =3D lvp =3D NULL; > + KASSERT((ldvp->v_vflag & VV_ROOT) =3D=3D 0 || > + ((dvp->v_vflag & VV_ROOT) !=3D 0 && (flags & ISDOTDOT) =3D=3D 0),= > + ("ldvp %p fl %#x dvp %p fl %#x flags %#x", ldvp, ldvp->v_vflag, > + dvp, dvp->v_vflag, flags)); > error =3D VOP_LOOKUP(ldvp, &lvp, cnp); > if (error =3D=3D EJUSTRETURN && (flags & ISLASTCN) && > (dvp->v_mount->mnt_flag & MNT_RDONLY) && I can't emphasize how much I hate my lousy C skills... Got "format '%#x' expects type 'unsigned int', but argument 3 has type 'u_long' [-Wformat]" from the compiler and found out that I can't read/understand any part of your patch; not even the syntax :-( After reading printf(3) I change the 3rd additional line into '("ldvp %p fl %#lx dvp %p fl %#lx flags %#x", ldvp, ldvp->v_vflag,' =E2=80=A6 A blind man may sometimes hit the mark. Here's the console output with an additional (ufs/devfs) LOR prepended: 1st 0xfffffe014bc09098 ufs (ufs) @ /usr/local/share/deploy-tools/RELENG_9_3/src/sys/kern/vfs_mount.c:851 2nd 0xfffffe014bd97098 devfs (devfs) @ /usr/local/share/deploy-tools/RELENG_9_3/src/sys/kern/vfs_subr.c:2225 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xffffff82e4f7c280 kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff82e4f7c340 _witness_debugger() at _witness_debugger+0x2c/frame 0xffffff82e4f7c360 witness_checkorder() at witness_checkorder+0x875/frame 0xffffff82e4f7c420= __lockmgr_args() at __lockmgr_args+0x1197/frame 0xffffff82e4f7c500 vop_stdlock() at vop_stdlock+0x39/frame 0xffffff82e4f7c520 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xe3/frame 0xffffff82e4f7c550 _vn_lock() at _vn_lock+0x57/frame 0xffffff82e4f7c5b0 vget() at vget+0x7b/frame 0xffffff82e4f7c600 devfs_allocv() at devfs_allocv+0x13e/frame 0xffffff82e4f7c660 devfs_root() at devfs_root+0x4d/frame 0xffffff82e4f7c6a0 vfs_donmount() at vfs_donmount+0xb89/frame 0xffffff82e4f7c990 sys_nmount() at sys_nmount+0x66/frame 0xffffff82e4f7c9d0 amd64_syscall() at amd64_syscall+0x318/frame 0xffffff82e4f7caf0 Xfast_syscall() at Xfast_syscall+0xf7/frame 0xffffff82e4f7caf0 --- syscall (378, FreeBSD ELF64, sys_nmount), rip =3D 0x800a94ecc, rsp =3D= 0x7fffffffdc08, rbp =3D 0x7fffffffdc20 --- Here's the panic: panic: ldvp 0xfffffe001bafb000 fl 0x1 dvp 0xfffffe01b4e5a9d8 fl 0 flags 0x120e144 cpuid =3D 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xffffff82e4e88f80 kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff82e4e89040 panic() at panic+0x1cd/frame 0xffffff82e4e89140 null_lookup() at null_lookup+0xa6/frame 0xffffff82e4e891c0 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x102/frame 0xffffff82e4e891f0 lookup() at lookup+0x32f/frame 0xffffff82e4e89290 namei() at namei+0x3df/frame 0xffffff82e4e89340 vn_open_cred() at vn_open_cred+0x1e2/frame 0xffffff82e4e894b0 vop_stdvptocnp() at vop_stdvptocnp+0x1af/frame 0xffffff82e4e897e0 null_vptocnp() at null_vptocnp+0xf5/frame 0xffffff82e4e89850 VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0x105/frame 0xffffff82e4e89880 vn_vptocnp_locked() at vn_vptocnp_locked+0x15b/frame 0xffffff82e4e89910 vn_fullpath1() at vn_fullpath1+0x100/frame 0xffffff82e4e89970 kern___getcwd() at kern___getcwd+0xd4/frame 0xffffff82e4e899d0 amd64_syscall() at amd64_syscall+0x318/frame 0xffffff82e4e89af0 Xfast_syscall() at Xfast_syscall+0xf7/frame 0xffffff82e4e89af0 --- syscall (326, FreeBSD ELF64, sys___getcwd), rip =3D 0x8011a191c, rsp = =3D 0x7fffffffe658, rbp =3D 0x801873400 --- KDB: enter: panic [ thread pid 1676 tid 100824 ] Stopped at kdb_enter+0x3b: movq $0,0x6455e2(%rip) db> show alllocks Process 1676 (vim) thread 0xfffffe0036fb8490 (100824) shared lockmgr zfs (zfs) r =3D 0 (0xfffffe001bafb098) locked @ /usr/local/share/deploy-tools/RELENG_9_3/src/sys/fs/nullfs/null_vnops.c:6= 24 db> show mount =E2=80=A6 0xfffffe0007b03338 /zfs/netshares/deployment/pub/FreeBSD/OmniLAN/ports/ports on /.JAILfbsm/usr/ports (nullfs) =E2=80=A6 db> show mount 0xfffffe0007b03338 0xfffffe0007b03338 /zfs/netshares/deployment/pub/FreeBSD/OmniLAN/ports/ports on /.JAILfbsm/usr/ports (nullfs) mnt_flag =3D LOCAL mnt_kern_flag =3D EXTENDED_SHARED, SHARED_WRITES, LOOKUP_EXCL_DOTDOT, MPSAFE, LOOKUP_SHARED mnt_opt =3D rw, fstype, fspath, target, errmsg mnt_stat =3D { version=3D537068824 type=3D222 flags=3D0x000000001000111c bsize=3D512 iosize=3D131072 blocks=3D6314028651 bfree=3D6309830121 bavail=3D6309830121 files=3D6310125501 ffree=3D6309830121 syncwrites=3D0 asyncwrites=3D0 syncreads=3D0 asyncreads=3D0 namemax=3D255 owner=3D0 fsid=3D[687931140, 41] } mnt_cred =3D { uid=3D0 ruid=3D0 } mnt_ref =3D 56 mnt_gen =3D 1 mnt_nvnodelistsize =3D 56 mnt_activevnodelistsize =3D 5 mnt_writeopcount =3D 0 mnt_maxsymlinklen =3D 0 mnt_iosize_max =3D 65536 mnt_hashseed =3D 308101864 mnt_secondary_writes =3D 0 mnt_secondary_accwrites =3D 0 mnt_gjprovider =3D NULL List of active vnodes vnode vnode 0xfffffe01b4e5a9d8: 0xfffffe01b4e5a9d8: tag null, type VDIR tag null, type VDIR usecount 2, writecount 0, refcount 2 mountedhere 0 usecount 2, writecount 0, refcount 2 mountedhere 0 flags (VI_ACTIVE) flags (VI_ACTIVE) v_object 0xfffffe014bbf4828 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bbf4828 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: SHARED (count 1) lock type zfs: SHARED (count 1) vp=3D0xfffffe01b4e5a9d8, lowervp=3D0xfffffe001bafb000 vp=3D0xfffffe01b4e5a9d8, lowervp=3D0xfffffe001bafb000 vnode vnode 0xfffffe014bf26000: 0xfffffe014bf26000: tag null, type VDIR tag null, type VDIR usecount 3, writecount 0, refcount 3 mountedhere 0 usecount 3, writecount 0, refcount 3 mountedhere 0 flags (VI_ACTIVE) flags (VI_ACTIVE) v_object 0xfffffe01b42ae488 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01b42ae488 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014bf26000, lowervp=3D0xfffffe014bf261f8 vp=3D0xfffffe014bf26000, lowervp=3D0xfffffe014bf261f8 vnode vnode 0xfffffe014bd633f0: 0xfffffe014bd633f0: tag null, type VDIR tag null, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0xfffffe001bb46000 usecount 1, writecount 0, refcount 1 mountedhere 0xfffffe001bb46000 flags (VI_ACTIVE) flags (VI_ACTIVE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014bd633f0, lowervp=3D0xfffffe014bd635e8 vp=3D0xfffffe014bd633f0, lowervp=3D0xfffffe014bd635e8 vnode vnode 0xfffffe014bc08000: 0xfffffe014bc08000: tag syncer, type VNON= tag syncer, type VNON usecount 1, writecount 0, refcount 1 mountedhere 0 usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VI_ACTIVE) flags (VI_ACTIVE) lock type syncer: UNLOCKED lock type syncer: UNLOCKED vnode vnode 0xfffffe014bc03dc8: 0xfffffe014bc03dc8: tag null, type VDIR tag null, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0 usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VV_ROOT|VI_ACTIVE) flags (VV_ROOT|VI_ACTIVE) v_object 0xfffffe014bbf4828 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bbf4828 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: SHARED (count 1) lock type zfs: SHARED (count 1) vp=3D0xfffffe014bc03dc8, lowervp=3D0xfffffe001bafb000 vp=3D0xfffffe014bc03dc8, lowervp=3D0xfffffe001bafb000 List of inactive vnodes vnode vnode 0xfffffe014bd975e8: 0xfffffe014bd975e8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014bbf4740 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bbf4740 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014bd975e8, lowervp=3D0xfffffe014b5c43f0 vp=3D0xfffffe014bd975e8, lowervp=3D0xfffffe014b5c43f0 vnode vnode 0xfffffe014bfe1bd0: 0xfffffe014bfe1bd0: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01b42ca828 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01b42ca828 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014bfe1bd0, lowervp=3D0xfffffe014bfe1dc8 vp=3D0xfffffe014bfe1bd0, lowervp=3D0xfffffe014bfe1dc8 vnode vnode 0xfffffe014bf27000: 0xfffffe014bf27000: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014bf27000, lowervp=3D0xfffffe014bf271f8 vp=3D0xfffffe014bf27000, lowervp=3D0xfffffe014bf271f8 vnode vnode 0xfffffe014bf26bd0: 0xfffffe014bf26bd0: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014be0a3a0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014be0a3a0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014bf26bd0, lowervp=3D0xfffffe014bf26dc8 vp=3D0xfffffe014bf26bd0, lowervp=3D0xfffffe014bf26dc8 vnode vnode 0xfffffe014bf267e0: 0xfffffe014bf267e0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014bf267e0, lowervp=3D0xfffffe014bf269d8 vp=3D0xfffffe014bf267e0, lowervp=3D0xfffffe014bf269d8 vnode vnode 0xfffffe014bf263f0: 0xfffffe014bf263f0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014bf263f0, lowervp=3D0xfffffe014bf265e8 vp=3D0xfffffe014bf263f0, lowervp=3D0xfffffe014bf265e8 vnode vnode 0xfffffe014bf5fdc8: 0xfffffe014bf5fdc8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01b42ae1d0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01b42ae1d0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014bf5fdc8, lowervp=3D0xfffffe014bf5fbd0 vp=3D0xfffffe014bf5fdc8, lowervp=3D0xfffffe014bf5fbd0 vnode vnode 0xfffffe014beeddc8: 0xfffffe014beeddc8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014bf700e8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bf700e8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014beeddc8, lowervp=3D0xfffffe014bd981f8 vp=3D0xfffffe014beeddc8, lowervp=3D0xfffffe014bd981f8 vnode vnode 0xfffffe014be037e0: 0xfffffe014be037e0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014bf9c3a0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bf9c3a0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014be037e0, lowervp=3D0xfffffe014bf5f9d8 vp=3D0xfffffe014be037e0, lowervp=3D0xfffffe014bf5f9d8 vnode vnode 0xfffffe014bc0b1f8: 0xfffffe014bc0b1f8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014bf9b9f8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bf9b9f8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014bc0b1f8, lowervp=3D0xfffffe014be8c9d8 vp=3D0xfffffe014bc0b1f8, lowervp=3D0xfffffe014be8c9d8 vnode vnode 0xfffffe014be8c1f8: 0xfffffe014be8c1f8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01b4036cb0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01b4036cb0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014be8c1f8, lowervp=3D0xfffffe014be8c7e0 vp=3D0xfffffe014be8c1f8, lowervp=3D0xfffffe014be8c7e0 vnode vnode 0xfffffe01b423b3f0: 0xfffffe01b423b3f0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014bf70740 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bf70740 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b423b3f0, lowervp=3D0xfffffe014be8c000 vp=3D0xfffffe01b423b3f0, lowervp=3D0xfffffe014be8c000 vnode vnode 0xfffffe014bfe21f8: 0xfffffe014bfe21f8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014bedecb0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bedecb0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014bfe21f8, lowervp=3D0xfffffe014bfe2000 vp=3D0xfffffe014bfe21f8, lowervp=3D0xfffffe014bfe2000 vnode vnode 0xfffffe014b45a5e8: 0xfffffe014b45a5e8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01b4036bc8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01b4036bc8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014b45a5e8, lowervp=3D0xfffffe0036f2bdc8 vp=3D0xfffffe014b45a5e8, lowervp=3D0xfffffe0036f2bdc8 vnode vnode 0xfffffe00366a0dc8: 0xfffffe00366a0dc8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014bf15828 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bf15828 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe00366a0dc8, lowervp=3D0xfffffe00366147e0 vp=3D0xfffffe00366a0dc8, lowervp=3D0xfffffe00366147e0 vnode vnode 0xfffffe0036614dc8: 0xfffffe0036614dc8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01b42441d0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01b42441d0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe0036614dc8, lowervp=3D0xfffffe0036614bd0 vp=3D0xfffffe0036614dc8, lowervp=3D0xfffffe0036614bd0 vnode vnode 0xfffffe014b602bd0: 0xfffffe014b602bd0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014bdd39f8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bdd39f8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014b602bd0, lowervp=3D0xfffffe014bfe25e8 vp=3D0xfffffe014b602bd0, lowervp=3D0xfffffe014bfe25e8 vnode vnode 0xfffffe014b6027e0: 0xfffffe014b6027e0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014bf08ae0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bf08ae0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014b6027e0, lowervp=3D0xfffffe014b6029d8 vp=3D0xfffffe014b6027e0, lowervp=3D0xfffffe014b6029d8 vnode vnode 0xfffffe014b6023f0: 0xfffffe014b6023f0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014bf6f740 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bf6f740 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014b6023f0, lowervp=3D0xfffffe014b6025e8 vp=3D0xfffffe014b6023f0, lowervp=3D0xfffffe014b6025e8 vnode vnode 0xfffffe014b602000: 0xfffffe014b602000: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014befc9f8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014befc9f8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014b602000, lowervp=3D0xfffffe014b6021f8 vp=3D0xfffffe014b602000, lowervp=3D0xfffffe014b6021f8 vnode vnode 0xfffffe01b42b3bd0: 0xfffffe01b42b3bd0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01b4244740 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01b4244740 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b42b3bd0, lowervp=3D0xfffffe01b42b3dc8 vp=3D0xfffffe01b42b3bd0, lowervp=3D0xfffffe01b42b3dc8 vnode vnode 0xfffffe01b42b37e0: 0xfffffe01b42b37e0: tag null, type VREG tag null, type VREG [279/1886] usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014bf15740 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bf15740 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b42b37e0, lowervp=3D0xfffffe01b42b39d8 vp=3D0xfffffe01b42b37e0, lowervp=3D0xfffffe01b42b39d8 vnode vnode 0xfffffe01b42b33f0: 0xfffffe01b42b33f0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014bd21910 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bd21910 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b42b33f0, lowervp=3D0xfffffe01b42b35e8 vp=3D0xfffffe01b42b33f0, lowervp=3D0xfffffe01b42b35e8 vnode vnode 0xfffffe01b42b3000: 0xfffffe01b42b3000: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014bf9dae0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bf9dae0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b42b3000, lowervp=3D0xfffffe01b42b31f8 vp=3D0xfffffe01b42b3000, lowervp=3D0xfffffe01b42b31f8 vnode vnode 0xfffffe01b428bbd0: 0xfffffe01b428bbd0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01b42ae658 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01b42ae658 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b428bbd0, lowervp=3D0xfffffe01b423cdc8 vp=3D0xfffffe01b428bbd0, lowervp=3D0xfffffe01b423cdc8 vnode vnode 0xfffffe01b428b7e0: 0xfffffe01b428b7e0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014bf09ae0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bf09ae0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b428b7e0, lowervp=3D0xfffffe01b428b9d8 vp=3D0xfffffe01b428b7e0, lowervp=3D0xfffffe01b428b9d8 vnode vnode 0xfffffe01b428b3f0: 0xfffffe01b428b3f0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014bef72b8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bef72b8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b428b3f0, lowervp=3D0xfffffe01b428b5e8 vp=3D0xfffffe01b428b3f0, lowervp=3D0xfffffe01b428b5e8 vnode vnode 0xfffffe01b428b000: 0xfffffe01b428b000: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01b4246000 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01b4246000 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b428b000, lowervp=3D0xfffffe01b428b1f8 vp=3D0xfffffe01b428b000, lowervp=3D0xfffffe01b428b1f8 vnode vnode 0xfffffe01b428abd0: 0xfffffe01b428abd0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01b4244488 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01b4244488 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b428abd0, lowervp=3D0xfffffe01b428adc8 vp=3D0xfffffe01b428abd0, lowervp=3D0xfffffe01b428adc8 vnode vnode 0xfffffe01b428a7e0: 0xfffffe01b428a7e0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01b42ae910 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01b42ae910 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b428a7e0, lowervp=3D0xfffffe01b428a9d8 vp=3D0xfffffe01b428a7e0, lowervp=3D0xfffffe01b428a9d8 vnode vnode 0xfffffe01b428a3f0: 0xfffffe01b428a3f0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe0007a31000 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe0007a31000 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b428a3f0, lowervp=3D0xfffffe01b428a5e8 vp=3D0xfffffe01b428a3f0, lowervp=3D0xfffffe01b428a5e8 vnode vnode 0xfffffe01b428a000: 0xfffffe01b428a000: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01b4244570 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01b4244570 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b428a000, lowervp=3D0xfffffe01b428a1f8 vp=3D0xfffffe01b428a000, lowervp=3D0xfffffe01b428a1f8 vnode vnode 0xfffffe01b427fbd0: 0xfffffe01b427fbd0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe0007a30bc8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe0007a30bc8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b427fbd0, lowervp=3D0xfffffe014b602dc8 vp=3D0xfffffe01b427fbd0, lowervp=3D0xfffffe014b602dc8 vnode vnode 0xfffffe01b427f7e0: 0xfffffe01b427f7e0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01b42472b8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01b42472b8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b427f7e0, lowervp=3D0xfffffe01b427f9d8 vp=3D0xfffffe01b427f7e0, lowervp=3D0xfffffe01b427f9d8 vnode vnode 0xfffffe01b427f3f0: 0xfffffe01b427f3f0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01b42ae0e8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01b42ae0e8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b427f3f0, lowervp=3D0xfffffe01b427f5e8 vp=3D0xfffffe01b427f3f0, lowervp=3D0xfffffe01b427f5e8 vnode vnode 0xfffffe01b427f000: 0xfffffe01b427f000: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01b42473a0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01b42473a0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b427f000, lowervp=3D0xfffffe01b427f1f8 vp=3D0xfffffe01b427f000, lowervp=3D0xfffffe01b427f1f8 vnode vnode 0xfffffe01b427ebd0: 0xfffffe01b427ebd0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014bf9cd98 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bf9cd98 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b427ebd0, lowervp=3D0xfffffe01b427edc8 vp=3D0xfffffe01b427ebd0, lowervp=3D0xfffffe01b427edc8 vnode vnode 0xfffffe01b427e7e0: 0xfffffe01b427e7e0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01b42ae000 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01b42ae000 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b427e7e0, lowervp=3D0xfffffe01b427e9d8 vp=3D0xfffffe01b427e7e0, lowervp=3D0xfffffe01b427e9d8 vnode vnode 0xfffffe01b427e3f0: 0xfffffe01b427e3f0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01b42ae570 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01b42ae570 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b427e3f0, lowervp=3D0xfffffe01b427e5e8 vp=3D0xfffffe01b427e3f0, lowervp=3D0xfffffe01b427e5e8 vnode vnode 0xfffffe01b427e000: 0xfffffe01b427e000: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01b42ae9f8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01b42ae9f8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b427e000, lowervp=3D0xfffffe01b427e1f8 vp=3D0xfffffe01b427e000, lowervp=3D0xfffffe01b427e1f8 vnode vnode 0xfffffe014b5cbbd0: 0xfffffe014b5cbbd0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014be0a570 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014be0a570 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014b5cbbd0, lowervp=3D0xfffffe01b428bdc8 vp=3D0xfffffe014b5cbbd0, lowervp=3D0xfffffe01b428bdc8 vnode vnode 0xfffffe014b5cb7e0: 0xfffffe014b5cb7e0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014bf6f910 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bf6f910 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014b5cb7e0, lowervp=3D0xfffffe014b5cb9d8 vp=3D0xfffffe014b5cb7e0, lowervp=3D0xfffffe014b5cb9d8 vnode vnode 0xfffffe014b5cb3f0: 0xfffffe014b5cb3f0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014bedebc8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bedebc8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014b5cb3f0, lowervp=3D0xfffffe014b5cb5e8 vp=3D0xfffffe014b5cb3f0, lowervp=3D0xfffffe014b5cb5e8 vnode vnode 0xfffffe014b5cb000: 0xfffffe014b5cb000: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01b42aebc8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01b42aebc8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014b5cb000, lowervp=3D0xfffffe014b5cb1f8 vp=3D0xfffffe014b5cb000, lowervp=3D0xfffffe014b5cb1f8 vnode vnode 0xfffffe014b5cabd0: 0xfffffe014b5cabd0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01b42ae3a0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01b42ae3a0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014b5cabd0, lowervp=3D0xfffffe014b5cadc8 vp=3D0xfffffe014b5cabd0, lowervp=3D0xfffffe014b5cadc8 vnode vnode 0xfffffe014b5ca7e0: 0xfffffe014b5ca7e0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01b42ae2b8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01b42ae2b8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014b5ca7e0, lowervp=3D0xfffffe014b5ca9d8 vp=3D0xfffffe014b5ca7e0, lowervp=3D0xfffffe014b5ca9d8 vnode vnode 0xfffffe014b5ca3f0: 0xfffffe014b5ca3f0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014bede9f8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bede9f8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014b5ca3f0, lowervp=3D0xfffffe014b5ca5e8 vp=3D0xfffffe014b5ca3f0, lowervp=3D0xfffffe014b5ca5e8 vnode vnode 0xfffffe014b5ca000: 0xfffffe014b5ca000: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014bede000 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bede000 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe014b5ca000, lowervp=3D0xfffffe014b5ca1f8 vp=3D0xfffffe014b5ca000, lowervp=3D0xfffffe014b5ca1f8 vnode vnode 0xfffffe01b42b4bd0: 0xfffffe01b42b4bd0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014bef7000 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bef7000 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b42b4bd0, lowervp=3D0xfffffe01b427fdc8 vp=3D0xfffffe01b42b4bd0, lowervp=3D0xfffffe01b427fdc8 vnode vnode 0xfffffe01b42b47e0: 0xfffffe01b42b47e0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014befdbc8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014befdbc8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b42b47e0, lowervp=3D0xfffffe01b42b49d8 vp=3D0xfffffe01b42b47e0, lowervp=3D0xfffffe01b42b49d8 vnode vnode 0xfffffe01b4e5abd0: 0xfffffe01b4e5abd0: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe014bbf4740 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe014bbf4740 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01b4e5abd0, lowervp=3D0xfffffe014b5c43f0 vp=3D0xfffffe01b4e5abd0, lowervp=3D0xfffffe014b5c43f0 db> > After that, you could try the patch which I posted at winter, but which= > was not tested. I do not know whether it is of any help, and I do need > the debugging information with the patch above before I can make any > conclusions. > > diff --git a/sys/fs/nullfs/null_subr.c b/sys/fs/nullfs/null_subr.c > index fa6c4af..3f74579 100644 > --- a/sys/fs/nullfs/null_subr.c > +++ b/sys/fs/nullfs/null_subr.c > @@ -251,6 +251,7 @@ null_nodeget(mp, lowervp, vpp) > vp->v_type =3D lowervp->v_type; > vp->v_data =3D xp; > vp->v_vnlock =3D lowervp->v_vnlock; > + vp->v_vflag =3D lowervp->v_vflag & VV_ROOT; > error =3D insmntque1(vp, mp, null_insmntque_dtr, xp); > if (error !=3D 0) > return (error); I tested this without the ldvp-debug patch and besides the same ufs/devds LOR nothing else happens with my usual simple end limited test.= Thanks so far, let me know if you want more debug output/testings! -Harry --------------enig09804AF5039DD5A9FD7ABF27 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlPVEGAACgkQLDqVQ9VXb8i6WgCfSw7IXgJVxJTdHSMEPhLwVz+V /ToAoMLFCL+I2xG/b18y3qGWvXd9CJ4E =v3mV -----END PGP SIGNATURE----- --------------enig09804AF5039DD5A9FD7ABF27-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 27 14:50:17 2014 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 ESMTPS id C1C862F0 for ; Sun, 27 Jul 2014 14:50:17 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 535FA22DB for ; Sun, 27 Jul 2014 14:50:17 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s6REoFxY097773; Sun, 27 Jul 2014 16:50:15 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 2B6CA3C7D; Sun, 27 Jul 2014 16:50:15 +0200 (CEST) Message-ID: <53D511A6.4010102@omnilan.de> Date: Sun, 27 Jul 2014 16:50:14 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: panic/lock on 9.3-RELEASE with nullfs/nfs/zfs combination References: <53D12973.3010805@omnilan.de> <20140724165917.GT93733@kib.kiev.ua> <53D1503B.2030200@omnilan.de> <20140724193048.GU93733@kib.kiev.ua> <53D2006C.7090207@omnilan.de> <20140725151448.GY93733@kib.kiev.ua> <53D380B2.2080700@omnilan.de> <20140726114839.GF93733@kib.kiev.ua> <53D5105A.6040204@omnilan.de> In-Reply-To: <53D5105A.6040204@omnilan.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5758C921C65484B103C64573" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Sun, 27 Jul 2014 16:50:15 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 14:50:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5758C921C65484B103C64573 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Harald Schmalzbauer's Nachricht vom 27.07.2014 16:44 (localtime): > =E2=80=A6 >> After that, you could try the patch which I posted at winter, but whic= h >> was not tested. I do not know whether it is of any help, and I do need= >> the debugging information with the patch above before I can make any >> conclusions. >> >> diff --git a/sys/fs/nullfs/null_subr.c b/sys/fs/nullfs/null_subr.c >> index fa6c4af..3f74579 100644 >> --- a/sys/fs/nullfs/null_subr.c >> +++ b/sys/fs/nullfs/null_subr.c >> @@ -251,6 +251,7 @@ null_nodeget(mp, lowervp, vpp) >> vp->v_type =3D lowervp->v_type; >> vp->v_data =3D xp; >> vp->v_vnlock =3D lowervp->v_vnlock; >> + vp->v_vflag =3D lowervp->v_vflag & VV_ROOT; >> error =3D insmntque1(vp, mp, null_insmntque_dtr, xp); >> if (error !=3D 0) >> return (error); > I tested this without the ldvp-debug patch and besides the same > ufs/devds LOR nothing else happens with my usual simple end limited tes= t. One thing to note: With the first rw-open on the nullfs-mount, there's always a almost 1 second dely on an otherwise incredibly responsive machine. That delay happens always after a reboot, and never after first rw-opened any file, regardless if I rw-open the same or a different file on the nullfs-mount. Is that something to worry about? Or a simple reason I can understand? Thanks, -Harry --------------enig5758C921C65484B103C64573 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlPVEaYACgkQLDqVQ9VXb8joEQCcC2bwmlpd7+ZeywOGbKwgNfuf n2EAoKCaK4kDFUHZik8LxyZffE+9YfYs =iArG -----END PGP SIGNATURE----- --------------enig5758C921C65484B103C64573-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 27 17:48:06 2014 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 ESMTPS id A042439E for ; Sun, 27 Jul 2014 17:48:06 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2721721B5 for ; Sun, 27 Jul 2014 17:48:05 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s6RHlvvJ009392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Jul 2014 20:47:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s6RHlvvJ009392 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s6RHlvV1009391; Sun, 27 Jul 2014 20:47:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 27 Jul 2014 20:47:57 +0300 From: Konstantin Belousov To: Harald Schmalzbauer Subject: Re: panic/lock on 9.3-RELEASE with nullfs/nfs/zfs combination Message-ID: <20140727174757.GN93733@kib.kiev.ua> References: <53D12973.3010805@omnilan.de> <20140724165917.GT93733@kib.kiev.ua> <53D1503B.2030200@omnilan.de> <20140724193048.GU93733@kib.kiev.ua> <53D2006C.7090207@omnilan.de> <20140725151448.GY93733@kib.kiev.ua> <53D380B2.2080700@omnilan.de> <20140726114839.GF93733@kib.kiev.ua> <53D5105A.6040204@omnilan.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RSvKN2On5SRY9c4K" Content-Disposition: inline In-Reply-To: <53D5105A.6040204@omnilan.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 17:48:06 -0000 --RSvKN2On5SRY9c4K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 27, 2014 at 04:44:42PM +0200, Harald Schmalzbauer wrote: > Bez??glich Konstantin Belousov's Nachricht vom 26.07.2014 13:48 > (localtime): > I can't emphasize how much I hate my lousy C skills... Got "format '%#x' > expects type 'unsigned int', but argument 3 has type 'u_long' > [-Wformat]" from the compiler and found out that I can't read/understand > any part of your patch; not even the syntax :-( >=20 > After reading printf(3) I change the 3rd additional line into > '("ldvp %p fl %#lx dvp %p fl %#lx flags %#x", ldvp, ldvp->v_vflag,' > ??? A blind man may sometimes hit the mark. This is because the patch was against HEAD, where I changed type of flags to not waste space. It was not merged to stable/9 to keep KBI. > Here's the panic: > panic: ldvp 0xfffffe001bafb000 fl 0x1 dvp 0xfffffe01b4e5a9d8 fl 0 flags > 0x120e144 > vnode vnode 0xfffffe014bc03dc8: 0xfffffe014bc03dc8: tag null, type VDIR > tag null, type VDIR > usecount 1, writecount 0, refcount 1 mountedhere 0 > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags (VV_ROOT|VI_ACTIVE) > flags (VV_ROOT|VI_ACTIVE) > v_object 0xfffffe014bbf4828 ref 0 pages 0 cleanbuf 0 dirtybuf 0 > v_object 0xfffffe014bbf4828 ref 0 pages 0 cleanbuf 0 dirtybuf 0 > lock type zfs: SHARED (count 1) > lock type zfs: SHARED (count 1) > vp=3D0xfffffe014bc03dc8, lowervp=3D0xfffffe001bafb000 > vp=3D0xfffffe014bc03dc8, lowervp=3D0xfffffe001bafb000 So the root vnode for underlying ZFS filesystem somehow managed to get two different upper vnodes for nullfs mount. My guess is that the real problem is due to inconsistent initialization of v_hash for zfs vnodes. It only get set in zfs_vget(), which causes root vnode to have zero hash initially. Please, keep the KASSERT() patch applied, revert the VV_ROOT patch for nullfs, and apply the following change. Then retest. diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c b/= sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c index 04160c6..33748fe 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c @@ -2075,8 +2075,6 @@ zfs_vget(vfs_t *vfsp, ino_t ino, int flags, vnode_t *= *vpp) err =3D vn_lock(*vpp, flags); if (err !=3D 0) *vpp =3D NULL; - else - (*vpp)->v_hash =3D ino; return (err); } =20 diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c b/s= ys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c index ac55996..c8f86b8 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c @@ -1228,9 +1228,10 @@ again: vnode_t *vp =3D ZTOV(zp); =20 err =3D insmntque(vp, zfsvfs->z_vfs); - if (err =3D=3D 0) + if (err =3D=3D 0) { + vp->v_hash =3D obj_num; VOP_UNLOCK(vp, 0); - else { + } else { zp->z_vnode =3D NULL; zfs_znode_dmu_fini(zp); zfs_znode_free(zp); --RSvKN2On5SRY9c4K Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT1TtMAAoJEJDCuSvBvK1BnwIP+wYJdIaUQ17ygpyiWCIpdFly gbSi91GMuQKa+FXwJ3bzJmwo3TELiWnX4NKNHYtaaso1zU5dW+ADh1dzuqX1E/xc iuQ3EDlmw7QkSCQl2R5EKlanG0Bqh5n0uIvJ/OVI+kkIna4KcW38N/xXGb5A1YjK eABkhB1pTWSBpI6emQMBJXabRiRInIDCTl/8uxGAucBBgHjSYmRaWbuiWjHt9dPh aBsmV6qps/mI9M84HxbEGMSYIDp2jZy9SJtAUVqqx1G1aF1taISRAUEc/pTRE1Mz 3ldVZ6DntSsjG4ZjrL/inED8Mcxa+nnn+TnJqigqRLk9PWuIsW87EyUaBVpRjXhk JSeTDjU4zL0SDTUL+VWHlgC+N8nyiEXK5jz13TCatQi6wcuZHcIyQ7Qlt0viifJ5 Low6wOl3FfoIWKF3mSsjrzSH8BlwJKFrOZlOJV8OQzXFUET/CjeXznorD5ZdGrZI ABgZ9DoJVY8aE5nhtwOR4UqURkYBjY5AhrJsqX5ywdXmbSYWTmLUrvFpO3nEj623 GqUaKOaKZJ6MvzrK0F3ADfACblhDBsPAxJt9oyyNQiTKlYcotKgugrRik6yVHlOO 5YdOOKi9ng5UWfY7PGSSI41aXgBc8J/w5ADVl2CJsi0w/Nuyo0wJd9vnzMVkpNLw BbLI7ThP7hqKQohfl70+ =JwIH -----END PGP SIGNATURE----- --RSvKN2On5SRY9c4K-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 27 18:24:28 2014 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 ESMTPS id 9FC22504 for ; Sun, 27 Jul 2014 18:24:28 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0E5C92559 for ; Sun, 27 Jul 2014 18:24:27 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s6RIOOfJ099172; Sun, 27 Jul 2014 20:24:24 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id EB0513CC4; Sun, 27 Jul 2014 20:24:23 +0200 (CEST) Message-ID: <53D543CD.5070607@omnilan.de> Date: Sun, 27 Jul 2014 20:24:13 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: panic/lock on 9.3-RELEASE with nullfs/nfs/zfs combination References: <53D12973.3010805@omnilan.de> <20140724165917.GT93733@kib.kiev.ua> <53D1503B.2030200@omnilan.de> <20140724193048.GU93733@kib.kiev.ua> <53D2006C.7090207@omnilan.de> <20140725151448.GY93733@kib.kiev.ua> <53D380B2.2080700@omnilan.de> <20140726114839.GF93733@kib.kiev.ua> <53D5105A.6040204@omnilan.de> <20140727174757.GN93733@kib.kiev.ua> In-Reply-To: <20140727174757.GN93733@kib.kiev.ua> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4664F2A2DE975AEBDB8A8BA1" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Sun, 27 Jul 2014 20:24:24 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 18:24:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4664F2A2DE975AEBDB8A8BA1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Bez=FCglich Konstantin Belousov's Nachricht vom 27.07.2014 19:47 (localtime): > On Sun, Jul 27, 2014 at 04:44:42PM +0200, Harald Schmalzbauer wrote: >> Bez??glich Konstantin Belousov's Nachricht vom 26.07.2014 13:48 >> (localtime): >> I can't emphasize how much I hate my lousy C skills... Got "format '%#= x' >> expects type 'unsigned int', but argument 3 has type 'u_long' >> [-Wformat]" from the compiler and found out that I can't read/understa= nd >> any part of your patch; not even the syntax :-( >> >> After reading printf(3) I change the 3rd additional line into >> '("ldvp %p fl %#lx dvp %p fl %#lx flags %#x", ldvp, ldvp->v_vflag,' >> ??? A blind man may sometimes hit the mark. > This is because the patch was against HEAD, where I changed type of fla= gs > to not waste space. It was not merged to stable/9 to keep KBI. > >> Here's the panic: >> panic: ldvp 0xfffffe001bafb000 fl 0x1 dvp 0xfffffe01b4e5a9d8 fl 0 flag= s >> 0x120e144 >> vnode vnode 0xfffffe014bc03dc8: 0xfffffe014bc03dc8: tag null, type VDI= R >> tag null, type VDIR >> usecount 1, writecount 0, refcount 1 mountedhere 0 >> usecount 1, writecount 0, refcount 1 mountedhere 0 >> flags (VV_ROOT|VI_ACTIVE) >> flags (VV_ROOT|VI_ACTIVE) >> v_object 0xfffffe014bbf4828 ref 0 pages 0 cleanbuf 0 dirtybuf 0 >> v_object 0xfffffe014bbf4828 ref 0 pages 0 cleanbuf 0 dirtybuf 0 >> lock type zfs: SHARED (count 1) >> lock type zfs: SHARED (count 1) >> vp=3D0xfffffe014bc03dc8, lowervp=3D0xfffffe001bafb000 >> vp=3D0xfffffe014bc03dc8, lowervp=3D0xfffffe001bafb000 > So the root vnode for underlying ZFS filesystem somehow managed to get > two different upper vnodes for nullfs mount. My guess is that the real= > problem is due to inconsistent initialization of v_hash for zfs vnodes.= > It only get set in zfs_vget(), which causes root vnode to have zero > hash initially. > > Please, keep the KASSERT() patch applied, revert the VV_ROOT patch for > nullfs, and apply the following change. Then retest. > > diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.= c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c > index 04160c6..33748fe 100644 > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c > @@ -2075,8 +2075,6 @@ zfs_vget(vfs_t *vfsp, ino_t ino, int flags, vnode= _t **vpp) > err =3D vn_lock(*vpp, flags); > if (err !=3D 0) > *vpp =3D NULL; > - else > - (*vpp)->v_hash =3D ino; > return (err); > } > =20 > diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c= b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c > index ac55996..c8f86b8 100644 > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c > @@ -1228,9 +1228,10 @@ again: > vnode_t *vp =3D ZTOV(zp); > =20 > err =3D insmntque(vp, zfsvfs->z_vfs); > - if (err =3D=3D 0) > + if (err =3D=3D 0) { > + vp->v_hash =3D obj_num; > VOP_UNLOCK(vp, 0); > - else { > + } else { > zp->z_vnode =3D NULL; > zfs_znode_dmu_fini(zp); > zfs_znode_free(zp); Applyed these two patches along with the KASSERT patch (reverted ROOT_VV) and did the same simple test: No panic, no debug message. So this also fixes my limited and simple test case. Tell me if I can provide anything else, I'll keep that latest patched version running, tomorrow will be regular usage and I'll report again. Thanks, -Harry --------------enig4664F2A2DE975AEBDB8A8BA1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlPVQ9cACgkQLDqVQ9VXb8i7pwCgwLh6wpYiMbtrSnfafr49oriK GCcAn2YHfWAAIj53g0Zr2VIUiNJ+Link =KGgb -----END PGP SIGNATURE----- --------------enig4664F2A2DE975AEBDB8A8BA1-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 27 18:29:09 2014 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 ESMTPS id B4E93627 for ; Sun, 27 Jul 2014 18:29:09 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 569562579 for ; Sun, 27 Jul 2014 18:29:09 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s6RIT484018641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Jul 2014 21:29:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s6RIT484018641 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s6RIT4xr018640; Sun, 27 Jul 2014 21:29:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 27 Jul 2014 21:29:04 +0300 From: Konstantin Belousov To: Harald Schmalzbauer Subject: Re: panic/lock on 9.3-RELEASE with nullfs/nfs/zfs combination Message-ID: <20140727182904.GO93733@kib.kiev.ua> References: <20140724165917.GT93733@kib.kiev.ua> <53D1503B.2030200@omnilan.de> <20140724193048.GU93733@kib.kiev.ua> <53D2006C.7090207@omnilan.de> <20140725151448.GY93733@kib.kiev.ua> <53D380B2.2080700@omnilan.de> <20140726114839.GF93733@kib.kiev.ua> <53D5105A.6040204@omnilan.de> <20140727174757.GN93733@kib.kiev.ua> <53D543CD.5070607@omnilan.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="swBRKU+0+VRhVQHB" Content-Disposition: inline In-Reply-To: <53D543CD.5070607@omnilan.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 18:29:09 -0000 --swBRKU+0+VRhVQHB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 27, 2014 at 08:24:13PM +0200, Harald Schmalzbauer wrote: > Bez?glich Konstantin Belousov's Nachricht vom 27.07.2014 19:47 > (localtime): > > On Sun, Jul 27, 2014 at 04:44:42PM +0200, Harald Schmalzbauer wrote: > >> Bez??glich Konstantin Belousov's Nachricht vom 26.07.2014 13:48 > >> (localtime): > >> I can't emphasize how much I hate my lousy C skills... Got "format '%#= x' > >> expects type 'unsigned int', but argument 3 has type 'u_long' > >> [-Wformat]" from the compiler and found out that I can't read/understa= nd > >> any part of your patch; not even the syntax :-( > >> > >> After reading printf(3) I change the 3rd additional line into > >> '("ldvp %p fl %#lx dvp %p fl %#lx flags %#x", ldvp, ldvp->v_vflag,' > >> ??? A blind man may sometimes hit the mark. > > This is because the patch was against HEAD, where I changed type of fla= gs > > to not waste space. It was not merged to stable/9 to keep KBI. > > > >> Here's the panic: > >> panic: ldvp 0xfffffe001bafb000 fl 0x1 dvp 0xfffffe01b4e5a9d8 fl 0 flags > >> 0x120e144 > >> vnode vnode 0xfffffe014bc03dc8: 0xfffffe014bc03dc8: tag null, type VDIR > >> tag null, type VDIR > >> usecount 1, writecount 0, refcount 1 mountedhere 0 > >> usecount 1, writecount 0, refcount 1 mountedhere 0 > >> flags (VV_ROOT|VI_ACTIVE) > >> flags (VV_ROOT|VI_ACTIVE) > >> v_object 0xfffffe014bbf4828 ref 0 pages 0 cleanbuf 0 dirtybuf 0 > >> v_object 0xfffffe014bbf4828 ref 0 pages 0 cleanbuf 0 dirtybuf 0 > >> lock type zfs: SHARED (count 1) > >> lock type zfs: SHARED (count 1) > >> vp=3D0xfffffe014bc03dc8, lowervp=3D0xfffffe001bafb000 > >> vp=3D0xfffffe014bc03dc8, lowervp=3D0xfffffe001bafb000 > > So the root vnode for underlying ZFS filesystem somehow managed to get > > two different upper vnodes for nullfs mount. My guess is that the real > > problem is due to inconsistent initialization of v_hash for zfs vnodes. > > It only get set in zfs_vget(), which causes root vnode to have zero > > hash initially. > > > > Please, keep the KASSERT() patch applied, revert the VV_ROOT patch for > > nullfs, and apply the following change. Then retest. > > > > diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.= c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c > > index 04160c6..33748fe 100644 > > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c > > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c > > @@ -2075,8 +2075,6 @@ zfs_vget(vfs_t *vfsp, ino_t ino, int flags, vnode= _t **vpp) > > err =3D vn_lock(*vpp, flags); > > if (err !=3D 0) > > *vpp =3D NULL; > > - else > > - (*vpp)->v_hash =3D ino; > > return (err); > > } > > =20 > > diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c= b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c > > index ac55996..c8f86b8 100644 > > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c > > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c > > @@ -1228,9 +1228,10 @@ again: > > vnode_t *vp =3D ZTOV(zp); > > =20 > > err =3D insmntque(vp, zfsvfs->z_vfs); > > - if (err =3D=3D 0) > > + if (err =3D=3D 0) { > > + vp->v_hash =3D obj_num; > > VOP_UNLOCK(vp, 0); > > - else { > > + } else { > > zp->z_vnode =3D NULL; > > zfs_znode_dmu_fini(zp); > > zfs_znode_free(zp); >=20 > Applyed these two patches along with the KASSERT patch (reverted > ROOT_VV) and did the same simple test: No panic, no debug message. So > this also fixes my limited and simple test case. Great, I believe that zfs patch fixes the root cause of the problem. Thank you for the testing. >=20 > Tell me if I can provide anything else, I'll keep that latest patched > version running, tomorrow will be regular usage and I'll report again. >=20 > Thanks, >=20 > -Harry >=20 --swBRKU+0+VRhVQHB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT1UTvAAoJEJDCuSvBvK1Bw/kP/3fFSdNYRmwzN2+aYpTTM7M0 J/gXRv08LY67mzvIJfxcoeTu0JyJoOlU0369H/DVspR1bvjGiD7mXvCT/Y1x4RnG ZUs8TbQxBt6O/WcqDRh1G/cnVj5v19PaUKRGY9/zciVcAJWk5T8LaKtz6coNYZtY drxuJtNI34t2QTfUS+B0/cIC16gNvRv32sJMJyTkvpFUboeEnyW8moFw16XUhabl aCSOAyFAMrTe3D5+bFCqo0HWNTd23eJ0ZwvLPBCadQkCWtVNBBrFBXVfRpSwMjyV WbwuK5YeQOfY4E5wliVkFfwub2PNifzQQ+M7hNM1n7SVnaFmYNrEy/PCzjjcRl3w gh2MwIZ/VjUI/5CBECTLPVVRrYn4+UTbtNHq8rSSNqC2uhSFNKXiVawezsZdkw2t qizDTnEWOeTIEZ9SVo7XhAJf077ixBSrRx9pxIsBVLhdMYuW9k3husiU12R+8NsI yOPZ7IYbtXRYPgzl35Ou2Q2lAvxsVtiWwOOwg2KDr8fTetT8c7n0jXY/oiKYfbtZ Ob1i90nJNMoBWfGjyHpY0/jaKqAyDDzIVYoWa862azavLa4UpRb6JJhNSh3tG7Pp D5qdLPG4Q5fJILmk6wB8dAEtMahX9vHbdln42f6hvkNvi1TJUz/kng6WXUsiU3Sr AdmiUafgvISbDQyCchYB =MQD3 -----END PGP SIGNATURE----- --swBRKU+0+VRhVQHB-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 27 19:20:01 2014 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 ESMTPS id 8890C1C4 for ; Sun, 27 Jul 2014 19:20:01 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0507B29E3 for ; Sun, 27 Jul 2014 19:20:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id s6RJJmfT076274 for ; Sun, 27 Jul 2014 23:19:48 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Sun, 27 Jul 2014 23:19:48 +0400 (MSK) From: Dmitry Morozovsky To: freebsd-stable@freebsd.org Subject: Re: restore: bad block size 5632 between different major versions In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Sun, 27 Jul 2014 23:19:48 +0400 (MSK) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 19:20:01 -0000 Colleagues, following up to myself: On Thu, 24 Jul 2014, Dmitry Morozovsky wrote: > I'm a bit stumbled. > > prerequisites: > > - backup server, stable/9 (a bit obsoleted, but this is unrelated to the > problem) I forgot to mention that it is ZFS-based. > ** on backup server: > backup@whale:/B/dump/lion> uname -r > 9.1-STABLE > backup@whale:/B/dump/lion> cat 5-var.dgz.?? | zcat | ./restore -t -v -f - > Verify tape and initialize maps > Dump date: Thu Jul 24 06:57:04 2014 > Dumped from: Wed Jul 23 06:57:04 2014 > Level 5 dump of /var on lion.rinet.ru:/dev/da0e > Label: none > bad block size 5632 ktrace'ing restore I've found that stat(".") on ZFS in my case returning blksize=5632, which makes restore unhappy somewhere at 261- if (stbuf.st_blksize >= TP_BSIZE && stbuf.st_blksize <= MAXBSIZE) 262- fssize = stbuf.st_blksize; 263- if (((fssize - 1) & fssize) != 0) { 264: fprintf(stderr, "bad block size %ld\n", fssize); 265- done(1); 266- } commenting lines 263-266 gives me working restore. Any hints from now? It's not clear to me why we check this at all? Thanks! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Sun Jul 27 20:25:43 2014 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 ESMTPS id BD66E667 for ; Sun, 27 Jul 2014 20:25:43 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 386DD24A5 for ; Sun, 27 Jul 2014 20:25:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id s6RKPdkJ076919; Mon, 28 Jul 2014 00:25:40 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Mon, 28 Jul 2014 00:25:39 +0400 (MSK) From: Dmitry Morozovsky To: Dave Hayes Subject: Re: Gmirror + gpart corruption on 9.3-PRE In-Reply-To: <53D2E560.5090100@jetcafe.org> Message-ID: References: <53D1BDB2.7030906@jetcafe.org> <53D2E560.5090100@jetcafe.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Mon, 28 Jul 2014 00:25:40 +0400 (MSK) Cc: Warren Block , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 20:25:43 -0000 On Fri, 25 Jul 2014, Dave Hayes wrote: > > > At 9.3-PRERELEASE #0 r268066M I've been trying unsucessfuly to set up > > > a brand shiny new gmirror + gpt style Raid 0 mirror using the > > > following procedure on a disk > > > > > > gpart create -s gpt ada0 > > > ( shows 931G of space) > > > gpart add -s 96G -t freebsd-swap -l swap0 ada0 > > > gpart add -t freebsd-ufs -l rw0 ada0 > > > gpart create -s gpt ada1 > > > gpart add -s 96G -t freebsd-swap -l swap1 ada1 > > > gpart add -t freebsd-ufs -l rw1 ada1 > > > gmirror label swap /dev/ada0p1 /dev/ada1p1 > > > gmirror label rw /dev/ada0p2 /dev/ada1p2 > > I need to be clearer. Above is the point at which the corrupt table message is > encountered. I believe the above is the equivalent of your method, and hence > your method may not work on 9.3-PRE and above. If you happen to be able to > test this, I'd be curious as to the results. > > I'm going to try gmirroring the entire disk and and using BSD labels for > separate partitions. I think this will have the effect I want, and it's worth > a test. ... or, possibly better, you could mark both your disks with gpart partitioning (maybe using -a1m to both align partitions and make them let some free gap at the end of disks), and then just gmirror partitions, as you did before. Or, did I miss something? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 07:27:46 2014 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 ESMTPS id EB3FBA80 for ; Mon, 28 Jul 2014 07:27:46 +0000 (UTC) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E8E628C8 for ; Mon, 28 Jul 2014 07:27:45 +0000 (UTC) Received: from hugo10.ka.punkt.de ([217.29.45.10]) by gate2.intern.punkt.de with ESMTP id s6S7Rbm4074864; Mon, 28 Jul 2014 09:27:37 +0200 (CEST) Received: from hausen-mbp.intern.punkt.de (hausen-mbp.intern.punkt.de [217.29.45.110] (may be forged)) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id s6S7RbWh028092; Mon, 28 Jul 2014 09:27:37 +0200 (CEST) (envelope-from hausen@punkt.de) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Gmirror + gpart corruption on 9.3-PRE From: "Patrick M. Hausen" In-Reply-To: Date: Mon, 28 Jul 2014 09:27:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <116A9F89-3C09-4C00-91F4-2776BBAE146B@punkt.de> References: <53D1BDB2.7030906@jetcafe.org> <53D1DD47.4040403@jetcafe.org> To: Warren Block X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 07:27:47 -0000 Hi, all, Am 25.07.2014 um 15:45 schrieb Warren Block : > On Fri, 25 Jul 2014, Patrick M. Hausen wrote: >=20 >> Am 25.07.2014 um 07:34 schrieb Warren Block : >>> True. But partitioning can be specific to the drive. It's not like = GPT-partitioned drives can be copied with dd (well, not correctly). >>=20 >> Errrr ... sorry, but ... could you please elaborate on that? Up until = now I was sure that any drive could be >> copied with dd(1). >>=20 >> Puzzled. :-) >=20 > GPT partitioning puts a primary partition table at the beginning of = the drive, and a backup partition table at the end of the drive. Thanks. I knew that. Never assume ... as usual. Of course I was thinking = "same sized disks", so your comment really made me wonder if there was anything as pervert as disk serial = numbers or other UUIDs in the partition information that would not work when copied blockwise. Best regards Patrick --=20 punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J=FCrgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 10:20:41 2014 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 ESMTPS id 4DDAC273 for ; Mon, 28 Jul 2014 10:20:41 +0000 (UTC) Received: from nm14-vm0.bullet.mail.bf1.yahoo.com (nm14-vm0.bullet.mail.bf1.yahoo.com [98.139.213.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 043652034 for ; Mon, 28 Jul 2014 10:20:40 +0000 (UTC) Received: from [98.139.215.141] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 28 Jul 2014 10:17:51 -0000 Received: from [98.139.212.238] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 28 Jul 2014 10:17:51 -0000 Received: from [127.0.0.1] by omp1047.mail.bf1.yahoo.com with NNFMP; 28 Jul 2014 10:17:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 68369.90208.bm@omp1047.mail.bf1.yahoo.com Received: (qmail 29984 invoked by uid 60001); 28 Jul 2014 10:17:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1406542670; bh=V5V4jM+WHZJENKTADdhycpa8mm8HqY3DcvEBMu7bj2o=; h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=pH5ue6UNwH7RQ+UQfkStmfk4+Kmt3f7Xo40BSl+XU+V55DGD7sNU9A/EYmf/P9MR0csVkHZz6mLNSoontQuv4x7VzgBHUMKp/F9w4XJ+SXQvx/A0NGJsPVhgr/9tqlkCX4NwJj09dl1bXgYK/6F6zPHafG1EYbFqwLJooA+92uE= X-YMail-OSG: jt4mRFcVM1k8YNPhD6agzelbQcOxBN.1MP2aEWr7PbxC3zF 2GpuifnnBDg7bUX7Hg7h8RKGKFlu11YIbxjXPHM6Llj5e9C9cxVu2lpRVVq2 Y3AYQrybqfPgKA4S_OA5NVLWIsla9GFkN4fkz18Ph5VcEgNbmjQBKKewixZn 2esKTWMXCVq5JjNP0MDY089P3rqjuvzCLF1HkCkEi3YF7hT540jssL8pXrlQ jKvOqVgwYz1xP4KybPIeV0d26_nzc2su2UPNaJeVgNtzWNK.93KfZuY8bMtG .XzNm97SnYqJxbN8F8awS0VtBmYRtFode.i0XXQUMlCvMI7g7CMg7fKvf6r3 ezt1EenepBpXBH5IeRF6WQSaXf0nMzXfRsnXj_92X1lrmAAk1uG8ahGXXiAh VvZaR_4XUa1bgk.xio3XbrzVHszwITD97oHtwEX50sr7GmQt7Npyt71QZ1No Z8eBaSjzW0Xy5KTPjmfuP_2p4FZ0DVzKztY4OidwPP_bFUs5ycN7MKdF2vgq UQDPIKjKUYt9S2RRBt62k1OPsQHKGdIRpEORs.CEk2bWgoepx5w-- Received: from [87.11.40.37] by web140906.mail.bf1.yahoo.com via HTTP; Mon, 28 Jul 2014 03:17:50 PDT X-Rocket-MIMEInfo: 002.001, SSBlbmNsb3NlIGRldGFpbHMgb2YgbXkgc3lzdGVtIGFuZCBwcm9ibGVtIHdpdGggaXRhbGlhbiBrZXlib2FyZDoKCkNvcHlyaWdodCAoYykgMTk5Mi0yMDE0IFRoZSBGcmVlQlNEIFByb2plY3QuCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NArCoMKgwqDCoMKgwqDCoCBUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.196.685 Message-ID: <1406542670.84373.YahooMailNeo@web140906.mail.bf1.yahoo.com> Date: Mon, 28 Jul 2014 03:17:50 -0700 From: Filippo Moretti Reply-To: Filippo Moretti Subject: Problem with italian keyboard To: "stable@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 10:20:41 -0000 I enclose details of my system and problem with italian keyboard:=0A=0ACopy= right (c) 1992-2014 The FreeBSD Project.=0ACopyright (c) 1979, 1980, 1983, = 1986, 1988, 1989, 1991, 1992, 1993, 1994=0A=A0=A0=A0=A0=A0=A0=A0 The Regent= s of the University of California. All rights reserved.=0AFreeBSD is a regi= stered trademark of The FreeBSD Foundation.=0AFreeBSD 10.0-STABLE #7 r26915= 2: Sun Jul 27 18:04:39 CEST 2014=0A=A0=A0=A0 root@sting:/usr/obj/usr/src/sy= s/STING_VT i386=0AFreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 2= 08032) 20140512=0AVT: running with driver "vga".=0ACPU: Intel(R) Pentium(R)= 4 CPU 3.20GHz (3200.04-MHz 686-class CPU)=0A=A0 Origin =3D "GenuineIntel"= =A0 Id =3D 0xf41=A0 Family =3D 0xf=A0 Model =3D 0x4=A0 Stepping =3D 1=0A=A0= Features=3D0xbfebfbff=0A=A0= Features2=3D0x441d=0A=A0 AMD Features= =3D0x100000=0A=A0 TSC: P-state invariant=0Areal memory=A0 =3D 429496729= 6 (4096 MB)=0Aavail memory =3D 3016171520 (2876 MB)=0AEvent timer "LAPIC" q= uality 400=0AACPI APIC Table: =0AFreeBSD/SMP: Multiproce= ssor System Detected: 2 CPUs=0AFreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HT= T threads=0A=A0cpu0 (BSP): APIC ID:=A0 0=0A=A0cpu1 (AP/HT): APIC ID:=A0 1= =0A=0A=0A=0A=0AConfiguring syscons: keymapkbdcontrol: keymap file "it.iso.k= bd" not found: No such file or directory=0Ahowever there is it.iso.kbd in /= usr/share/syscons/keymaps=0Aany suggestion appreciated=0AFilippo=0Athis beh= aviour started from july the world of july 5 and did not disppear on july 2= 7=0AFilippo=0A From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 11:20:34 2014 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 ESMTPS id C3648602 for ; Mon, 28 Jul 2014 11:20:34 +0000 (UTC) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5061D2788 for ; Mon, 28 Jul 2014 11:20:34 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id pv20so5355242lab.15 for ; Mon, 28 Jul 2014 04:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w46LKi+FT5zZKf+aXk7M+mWvu3ve5FWHUbD6G83DYdI=; b=TPp+4mUSbpu/aZ5i3dPZB8yMOUwZT4zBJzIBLeYxEeDADQPFtxB+2XBaSWK81rmojC Rkbt9a21pnv0a23unId9Lwu+sjBOtgUxckuWlC921FKjM/Ad5FtWIDLkhTTw1xAmWhCx BakHnw4cDML144OMo/SFtIXaJZIPRl6KPf+hqD+pyHcxCyle2WhPhWjT5AnkNtKxptKh DOS+VzeepDZyI9lYds9bcPC9dHonP33uMqPw/gHVRLvtqIaaUfHce5hhWoYiL00hCrsx FrMFIJQUl93uh3i3F7EZmgxnWGB5DnXWgESOtE1QNdOAD5QyBCqGckFnik4gTKQUu7Vv pDYg== MIME-Version: 1.0 X-Received: by 10.112.154.134 with SMTP id vo6mr2421361lbb.92.1406546432077; Mon, 28 Jul 2014 04:20:32 -0700 (PDT) Received: by 10.112.137.70 with HTTP; Mon, 28 Jul 2014 04:20:32 -0700 (PDT) In-Reply-To: <1406542670.84373.YahooMailNeo@web140906.mail.bf1.yahoo.com> References: <1406542670.84373.YahooMailNeo@web140906.mail.bf1.yahoo.com> Date: Mon, 28 Jul 2014 12:20:32 +0100 Message-ID: Subject: Re: Problem with italian keyboard From: Tom Evans To: Filippo Moretti Content-Type: text/plain; charset=UTF-8 Cc: "stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 11:20:34 -0000 On Mon, Jul 28, 2014 at 11:17 AM, Filippo Moretti via freebsd-stable wrote: > I enclose details of my system and problem with italian keyboard: > > Copyright (c) 1992-2014 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 10.0-STABLE #7 r269152: Sun Jul 27 18:04:39 CEST 2014 > root@sting:/usr/obj/usr/src/sys/STING_VT i386 VT kernel. > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 > VT: running with driver "vga". > CPU: Intel(R) Pentium(R) 4 CPU 3.20GHz (3200.04-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf41 Family = 0xf Model = 0x4 Stepping = 1 > Features=0xbfebfbff > Features2=0x441d > AMD Features=0x100000 > TSC: P-state invariant > real memory = 4294967296 (4096 MB) > avail memory = 3016171520 (2876 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads > cpu0 (BSP): APIC ID: 0 > cpu1 (AP/HT): APIC ID: 1 > > > > > Configuring syscons: keymapkbdcontrol: keymap file "it.iso.kbd" not found: No such file or directory > however there is it.iso.kbd in /usr/share/syscons/keymaps You need to convert this and put it in /usr/share/vt/keymaps since you are no longer using syscons. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 12:17:22 2014 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 ESMTPS id 70101797; Mon, 28 Jul 2014 12:17:22 +0000 (UTC) Received: from mailout11.t-online.de (mailout11.t-online.de [194.25.134.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C119A20A3; Mon, 28 Jul 2014 12:17:21 +0000 (UTC) Received: from fwd41.aul.t-online.de (fwd41.aul.t-online.de [172.20.27.139]) by mailout11.t-online.de (Postfix) with SMTP id 72AF45F1D6D; Mon, 28 Jul 2014 14:07:23 +0200 (CEST) Received: from [192.168.119.26] (TltQOyZDQhRHosx-nJsctVTustlYxwHZ60RWAzqT7-SBMzxRkvbiUPqp-lbm2qUQl9@[84.154.101.219]) by fwd41.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XBjhy-3eLRwG0; Mon, 28 Jul 2014 14:07:14 +0200 Message-ID: <53D63CEE.2010106@freebsd.org> Date: Mon, 28 Jul 2014 14:07:10 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Filippo Moretti Subject: Re: Problem with italian keyboard References: <1406542670.84373.YahooMailNeo@web140906.mail.bf1.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ID: TltQOyZDQhRHosx-nJsctVTustlYxwHZ60RWAzqT7-SBMzxRkvbiUPqp-lbm2qUQl9 X-TOI-MSGID: 6d44082e-3d3d-46af-a696-85804c3d7400 Cc: Tom Evans , "stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 12:17:22 -0000 Am 28.07.2014 um 13:20 schrieb Tom Evans: > On Mon, Jul 28, 2014 at 11:17 AM, Filippo Moretti via freebsd-stable >> Configuring syscons: keymapkbdcontrol: keymap file "it.iso.kbd" not found: No such file or directory >> however there is it.iso.kbd in /usr/share/syscons/keymaps > > You need to convert this and put it in /usr/share/vt/keymaps since you > are no longer using syscons. For LATIN encodings (e.g. ISO8859-1) no conversion is required (the result of the conversion is identical to the file for syscons). You can copy over the file from /usr/share/syscons/keymaps/ to /usr/share/vt/keymaps/, or you can put the full path to the keymap file into rc.conf (or use it on the command line). I think we should have a working solution in the upcoming FreeBSD-10.1. Since the keymaps for LATIN encodings are compatible between syscons and newcons, they could be installed into both places, syscons/keymaps and vt/keymaps. Alternatively, kbdcontrol could use the syscons/keymaps directory as a fallback for keymaps not found in vt/keymaps. This work-around is currently active in -CURRENT, since there are only 3 converted keymap files in vt/keymaps and everybody trying out newcons has the same problem. Regards, STefan From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 12:33:08 2014 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 ESMTPS id 60C65C9F for ; Mon, 28 Jul 2014 12:33:08 +0000 (UTC) Received: from nm32-vm1.bullet.mail.bf1.yahoo.com (nm32-vm1.bullet.mail.bf1.yahoo.com [72.30.239.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 144AF225F for ; Mon, 28 Jul 2014 12:33:07 +0000 (UTC) Received: from [98.139.215.140] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 28 Jul 2014 12:29:39 -0000 Received: from [98.139.212.250] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 28 Jul 2014 12:29:39 -0000 Received: from [127.0.0.1] by omp1059.mail.bf1.yahoo.com with NNFMP; 28 Jul 2014 12:29:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 759864.45479.bm@omp1059.mail.bf1.yahoo.com Received: (qmail 1058 invoked by uid 60001); 28 Jul 2014 12:29:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1406550579; bh=ZeUKi1hDRXEtiQbXFaXa4ASNsjcCEYgyOn8aaNrSQXk=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=oLNT8bdZ880LlLTv2nojo+7Fa2wWPLJG6jhB1mLzzF8vg+WW0b5ZaVZBlgwvYHSo6U9xkcIVy0/RXhgQi4yj9mt9Qz/eVqulJ/i9TIdfYwiQpb1CzSmjeWMyl7sr8tSXYndMkRhLqvmbjTJ2c5Qhn2FL46KJkljcpHlWsKknHcM= X-YMail-OSG: 3ehTj4sVM1ljm5Mpqam0DO7hwIFptuHuo_z07TXuzus0CZx EZVldJ7QH46_Z.7tFKN4xbq6lnr9GPpDuuVBOppDARWtyLnNP6O_P5lgV9Qc LaJ3BpQJWvmcTrY0EyUSg5qM3fn5Yq4Yhx8QcNpebKfT1YTpP82kg_UwUfU3 jp2Ydyw6QG9RrgVouBhZBHJAJuOrckKKvqDkiWQjEk6lmc6gQIwPQkC1u7PL g7YmNkOEp_eH.qnUhQSa_JSp9.lk7x8gRNrIFamH4U9ovQ26ZpDvOb2_uAOr OkSqhQ2VbvOzpYrKknHBK9PYkjx2Xbud9twzgLzenB0A.s4mQ2E2z0Jg.iTP ETnZZp0qhgqk0icQoFig31YSpWpsfB9KdToKg8DTfooeDCBvWOnhGTfGRKdm U6t3tgxwT0ZMK8dPTKGyvuDcYvErqnnAkVH0BzuuE9eZMksvsFIilomNxS47 fIG9FKPpJnXCgX78w3AiSheg49sfjJ.YnAzqxkJqm30po29AOfTRrWMdy4i0 aW02C5jsk6i3Q_M4JSThgCQ4eYjU.JZEY0MzaBwTLRi_B Received: from [87.11.40.37] by web140904.mail.bf1.yahoo.com via HTTP; Mon, 28 Jul 2014 05:29:39 PDT X-Rocket-MIMEInfo: 002.001, SSByYW4ga2JkbWFwIC1sIGFuZCBub3cgaXMgd29ya2luZyBwcm9wZXJseQp0aGFuayB5b3UKRmlsaXBwbwoKCgpPbiBNb25kYXksIEp1bHkgMjgsIDIwMTQgMjoxNyBQTSwgU3RlZmFuIEVzc2VyIDxzZUBmcmVlYnNkLm9yZz4gd3JvdGU6CiAKCgpBbSAyOC4wNy4yMDE0IHVtIDEzOjIwIHNjaHJpZWIgVG9tIEV2YW5zOgo.IE9uIE1vbiwgSnVsIDI4LCAyMDE0IGF0IDExOjE3IEFNLCBGaWxpcHBvIE1vcmV0dGkgdmlhIGZyZWVic2Qtc3RhYmxlCj4.IENvbmZpZ3VyaW5nIHN5c2NvbnM6IGtleW1hcGtiZGNvbnQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.196.685 References: <1406542670.84373.YahooMailNeo@web140906.mail.bf1.yahoo.com> <53D63CEE.2010106@freebsd.org> Message-ID: <1406550579.20496.YahooMailNeo@web140904.mail.bf1.yahoo.com> Date: Mon, 28 Jul 2014 05:29:39 -0700 From: Filippo Moretti Reply-To: Filippo Moretti Subject: Re: Problem with italian keyboard To: Stefan Esser In-Reply-To: <53D63CEE.2010106@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Tom Evans , "stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 12:33:08 -0000 I ran kbdmap -l and now is working properly=0Athank you=0AFilippo=0A=0A=0A= =0AOn Monday, July 28, 2014 2:17 PM, Stefan Esser wrote:= =0A =0A=0A=0AAm 28.07.2014 um 13:20 schrieb Tom Evans:=0A> On Mon, Jul 28, = 2014 at 11:17 AM, Filippo Moretti via freebsd-stable=0A>> Configuring sysco= ns: keymapkbdcontrol: keymap file "it.iso.kbd" not found: No such file or d= irectory=0A>> however there is it.iso.kbd in /usr/share/syscons/keymaps=0A>= =0A> You need to convert this and put it in /usr/share/vt/keymaps since yo= u=0A> are no longer using syscons.=0A=0AFor LATIN encodings (e.g. ISO8859-1= ) no conversion is required=0A(the result of the conversion is identical to= the file for=0Asyscons).=0A=0AYou can copy over the file from /usr/share/s= yscons/keymaps/ to=0A/usr/share/vt/keymaps/, or you can put the full path t= o the=0Akeymap file into rc.conf (or use it on the command line).=0A=0AI th= ink we should have a working solution in the upcoming=0AFreeBSD-10.1.=0A=0A= Since the keymaps for LATIN encodings are compatible between=0Asyscons and = newcons, they could be=A0 installed into both places,=0Asyscons/keymaps and= vt/keymaps.=0A=0AAlternatively, kbdcontrol could use the syscons/keymaps= =0Adirectory as a fallback for keymaps not found in vt/keymaps.=0AThis work= -around is currently active in -CURRENT, since there=0Aare only 3 converted= keymap files in vt/keymaps and everybody=0Atrying out newcons has the same= problem.=0A=0ARegards, STefan=0A=0A_______________________________________= ________=0Afreebsd-stable@freebsd.org mailing list=0Ahttp://lists.freebsd.o= rg/mailman/listinfo/freebsd-stable=0ATo unsubscribe, send any mail to "free= bsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 16:07:54 2014 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 ESMTPS id 25BEDD8B; Mon, 28 Jul 2014 16:07:54 +0000 (UTC) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E15602D2A; Mon, 28 Jul 2014 16:07:53 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id eu11so10823196pac.3 for ; Mon, 28 Jul 2014 09:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yp5TauZv/+AhYnH+GsFaMbC9qs/9wQRw8Ft61+mJ6P8=; b=Jb7e0vB/GKvrwCNcf5/UMGOYBgmUDRRx4C92P46hVH6s4FsxcZK9VdcmcquMYG9n+L xXByVP3HVvukKwurdbjo+zoKR3F1jUW8vA4CZjx5TycTBczjFJ0jkNEc2wdFv2nfIzTP tahWLTY/D91bsFnurUkXaFQRvHe5NA5JX7C0zD6qba0Hx5PPt30qnA2rHn+V/krdzCYe +XYdjInpZrTo/m3UocxgNEEgun2nOC0CZfNkBRHtVxmmm57J2na/zWdUqWHDoBDhzj6n M1i6G6OW4v80RvmmboF7dlF26r5lEXRz/yrukjky6hFSdIhWeZ2cQpCjya9zUETMJ2Do RYUg== X-Received: by 10.69.2.35 with SMTP id bl3mr39230690pbd.83.1406563673502; Mon, 28 Jul 2014 09:07:53 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:9cc1:8b97:b7d9:aa45? ([2601:8:ab80:7d6:9cc1:8b97:b7d9:aa45]) by mx.google.com with ESMTPSA id gb1sm18071177pbd.76.2014.07.28.09.07.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 09:07:52 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [REGRESSION] Root zpool mounting broken between 06/30/2013 and 07/21/2013 when PS/2 support compiled into the kernel From: Garrett Cooper In-Reply-To: Date: Mon, 28 Jul 2014 09:07:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3BFFF901-F5C0-4079-834E-F3199A188EF8@gmail.com> References: <78424E5D-4EB2-4462-A190-D0AC97136790@gmail.com> <201307221208.22060.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-fs@freebsd.org" , "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 16:07:54 -0000 On Jul 22, 2013, at 10:58 AM, Garrett Cooper = wrote: > On Jul 22, 2013, at 9:08 AM, John Baldwin wrote: >=20 >> On Monday, July 22, 2013 10:30:32 am Garrett Cooper wrote: >>> I have a KERNCONF that previously had PS/2 support compiled into the = kernel. If I comment out the following lines like so: >>>=20 >>> # atkbdc0 controls both the keyboard and the PS/2 mouse >>> #device atkbdc # AT keyboard controller >>> #device atkbd # AT keyboard >>>=20 >>> then I'm able to mount root again (it was failing with ENOXDEV). >>>=20 >>> The working kernel was as follows: >>>=20 >>> $ strings /boot/kernel.WORKING/kernel | grep -B 2 -A 2 BAYONETTA >>> @(#)FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 >>> FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 >>> = gcooper@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-st= able-9/sys/BAYONETTA >>> gcc version 4.2.1 20070831 patched [FreeBSD] >>> FreeBSD >>> 9.1-STABLE >>> BAYONETTA >>> $ cd /usr/src; git log 0304216 >>> commit 03042167f73c213732b44218a24d8e1bbea00f8c >>> Merge: 2edcad2 974abfb >>> Author: Garrett Cooper >>> Date: Mon Jun 24 19:00:45 2013 -0700 >>>=20 >>> Merge remote-tracking branch 'upstream/stable/9' into stable/9 >>>=20 >>> The working kernel [with atkbdc] was as follows: >>>=20 >>> FreeBSD bayonetta.local 9.2-BETA1 FreeBSD 9.2-BETA1 #12 r+c178034: = Sun Jul 21 20:19:38 PDT 2013 =20 >> = root@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-stabl= e-9/sys/BAYONETTA amd64 >>> $ git log c178034 >>> commit c17803445f4ffb97e1a46a1be5f7ea04692793f0 >>> Author: avg >>> Date: Tue Jul 9 08:30:31 2013 +0000 >>>=20 >>> zfsboottest.sh: remove checks for things that are not strictly = required >>>=20 >>> MFC after: 10 days >>>=20 >>> (Yes, I had to backport some things because they are busted on = stable/9 due to other incomplete/missing MFCs). >>>=20 >>> I can test out patches, but I don't have time to bisect the actual = commit that caused the failure. That being said my intuition says it's = this >> commit should be looked at first: >>>=20 >>> commit 28f961058b0667841d7e9d8639bfd02ed8689faa >>> Author: jhb >>> Date: Wed Jul 17 14:04:18 2013 +0000 >>>=20 >>> MFC 252576: >>> Don't perform the acpi_DeviceIsPresent() check for PCI-PCI = bridges. If >>> we are probing a PCI-PCI bridge it is because we found one by = enumerating >>> the devices on a PCI bus, so the bridge is definitely present. A = few >>> BIOSes report incorrect status (_STA) for some bridges that = claimed they >>> were not present when in fact they were. >>>=20 >>> While here, move this check earlier for Host-PCI bridges so attach = fails >>> before doing any work that needs to be torn down. >>>=20 >>> PR: kern/91594 >>> Approved by: re (marius) >>=20 >> I strongly doubt that this is related. It would be most helpful if = you could >> obtain a dmesg from the new kernel however (perhaps via a serial = console) to >> rule it out. All you would need to see is if the new kernel sees = more "pcib" >> devices than the old one to see if this change even has an effect on = your >> system. >=20 > Unfortunately the USB keyboard is broken as well at the mount root = prompt and the workstation doesn't have a uart on it that I can play = with (it's my home box), so I'm dead in the water when it panics at the = mount root prompt right now. >=20 > I guess I can revert this and a handful of other amd64/ata_cam/zfs = commits to see if this goes away, but I won't be getting to that before = next Sunday probably as this is my file server and DNS server now. I ran into the issue going from vanilla 9.2-RELEASE-p10 to = 9.3-RELEASE as well :(. I=92ve filed this bug to track the issue: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192183 . I=92ll see = if GENERIC can boot my system sometime this week (the KERNCONF has been = working for several releases, but it could be an issue with that that=92s = being overlooked by accident). Thanks! -Garrett From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 16:37:06 2014 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 ESMTPS id AF6187C8; Mon, 28 Jul 2014 16:37:06 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5841D218E; Mon, 28 Jul 2014 16:37:06 +0000 (UTC) Received: from [192.168.1.75] (75-48-77-17.lightspeed.cncrca.sbcglobal.net [75.48.77.17]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C79B7B949; Mon, 28 Jul 2014 12:37:03 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [REGRESSION] Root zpool mounting broken between 06/30/2013 and 07/21/2013 when PS/2 support compiled into the kernel From: John Baldwin In-Reply-To: <3BFFF901-F5C0-4079-834E-F3199A188EF8@gmail.com> Date: Mon, 28 Jul 2014 09:37:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <95A4D9A9-9D69-4258-A1EC-CBC6DC2F49FF@FreeBSD.org> References: <78424E5D-4EB2-4462-A190-D0AC97136790@gmail.com> <201307221208.22060.jhb@freebsd.org> <3BFFF901-F5C0-4079-834E-F3199A188EF8@gmail.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1878.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 28 Jul 2014 12:37:04 -0400 (EDT) Cc: "freebsd-fs@freebsd.org" , "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 16:37:06 -0000 On Jul 28, 2014, at 9:07 AM, Garrett Cooper = wrote: > On Jul 22, 2013, at 10:58 AM, Garrett Cooper = wrote: >=20 >> On Jul 22, 2013, at 9:08 AM, John Baldwin wrote: >>=20 >>> On Monday, July 22, 2013 10:30:32 am Garrett Cooper wrote: >>>> I have a KERNCONF that previously had PS/2 support compiled into = the kernel. If I comment out the following lines like so: >>>>=20 >>>> # atkbdc0 controls both the keyboard and the PS/2 mouse >>>> #device atkbdc # AT keyboard controller >>>> #device atkbd # AT keyboard >>>>=20 >>>> then I'm able to mount root again (it was failing with ENOXDEV). >>>>=20 >>>> The working kernel was as follows: >>>>=20 >>>> $ strings /boot/kernel.WORKING/kernel | grep -B 2 -A 2 BAYONETTA >>>> @(#)FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 >>>> FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 >>>> = gcooper@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-st= able-9/sys/BAYONETTA >>>> gcc version 4.2.1 20070831 patched [FreeBSD] >>>> FreeBSD >>>> 9.1-STABLE >>>> BAYONETTA >>>> $ cd /usr/src; git log 0304216 >>>> commit 03042167f73c213732b44218a24d8e1bbea00f8c >>>> Merge: 2edcad2 974abfb >>>> Author: Garrett Cooper >>>> Date: Mon Jun 24 19:00:45 2013 -0700 >>>>=20 >>>> Merge remote-tracking branch 'upstream/stable/9' into stable/9 >>>>=20 >>>> The working kernel [with atkbdc] was as follows: >>>>=20 >>>> FreeBSD bayonetta.local 9.2-BETA1 FreeBSD 9.2-BETA1 #12 r+c178034: = Sun Jul 21 20:19:38 PDT 2013 =20 >>> = root@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-stabl= e-9/sys/BAYONETTA amd64 >>>> $ git log c178034 >>>> commit c17803445f4ffb97e1a46a1be5f7ea04692793f0 >>>> Author: avg >>>> Date: Tue Jul 9 08:30:31 2013 +0000 >>>>=20 >>>> zfsboottest.sh: remove checks for things that are not strictly = required >>>>=20 >>>> MFC after: 10 days >>>>=20 >>>> (Yes, I had to backport some things because they are busted on = stable/9 due to other incomplete/missing MFCs). >>>>=20 >>>> I can test out patches, but I don't have time to bisect the actual = commit that caused the failure. That being said my intuition says it's = this >>> commit should be looked at first: >>>>=20 >>>> commit 28f961058b0667841d7e9d8639bfd02ed8689faa >>>> Author: jhb >>>> Date: Wed Jul 17 14:04:18 2013 +0000 >>>>=20 >>>> MFC 252576: >>>> Don't perform the acpi_DeviceIsPresent() check for PCI-PCI = bridges. If >>>> we are probing a PCI-PCI bridge it is because we found one by = enumerating >>>> the devices on a PCI bus, so the bridge is definitely present. A = few >>>> BIOSes report incorrect status (_STA) for some bridges that = claimed they >>>> were not present when in fact they were. >>>>=20 >>>> While here, move this check earlier for Host-PCI bridges so attach = fails >>>> before doing any work that needs to be torn down. >>>>=20 >>>> PR: kern/91594 >>>> Approved by: re (marius) >>>=20 >>> I strongly doubt that this is related. It would be most helpful if = you could >>> obtain a dmesg from the new kernel however (perhaps via a serial = console) to >>> rule it out. All you would need to see is if the new kernel sees = more "pcib" >>> devices than the old one to see if this change even has an effect on = your >>> system. >>=20 >> Unfortunately the USB keyboard is broken as well at the mount root = prompt and the workstation doesn't have a uart on it that I can play = with (it's my home box), so I'm dead in the water when it panics at the = mount root prompt right now. >>=20 >> I guess I can revert this and a handful of other amd64/ata_cam/zfs = commits to see if this goes away, but I won't be getting to that before = next Sunday probably as this is my file server and DNS server now. >=20 > I ran into the issue going from vanilla 9.2-RELEASE-p10 to = 9.3-RELEASE as well :(. I=92ve filed this bug to track the issue: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192183 . I=92ll see = if GENERIC can boot my system sometime this week (the KERNCONF has been = working for several releases, but it could be an issue with that that=92s = being overlooked by accident). > Thanks! There is basically zero chance that the commit in question can cause = this. Also, you would need to get verbose dmesg's of old and new = kernels as a first step in narrowing it down. --=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 16:57:09 2014 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 ESMTPS id C159F1A6; Mon, 28 Jul 2014 16:57:09 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A9D02462; Mon, 28 Jul 2014 16:57:09 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id h3so3924416igd.8 for ; Mon, 28 Jul 2014 09:57:08 -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:content-transfer-encoding; bh=9xyT82B/BhtPHkcW9Qy/IfunNscqwEV7qbVPPIUz4fc=; b=Vehph17EyiMNF4uqrn1muHazUd1Nl/gDU+gLKTxYKzJZSoZuC7ZfjskUv93iYpQHox RSBtEXQ0JwLVIUVd3WkTqNelw5r5n0ZbbmqQljTmatproL867wNaLP1C7zOGTVfQLpCL xnvtwkastu3cbaPQkhz8h4N5PJ/4nulekXcSUnUYtIQGqNujDzkZzkWSJUX63KqNOnxs H48WFXBtidAHaKr/gZcUoaQEfGAZzpXEcJoWq3Rvw7Fc/7uvnGmXwVdckV964e/0Fdxb mTAFvx8SEvsShCf0YOjB3uu114P83V+e/5qYBg9dw8lc7wqs9rZf0TWZbiw9MH50Y1lX RxQQ== MIME-Version: 1.0 X-Received: by 10.42.198.75 with SMTP id en11mr44210448icb.7.1406566628805; Mon, 28 Jul 2014 09:57:08 -0700 (PDT) Received: by 10.50.213.102 with HTTP; Mon, 28 Jul 2014 09:57:08 -0700 (PDT) In-Reply-To: <95A4D9A9-9D69-4258-A1EC-CBC6DC2F49FF@FreeBSD.org> References: <78424E5D-4EB2-4462-A190-D0AC97136790@gmail.com> <201307221208.22060.jhb@freebsd.org> <3BFFF901-F5C0-4079-834E-F3199A188EF8@gmail.com> <95A4D9A9-9D69-4258-A1EC-CBC6DC2F49FF@FreeBSD.org> Date: Mon, 28 Jul 2014 09:57:08 -0700 Message-ID: Subject: Re: [REGRESSION] Root zpool mounting broken between 06/30/2013 and 07/21/2013 when PS/2 support compiled into the kernel From: Garrett Cooper To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-fs@freebsd.org" , "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 16:57:09 -0000 On Mon, Jul 28, 2014 at 9:37 AM, John Baldwin wrote: > > On Jul 28, 2014, at 9:07 AM, Garrett Cooper wrote= : > >> On Jul 22, 2013, at 10:58 AM, Garrett Cooper wro= te: >> >>> On Jul 22, 2013, at 9:08 AM, John Baldwin wrote: >>> >>>> On Monday, July 22, 2013 10:30:32 am Garrett Cooper wrote: >>>>> I have a KERNCONF that previously had PS/2 support compiled into the = kernel. If I comment out the following lines like so: >>>>> >>>>> # atkbdc0 controls both the keyboard and the PS/2 mouse >>>>> #device atkbdc # AT keyboard controller >>>>> #device atkbd # AT keyboard >>>>> >>>>> then I'm able to mount root again (it was failing with ENOXDEV). >>>>> >>>>> The working kernel was as follows: >>>>> >>>>> $ strings /boot/kernel.WORKING/kernel | grep -B 2 -A 2 BAYONETTA >>>>> @(#)FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 >>>>> FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 >>>>> gcooper@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-free= bsd-stable-9/sys/BAYONETTA >>>>> gcc version 4.2.1 20070831 patched [FreeBSD] >>>>> FreeBSD >>>>> 9.1-STABLE >>>>> BAYONETTA >>>>> $ cd /usr/src; git log 0304216 >>>>> commit 03042167f73c213732b44218a24d8e1bbea00f8c >>>>> Merge: 2edcad2 974abfb >>>>> Author: Garrett Cooper >>>>> Date: Mon Jun 24 19:00:45 2013 -0700 >>>>> >>>>> Merge remote-tracking branch 'upstream/stable/9' into stable/9 >>>>> >>>>> The working kernel [with atkbdc] was as follows: >>>>> >>>>> FreeBSD bayonetta.local 9.2-BETA1 FreeBSD 9.2-BETA1 #12 r+c178034: Su= n Jul 21 20:19:38 PDT 2013 >>>> root@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-s= table-9/sys/BAYONETTA amd64 >>>>> $ git log c178034 >>>>> commit c17803445f4ffb97e1a46a1be5f7ea04692793f0 >>>>> Author: avg >>>>> Date: Tue Jul 9 08:30:31 2013 +0000 >>>>> >>>>> zfsboottest.sh: remove checks for things that are not strictly requi= red >>>>> >>>>> MFC after: 10 days >>>>> >>>>> (Yes, I had to backport some things because they are busted on stable= /9 due to other incomplete/missing MFCs). >>>>> >>>>> I can test out patches, but I don't have time to bisect the actual co= mmit that caused the failure. That being said my intuition says it's this >>>> commit should be looked at first: >>>>> >>>>> commit 28f961058b0667841d7e9d8639bfd02ed8689faa >>>>> Author: jhb >>>>> Date: Wed Jul 17 14:04:18 2013 +0000 >>>>> >>>>> MFC 252576: >>>>> Don't perform the acpi_DeviceIsPresent() check for PCI-PCI bridges. = If >>>>> we are probing a PCI-PCI bridge it is because we found one by enumer= ating >>>>> the devices on a PCI bus, so the bridge is definitely present. A fe= w >>>>> BIOSes report incorrect status (_STA) for some bridges that claimed = they >>>>> were not present when in fact they were. >>>>> >>>>> While here, move this check earlier for Host-PCI bridges so attach f= ails >>>>> before doing any work that needs to be torn down. >>>>> >>>>> PR: kern/91594 >>>>> Approved by: re (marius) >>>> >>>> I strongly doubt that this is related. It would be most helpful if yo= u could >>>> obtain a dmesg from the new kernel however (perhaps via a serial conso= le) to >>>> rule it out. All you would need to see is if the new kernel sees more= "pcib" >>>> devices than the old one to see if this change even has an effect on y= our >>>> system. >>> >>> Unfortunately the USB keyboard is broken as well at the mount root prom= pt and the workstation doesn't have a uart on it that I can play with (it's= my home box), so I'm dead in the water when it panics at the mount root pr= ompt right now. >>> >>> I guess I can revert this and a handful of other amd64/ata_cam/zfs comm= its to see if this goes away, but I won't be getting to that before next Su= nday probably as this is my file server and DNS server now. >> >> I ran into the issue going from vanilla 9.2-RELEASE-p10 to 9.3-REL= EASE as well :(. I=E2=80=99ve filed this bug to track the issue: https://bu= gs.freebsd.org/bugzilla/show_bug.cgi?id=3D192183 . I=E2=80=99ll see if GENE= RIC can boot my system sometime this week (the KERNCONF has been working fo= r several releases, but it could be an issue with that that=E2=80=99s being= overlooked by accident). >> Thanks! ... > Also, you would need to get verbose dmesg's of old and new kernels as a f= irst step in narrowing it down. I can't do trivial debugging because my USB keyboard doesn't work at the mountroot prompt ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D133989 ), I don't have a PS/2 keyboard, and the system only has VGA access :(. I'll try working on disabling the PS/2 controller in the BIOS and a few other things to force the system to stop ignoring the USB keyboard to get scrollback, because that appeared to work for some folks with this issue according to the ukbd bug I referenced. -Garrett From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 20:02:38 2014 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 ESMTPS id 156B06F3 for ; Mon, 28 Jul 2014 20:02:38 +0000 (UTC) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CCE7E2ADB for ; Mon, 28 Jul 2014 20:02:37 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id ik5so3285820vcb.34 for ; Mon, 28 Jul 2014 13:02:36 -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:content-type; bh=WxuxVVwR2zNvqMrn1KnhgjOfFKvq9RZpNwlRDF4PlOg=; b=L5PfimNcJbTC622KyOPPAGuhcLgIV45jEOLaaBil1N4WYWI874eEBRTI6dWhqRaEgu h+tHZqUtZDr7XpynmCjXY0EDLQp6M5ef2irmTsrRCB4GarElKP+vr0VKjbXL3NhvCPwv +iQioO7ph2YssDegIB4lkVcCANetbygw+v59SHTurICOVW6/MHuaWhmpshE/Q4uMavOo DYlacnoPA5M71pi7NaTw16FMRD3+pXUOwKGAAxSjka23DXOwzA1DTE66BtM76fcuZI7/ 501w2zbcqCaOKf5aPatnCDxpYQe1qsxNCt9XzW+EA1oqYpwpGVbY/zCbCmwH8SEDU5cc OSEg== MIME-Version: 1.0 X-Received: by 10.220.183.65 with SMTP id cf1mr3226007vcb.76.1406577756869; Mon, 28 Jul 2014 13:02:36 -0700 (PDT) Received: by 10.220.136.79 with HTTP; Mon, 28 Jul 2014 13:02:36 -0700 (PDT) Date: Mon, 28 Jul 2014 22:02:36 +0200 Message-ID: Subject: Recent 10-STABLE powers off during boot if SMP is enabled From: Nikolay Denev To: FreeBSD Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 20:02:38 -0000 Hi, I've just upgraded from a few months old 10-STABLE to today's 10-STABLE and suddenly my machine started to poweroff during boot. The machine itself is a bit old and quirky (HP ex470) and the kernel is with RCTL, VIMAGE and other stuff not in GENERIC. The last thing that flashes on the screen before powering off is this : http://tinypic.com/r/2uf3oqt/8 I've then tried to add "kern.smp.disabled=1" in /boot/loader.conf and it boots Ok with one CPU. Any ideas? --Nikolay From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 21:12:16 2014 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 ESMTPS id 81829DC2; Mon, 28 Jul 2014 21:12:16 +0000 (UTC) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 18E572452; Mon, 28 Jul 2014 21:12:16 +0000 (UTC) Received: by mail-vc0-f179.google.com with SMTP id hq11so12220266vcb.38 for ; Mon, 28 Jul 2014 14:12:15 -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=VoubXm5SSfzueFiFVhmhuvwLaNCWWlFEw/Cz1EEgX48=; b=CDchnjmsPawFJD/4QrbtEj0p6+eP9L4i99BZAZxM7tQUyal83TWFxFkmWEwUZeZbDU pZxguRvtoP88HBJ9PPdSNAAFdveiE5j3sFrXgl9KkfrbjBOWqtW5mhHAM7Fox/sjnCyP KX1avT2Ki70uxpE5Eg0C9FAZRymPV0cCEzJsNn1UoCAXHg5LRCK2/1omEWsHQb8rcl8P F5YychWyXRsA+B57tN1ui5sw5/hv921dU3RPnMmJKXm8iYyktkN/LOMF9K0KO3jpUE+I vTnIhGSI/Rm/a0HK03WaYdCF0Y8mQ77UviENN6RM8kZRHJ5k6sw2hch1+CG3Bj7abkA0 29yQ== MIME-Version: 1.0 X-Received: by 10.52.25.228 with SMTP id f4mr66396vdg.62.1406581935088; Mon, 28 Jul 2014 14:12:15 -0700 (PDT) Received: by 10.220.194.129 with HTTP; Mon, 28 Jul 2014 14:12:15 -0700 (PDT) In-Reply-To: References: <201406262133.s5QLXXP8029811@svn.freebsd.org> Date: Mon, 28 Jul 2014 14:12:15 -0700 Message-ID: Subject: Re: svn commit: r267935 - head/sys/dev/e1000 From: Jack Vogel To: Ed Maste Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Jack F Vogel , "stable@freebsd.org" , hiren panchasara X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 21:12:16 -0000 Done, thanks for staying on my case Ed :) Jack On Fri, Jul 25, 2014 at 11:03 AM, Ed Maste wrote: > >> On Wed, Jul 16, 2014 at 11:49 PM, Herbert J. Skuhra > wrote: > >> > Den 26.06.2014 23:33, skrev Jack F Vogel: > >> > > >> >> Author: jfv > >> >> Date: Thu Jun 26 21:33:32 2014 > >> >> New Revision: 267935 > >> >> URL: http://svnweb.freebsd.org/changeset/base/267935 > >> >> > >> >> Log: > >> >> Sync the E1000 shared code with Intel internal, this adds fixes, > >> >> and more importantly, new I218 adapter support to the em driver. > >> >> > >> >> MFC after: 1 week > >> > > >> > > >> > Does anyone know when this will be commited to stable/10? > >> > Any open issues with this change? > > > > On 17 July 2014 03:31, Jack Vogel wrote: > > Will try to squeeze it in between crises next week :) > > Hi Jack - do you think you'll be able to tackle this soon? It will be > very good to get test exposure in advance of the fast-approaching 10.1 > release process. > > Thanks, > Ed > From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 22:17:56 2014 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 ESMTPS id 7D363D26 for ; Mon, 28 Jul 2014 22:17:56 +0000 (UTC) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E8DC2AB0 for ; Mon, 28 Jul 2014 22:17:56 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id lf12so12272200vcb.29 for ; Mon, 28 Jul 2014 15:17:55 -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 :content-type; bh=IF16LWFBHWN2D6lbv4EcXVNn8ET8BX/3gg2VZIYcccM=; b=xU1pbykYMh15SHp95nSgAY2749QzvGeAtH3X5J96nK8bqdwz3Wl3au7dr7Tmfimyrn JireWEga4VoEnyMXxz/ksVOYx5E4X695BHscuS0hfNUmyZsa9U59nhuj8tihksE2LReP 9E3RKHSbxj94FLdGCvKnJsUAhT2BwLgK2k9SrpUT1JzSs12xf9ALwAa07fzoTYLWdXig LiThvFFm1CmQ11NZ4IL/BFfIMja9Bt8fkRwAU8MR0lyPr2Aj6Y512R41CrTT3tiHTKhH 0t89m3WIeTjZKuCWfsRnJ9JTMcWOnCNqeSrrt+Tw13XsjfJXmxuyIsXPZnI8c8Pt1yos 4n+g== MIME-Version: 1.0 X-Received: by 10.52.36.80 with SMTP id o16mr279954vdj.58.1406585875306; Mon, 28 Jul 2014 15:17:55 -0700 (PDT) Received: by 10.220.194.68 with HTTP; Mon, 28 Jul 2014 15:17:55 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Jul 2014 00:17:55 +0200 Message-ID: Subject: Re: Recent 10-STABLE powers off during boot if SMP is enabled From: Nikolay Denev To: FreeBSD Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 28 Jul 2014 22:17:56 -0000 On Mon, Jul 28, 2014 at 10:02 PM, Nikolay Denev wrote: > Hi, > > I've just upgraded from a few months old 10-STABLE to today's > 10-STABLE and suddenly > my machine started to poweroff during boot. > The machine itself is a bit old and quirky (HP ex470) and the kernel > is with RCTL, VIMAGE and other stuff not in GENERIC. > > The last thing that flashes on the screen before powering off is this > : http://tinypic.com/r/2uf3oqt/8 > > I've then tried to add "kern.smp.disabled=1" in /boot/loader.conf and > it boots Ok with one CPU. > > Any ideas? > > --Nikolay Here's what I have in loader.conf: net.fibs="16" autoboot_delay="3" dtraceall_load="YES" vfs.root.mountfrom="zfs:zfs" amdtemp_load="YES" if_sge_load="YES" zfs_load="YES" aio_load="YES" kern.ipc.nmbclusters=256000 hw.ata.wc=0 dev.cpu.0.freq=2000 linux_load="YES" hw.mca.enabled=1 vfs.zfs.arc_min="256M" vfs.zfs.arc_max="1024M" ex470_load="YES" kern.geom.label.gpt.enable=1 kern.cam.ada.legacy_aliases=0 KERNCONF : cpu HAMMER ident NAS makeoptions DEBUG=-gdwarf-2 makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support options RACCT options RCTL options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options TCP_OFFLOAD # TCP offload #options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories #options UFS_GJOURNAL # Enable gjournal-based UFS journaling #options QUOTA # Enable disk quotas for UFS #options MD_ROOT # MD is a potential root device options NFSCL # New Network Filesystem Client options NFSD # New Network Filesystem Server options NFSLOCKD # Network Lock Manager #options NFS_ROOT # NFS usable as /, requires NFSCL #options MSDOSFS # MSDOS Filesystem #options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_RAID # Soft RAID functionality. options GEOM_LABEL # Provides labelization options COMPAT_FREEBSD32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=500 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options CAPABILITY_MODE # Capsicum capability mode options CAPABILITIES # Capsicum capabilities options PROCDESC # Support for process descriptors options MAC # TrustedBSD MAC Framework options KDTRACE_FRAME # Ensure frames are compiled in options KDTRACE_HOOKS # Kernel DTrace hooks options DDB_CTF # Kernel ELF linker loads CTF data options INCLUDE_CONFIG_FILE # Include this file in kernel # Debugging support. Always need this: options KDB # Enable kernel debugger support. options KDB_TRACE # Print a stack trace for a panic. # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq # Bus support. device acpi device pci # ATA controllers device ahci # AHCI-compatible SATA controllers device ata # Legacy ATA/SATA controllers options ATA_STATIC_ID # Static device numbering device mvs # Marvell 88SX50XX/88SX60XX/88SX70XX/SoC SATA device siis # SiliconImage SiI3124/SiI3132/SiI3531 SATA # ATA/SCSI peripherals device scbus # SCSI bus (required for ATA/SCSI) #device ch # SCSI media changers device da # Direct Access (disks) #device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct ATA/SCSI access) device ses # Enclosure Services (SES and SAF-TE) #device ctl # CAM Target Layer # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard #device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver #options VGA_WIDTH90 device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc options SC_PIXEL_MODE device agp # support several AGP chipsets # Serial (COM) ports device uart # Generic UART driver # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device sge # Silicon Integrated Systems SiS190/191 # Pseudo devices. device loop # Network loopback device random # Entropy device device padlock_rng # VIA Padlock RNG device rdrand_rng # Intel Bull Mountain RNG device ether # Ethernet support device vlan # 802.1Q VLAN support device tun # Packet tunnel. device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module device bpf # Berkeley packet filter # USB support options USB_DEBUG # enable debug msgs device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device xhci # XHCI PCI->USB interface (USB 3.0) device usb # USB Bus (required) device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da options VIMAGE options ROUTETABLES=8 options RADIX_MPATH From owner-freebsd-stable@FreeBSD.ORG Tue Jul 29 01:33:18 2014 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 ESMTPS id E6A3D195; Tue, 29 Jul 2014 01:33:18 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AAE86203A; Tue, 29 Jul 2014 01:33:18 +0000 (UTC) Received: from pippin.baldwin.cx (75-48-77-17.lightspeed.cncrca.sbcglobal.net [75.48.77.17]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A35D5B94B; Mon, 28 Jul 2014 21:33:16 -0400 (EDT) From: John Baldwin To: Garrett Cooper Subject: Re: [REGRESSION] Root zpool mounting broken between 06/30/2013 and 07/21/2013 when PS/2 support compiled into the kernel Date: Mon, 28 Jul 2014 21:32:24 -0400 Message-ID: <10421077.Qp3biFQLVt@pippin.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/11.0-CURRENT; KDE/4.12.5; amd64; ; ) In-Reply-To: References: <78424E5D-4EB2-4462-A190-D0AC97136790@gmail.com> <95A4D9A9-9D69-4258-A1EC-CBC6DC2F49FF@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 28 Jul 2014 21:33:16 -0400 (EDT) Cc: "freebsd-fs@freebsd.org" , "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 01:33:19 -0000 On Monday 28 July 2014 09:57:08 Garrett Cooper wrote: > On Mon, Jul 28, 2014 at 9:37 AM, John Baldwin wrote= : > > On Jul 28, 2014, at 9:07 AM, Garrett Cooper = wrote: > >> On Jul 22, 2013, at 10:58 AM, Garrett Cooper =20 wrote: > >>> On Jul 22, 2013, at 9:08 AM, John Baldwin wrote= : > >>>> On Monday, July 22, 2013 10:30:32 am Garrett Cooper wrote: > >>>>> I have a KERNCONF that previously had PS/2 support compiled int= o the > >>>>> kernel. If I comment out the following lines like so: > >>>>>=20 > >>>>> # atkbdc0 controls both the keyboard and the PS/2 mouse > >>>>> #device atkbdc # AT keyboard controller > >>>>> #device atkbd # AT keyboard > >>>>>=20 > >>>>> then I'm able to mount root again (it was failing with ENOXDEV)= . > >>>>>=20 > >>>>> The working kernel was as follows: > >>>>>=20 > >>>>> $ strings /boot/kernel.WORKING/kernel | grep -B 2 -A 2 BAYONETT= A > >>>>> @(#)FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 20= 13 > >>>>> FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 > >>>>>=20 > >>>>> gcooper@bayonetta.local:/usr/obj/scratch/git/github/yaneurabey= a-freeb > >>>>> sd-stable-9/sys/BAYONETTA>>>>>=20 > >>>>> gcc version 4.2.1 20070831 patched [FreeBSD] > >>>>> FreeBSD > >>>>> 9.1-STABLE > >>>>> BAYONETTA > >>>>> $ cd /usr/src; git log 0304216 > >>>>> commit 03042167f73c213732b44218a24d8e1bbea00f8c > >>>>> Merge: 2edcad2 974abfb > >>>>> Author: Garrett Cooper > >>>>> Date: Mon Jun 24 19:00:45 2013 -0700 > >>>>>=20 > >>>>> Merge remote-tracking branch 'upstream/stable/9' into stable/9= > >>>>>=20 > >>>>> The working kernel [with atkbdc] was as follows: > >>>>>=20 > >>>>> FreeBSD bayonetta.local 9.2-BETA1 FreeBSD 9.2-BETA1 #12 r+c1780= 34: Sun > >>>>> Jul 21 20:19:38 PDT 2013>>>>=20 > >>>> root@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-fre= ebsd-st > >>>> able-9/sys/BAYONETTA amd64>>>>=20 > >>>>> $ git log c178034 > >>>>> commit c17803445f4ffb97e1a46a1be5f7ea04692793f0 > >>>>> Author: avg > >>>>> Date: Tue Jul 9 08:30:31 2013 +0000 > >>>>>=20 > >>>>> zfsboottest.sh: remove checks for things that are not strictly= > >>>>> required > >>>>> =20 > >>>>> MFC after: 10 days > >>>>>=20 > >>>>> (Yes, I had to backport some things because they are busted on > >>>>> stable/9 due to other incomplete/missing MFCs). > >>>>>=20 > >>>>> I can test out patches, but I don't have time to bisect the act= ual > >>>>> commit that caused the failure. That being said my intuition sa= ys > >>>>> it's this>>>>=20 > >>>> commit should be looked at first: > >>>>> commit 28f961058b0667841d7e9d8639bfd02ed8689faa > >>>>> Author: jhb > >>>>> Date: Wed Jul 17 14:04:18 2013 +0000 > >>>>>=20 > >>>>> MFC 252576: > >>>>> Don't perform the acpi_DeviceIsPresent() check for PCI-PCI bri= dges.=20 > >>>>> If > >>>>> we are probing a PCI-PCI bridge it is because we found one by > >>>>> enumerating > >>>>> the devices on a PCI bus, so the bridge is definitely present.= A few > >>>>> BIOSes report incorrect status (_STA) for some bridges that cl= aimed > >>>>> they > >>>>> were not present when in fact they were. > >>>>> =20 > >>>>> While here, move this check earlier for Host-PCI bridges so at= tach > >>>>> fails > >>>>> before doing any work that needs to be torn down. > >>>>> =20 > >>>>> PR: kern/91594 > >>>>> Approved by: re (marius) > >>>>=20 > >>>> I strongly doubt that this is related. It would be most helpful= if you > >>>> could obtain a dmesg from the new kernel however (perhaps via a = serial > >>>> console) to rule it out. All you would need to see is if the ne= w > >>>> kernel sees more "pcib" devices than the old one to see if this = change > >>>> even has an effect on your system. > >>>=20 > >>> Unfortunately the USB keyboard is broken as well at the mount roo= t > >>> prompt and the workstation doesn't have a uart on it that I can p= lay > >>> with (it's my home box), so I'm dead in the water when it panics = at the > >>> mount root prompt right now. > >>>=20 > >>> I guess I can revert this and a handful of other amd64/ata_cam/zf= s > >>> commits to see if this goes away, but I won't be getting to that = before > >>> next Sunday probably as this is my file server and DNS server now= .>>>=20 > >> I ran into the issue going from vanilla 9.2-RELEASE-p10 to > >> 9.3-RELEASE as well :(. I=E2=80=99ve filed this bug to track= the issue: > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192183 .= I=E2=80=99ll > >> see if GENERIC can boot my system sometime this week (the KE= RNCONF > >> has been working for several releases, but it could be an is= sue > >> with that that=E2=80=99s being overlooked by accident).>>=20= > >> Thanks! >=20 > ... >=20 > > Also, you would need to get verbose dmesg's of old and new kernels = as a > > first step in narrowing it down. > I can't do trivial debugging because my USB keyboard doesn't work at > the mountroot prompt ( > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D133989 ), I don't= > have a PS/2 keyboard, and the system only has VGA access :(. I'll try= > working on disabling the PS/2 controller in the BIOS and a few other > things to force the system to stop ignoring the USB keyboard to get > scrollback, because that appeared to work for some folks with this > issue according to the ukbd bug I referenced. Do you have a serial port so you could use a serial console (or is this= a=20 laptop)? --=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Jul 29 14:04:53 2014 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 ESMTPS id 31EA317B for ; Tue, 29 Jul 2014 14:04:53 +0000 (UTC) Received: from mx2.paymentallianceintl.com (mx2.paymentallianceintl.com [216.26.158.171]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx2.paymentallianceintl.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9AD772467 for ; Tue, 29 Jul 2014 14:04:49 +0000 (UTC) Received: from PAIMAIL.pai.local (paimail.pai.local [10.10.0.153]) by mx2.paymentallianceintl.com (8.14.5/8.13.8) with ESMTP id s6TE4f60087238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 29 Jul 2014 10:04:41 -0400 (EDT) (envelope-from mikej@paymentallianceintl.com) Received: from PAICAS.pai.local (10.10.0.154) by PAIMAIL.pai.local (10.10.0.153) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 29 Jul 2014 10:04:41 -0400 Received: from PAIMAIL.pai.local ([::1]) by PAICAS.pai.local ([::1]) with mapi; Tue, 29 Jul 2014 10:04:41 -0400 From: Michael Jung To: "freebsd-stable@freebsd.org" Date: Tue, 29 Jul 2014 10:04:41 -0400 Subject: r269147 fails to boot after ZFS pool upgrade and new boot code installation Thread-Topic: r269147 fails to boot after ZFS pool upgrade and new boot code installation Thread-Index: Ac+rNdbTfaK45XUyTaW+FCGAeI2bXw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 14:04:53 -0000 Everyone, The freebsd-fs was silent about this post so I'm hoping someone will chime in here. 10-stable r269147: Upgraded the zfs pool to 5000 and installed new bootcode= . The system was working fine prior to upgrading the pool. NOTE: Due to the BIOS not supporting drives > 2TB in ACHI mode this MB is running in legacy IDE mode. I understand the speed implications of this - it is just a test box. ZFS MIRROR BOOT ada0/ada1 gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad0 gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad1 Loading Operating System ... ZFS: i/o error - all block copies unavailable ZFS: can't read object set for dataset u ZFS: can't open root filesystem gptzsboot: failed to mount default pool zroot FreBSD/x86 boot Default zroot: boot: I tried to recover using FreeBSD-Stable USB Live CD r268571 but could not import the pool. # zpool import -f -N zroot ZFS filesystem version:5 ZFS storage pool version: feature support (5000) This pool uses the following feature(s) not support by this system: com.delphix:embedded_data cannot impot 'zroot': unsupported version or feature # FreeBSD-11-Current r268622 LIVE CD (USB) imports the pool fine. Only two mirrored drives attached to onboard SATA. Both drives show up in = =3D BIOS as first two boot devices. I attempted to install the r269147 bootcode again like: # zpool import -f -N zroot # mkdir /tmp/zroot # mount -r -t zfs zroot/ROOT/default /tmp/zroot # gpart bootcode -b /tmp/zroot/boot/pmbr -p /tmp/zroot/boot/gptzfsboot -i 1= =3D ada0 # gpart bootcode -b /tmp/zroot/boot/pmbr -p /tmp/zroot/boot/gptzfsboot -i 1= =3D ada1 but resulted in same problem. I also tried installing 11-current bootcode = =3D r268622 which also fails to boot. (I did not export the pool. I even tried power reset after writing bootcod= =3D e) gpart list/show: 34 5860533101 ada0 GPT (2.7T) 34 6 - free - (3.0K) 40 1024 1 freebsd-boot (512K) 1064 25165824 2 freebsd-swap (12G) 25166888 5835366240 3 freebsd-zfs (2.7T) 5860533128 7 - free - (3.5K) 34 5860533101 ada1 GPT (2.7T) 34 6 - free - (3.0K) 40 1024 1 freebsd-boot (512K) 1064 25165824 2 freebsd-swap (12G) 25166888 5835366240 3 freebsd-zfs (2.7T) 5860533128 7 - free - (3.5K) Geom name: ada0 modified: false state: OK fwheads: 16 fwsectors: 63 last: 5860533134 first: 34 entries: 128 scheme: GPT Providers: 1. Name: ada0p1 Mediasize: 524288 (512K) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r0w0e0 rawuuid: 4130f007-f278-11e3-990a-001b211e2e44 rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f label: gptboot0 length: 524288 offset: 20480 type: freebsd-boot index: 1 end: 1063 start: 40 2. Name: ada0p2 Mediasize: 12884901888 (12G) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r0w0e0 rawuuid: 41809b76-f278-11e3-990a-001b211e2e44 rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b label: swap0 length: 12884901888 offset: 544768 type: freebsd-swap index: 2 end: 25166887 start: 1064 3. Name: ada0p3 Mediasize: 2987707514880 (2.7T) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e2 rawuuid: 41ad88b5-f278-11e3-990a-001b211e2e44 rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b label: zfs0 length: 2987707514880 offset: 12885446656 type: freebsd-zfs index: 3 end: 5860533127 start: 25166888 Consumers: 1. Name: ada0 Mediasize: 3000592982016 (2.7T) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e3 Geom name: ada1 modified: false state: OK fwheads: 16 fwsectors: 63 last: 5860533134 first: 34 entries: 128 scheme: GPT Providers: 1. Name: ada1p1 Mediasize: 524288 (512K) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r0w0e0 rawuuid: 4260eded-f278-11e3-990a-001b211e2e44 rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f label: gptboot1 length: 524288 offset: 20480 type: freebsd-boot index: 1 end: 1063 start: 40 2. Name: ada1p2 Mediasize: 12884901888 (12G) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r0w0e0 rawuuid: 42984815-f278-11e3-990a-001b211e2e44 rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b label: swap1 length: 12884901888 offset: 544768 type: freebsd-swap index: 2 end: 25166887 start: 1064 3. Name: ada1p3 Mediasize: 2987707514880 (2.7T) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e2 rawuuid: 42c54127-f278-11e3-990a-001b211e2e44 rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b label: zfs1 length: 2987707514880 offset: 12885446656 type: freebsd-zfs index: 3 end: 5860533127 start: 25166888 Consumers: 1. Name: ada1 Mediasize: 3000592982016 (2.7T) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e3 Geom name: da0 modified: false state: OK fwheads: 255 fwsectors: 63 last: 15633405 first: 3 entries: 4 scheme: GPT Providers: 1. Name: da0p1 Mediasize: 819200 (800K) Sectorsize: 512 Stripesize: 0 Stripeoffset: 1536 Mode: r0w0e0 rawuuid: 71f92853-0b8c-11e4-8fcb-002564f96db2 rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b label: (null) length: 819200 offset: 1536 type: efi index: 1 end: 1602 start: 3 2. Name: da0p2 Mediasize: 16384 (16K) Sectorsize: 512 Stripesize: 0 Stripeoffset: 820736 Mode: r0w0e0 rawuuid: 71f9287f-0b8c-11e4-8fcb-002564f96db2 rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f label: (null) length: 16384 offset: 820736 type: freebsd-boot index: 2 end: 1634 start: 1603 3. Name: da0p3 Mediasize: 697991168 (666M) Sectorsize: 512 Stripesize: 0 Stripeoffset: 837120 Mode: r1w0e1 rawuuid: 71f9288e-0b8c-11e4-8fcb-002564f96db2 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: (null) length: 697991168 offset: 837120 type: freebsd-ufs index: 3 end: 1364898 start: 1635 4. Name: da0p4 Mediasize: 1048576 (1.0M) Sectorsize: 512 Stripesize: 0 Stripeoffset: 698828288 Mode: r0w0e0 rawuuid: 71f9289d-0b8c-11e4-8fcb-002564f96db2 rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b label: (null) length: 1048576 offset: 698828288 type: freebsd-swap index: 4 end: 1366946 start: 1364899 Consumers: 1. Name: da0 Mediasize: 8004304896 (7.5G) Sectorsize: 512 Mode: r1w0e1 Geom name: diskid/DISK-20043512300A4E318DDE modified: false state: OK fwheads: 255 fwsectors: 63 last: 15633405 first: 3 entries: 4 scheme: GPT Providers: 1. Name: diskid/DISK-20043512300A4E318DDEp1 Mediasize: 819200 (800K) Sectorsize: 512 Stripesize: 0 Stripeoffset: 1536 Mode: r0w0e0 rawuuid: 71f92853-0b8c-11e4-8fcb-002564f96db2 rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b label: (null) length: 819200 offset: 1536 type: efi index: 1 end: 1602 start: 3 2. Name: diskid/DISK-20043512300A4E318DDEp2 Mediasize: 16384 (16K) Sectorsize: 512 Stripesize: 0 Stripeoffset: 820736 Mode: r0w0e0 rawuuid: 71f9287f-0b8c-11e4-8fcb-002564f96db2 rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f label: (null) length: 16384 offset: 820736 type: freebsd-boot index: 2 end: 1634 start: 1603 3. Name: diskid/DISK-20043512300A4E318DDEp3 Mediasize: 697991168 (666M) Sectorsize: 512 Stripesize: 0 Stripeoffset: 837120 Mode: r0w0e0 rawuuid: 71f9288e-0b8c-11e4-8fcb-002564f96db2 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: (null) length: 697991168 offset: 837120 type: freebsd-ufs index: 3 end: 1364898 start: 1635 4. Name: diskid/DISK-20043512300A4E318DDEp4 Mediasize: 1048576 (1.0M) Sectorsize: 512 Stripesize: 0 Stripeoffset: 698828288 Mode: r0w0e0 rawuuid: 71f9289d-0b8c-11e4-8fcb-002564f96db2 rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b label: (null) length: 1048576 offset: 698828288 type: freebsd-swap index: 4 end: 1366946 start: 1364899 Consumers: 1. Name: diskid/DISK-20043512300A4E318DDE Mediasize: 8004304896 (7.5G) Sectorsize: 512 Mode: r0w0e0 Any ideas on how to debug this further? Regards, Michael Jung GoPai.com | Facebook.com/PaymentAlliance [cid:iso] CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 6060 Dutchmans Lane, Suite 320, Louisville, KY 40205 From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 10:51:27 2014 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 ESMTPS id 350928F2; Wed, 30 Jul 2014 10:51:27 +0000 (UTC) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F00E62ACE; Wed, 30 Jul 2014 10:51:26 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id bj1so1311442pad.39 for ; Wed, 30 Jul 2014 03:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1k69CfV87RE1BNtfzMghnIWBoXgJmb1tQuRSkAs0d0Y=; b=wTTtuEVQesWQRhs+kOv/h5RS1YMCmyz6yCoMtY7g0rW4QHltulJ8e6s74PN8IBx2zi ze95W5ngtz/3RuOuIB4kLJb6jQOSIQq5EzKsmjhYm9IAIw/GEM6pyq9IvPVDykXwxFnE J70iYFZj+nOeSlFY5e4+2cnRym/pcsoqsQh6bF5JcXZ0NlDCwzUhR2u5eBGY2OhVGfNM ompIOoWpeAGwbqU5KCiMTvompnP4Bam1aQCvtf7+UJEWCCfAsqAIO1jJ4si9YPOxTMco LQEE3oVt7YYhtL6kvi1a7nHxI0ptipIInr5Mal04APyvc17rQipY+W2Lu4OlsL9qesnB NqWw== X-Received: by 10.70.37.129 with SMTP id y1mr3714934pdj.12.1406717486174; Wed, 30 Jul 2014 03:51:26 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:4de3:c604:bd4e:bab2? ([2601:8:ab80:7d6:4de3:c604:bd4e:bab2]) by mx.google.com with ESMTPSA id da14sm6775014pac.24.2014.07.30.03.51.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 03:51:25 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [REGRESSION] Root zpool mounting broken between 06/30/2013 and 07/21/2013 when PS/2 support compiled into the kernel From: Garrett Cooper In-Reply-To: <10421077.Qp3biFQLVt@pippin.baldwin.cx> Date: Wed, 30 Jul 2014 03:51:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <78424E5D-4EB2-4462-A190-D0AC97136790@gmail.com> <95A4D9A9-9D69-4258-A1EC-CBC6DC2F49FF@FreeBSD.org> <10421077.Qp3biFQLVt@pippin.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-fs@freebsd.org" , "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 30 Jul 2014 10:51:27 -0000 On Jul 28, 2014, at 6:32 PM, John Baldwin wrote: > On Monday 28 July 2014 09:57:08 Garrett Cooper wrote: >> On Mon, Jul 28, 2014 at 9:37 AM, John Baldwin = wrote: >>> On Jul 28, 2014, at 9:07 AM, Garrett Cooper = wrote: >>>> On Jul 22, 2013, at 10:58 AM, Garrett Cooper = =20 > wrote: >>>>> On Jul 22, 2013, at 9:08 AM, John Baldwin wrote: >>>>>> On Monday, July 22, 2013 10:30:32 am Garrett Cooper wrote: >>>>>>> I have a KERNCONF that previously had PS/2 support compiled into = the >>>>>>> kernel. If I comment out the following lines like so: >>>>>>>=20 >>>>>>> # atkbdc0 controls both the keyboard and the PS/2 mouse >>>>>>> #device atkbdc # AT keyboard controller >>>>>>> #device atkbd # AT keyboard >>>>>>>=20 >>>>>>> then I'm able to mount root again (it was failing with ENOXDEV). >>>>>>>=20 >>>>>>> The working kernel was as follows: >>>>>>>=20 >>>>>>> $ strings /boot/kernel.WORKING/kernel | grep -B 2 -A 2 BAYONETTA >>>>>>> @(#)FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT = 2013 >>>>>>> FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 >>>>>>>=20 >>>>>>> = gcooper@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freeb >>>>>>> sd-stable-9/sys/BAYONETTA>>>>>=20 >>>>>>> gcc version 4.2.1 20070831 patched [FreeBSD] >>>>>>> FreeBSD >>>>>>> 9.1-STABLE >>>>>>> BAYONETTA >>>>>>> $ cd /usr/src; git log 0304216 >>>>>>> commit 03042167f73c213732b44218a24d8e1bbea00f8c >>>>>>> Merge: 2edcad2 974abfb >>>>>>> Author: Garrett Cooper >>>>>>> Date: Mon Jun 24 19:00:45 2013 -0700 >>>>>>>=20 >>>>>>> Merge remote-tracking branch 'upstream/stable/9' into stable/9 >>>>>>>=20 >>>>>>> The working kernel [with atkbdc] was as follows: >>>>>>>=20 >>>>>>> FreeBSD bayonetta.local 9.2-BETA1 FreeBSD 9.2-BETA1 #12 = r+c178034: Sun >>>>>>> Jul 21 20:19:38 PDT 2013>>>>=20 >>>>>> = root@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-st >>>>>> able-9/sys/BAYONETTA amd64>>>>=20 >>>>>>> $ git log c178034 >>>>>>> commit c17803445f4ffb97e1a46a1be5f7ea04692793f0 >>>>>>> Author: avg >>>>>>> Date: Tue Jul 9 08:30:31 2013 +0000 >>>>>>>=20 >>>>>>> zfsboottest.sh: remove checks for things that are not strictly >>>>>>> required >>>>>>>=20 >>>>>>> MFC after: 10 days >>>>>>>=20 >>>>>>> (Yes, I had to backport some things because they are busted on >>>>>>> stable/9 due to other incomplete/missing MFCs). >>>>>>>=20 >>>>>>> I can test out patches, but I don't have time to bisect the = actual >>>>>>> commit that caused the failure. That being said my intuition = says >>>>>>> it's this>>>>=20 >>>>>> commit should be looked at first: >>>>>>> commit 28f961058b0667841d7e9d8639bfd02ed8689faa >>>>>>> Author: jhb >>>>>>> Date: Wed Jul 17 14:04:18 2013 +0000 >>>>>>>=20 >>>>>>> MFC 252576: >>>>>>> Don't perform the acpi_DeviceIsPresent() check for PCI-PCI = bridges.=20 >>>>>>> If >>>>>>> we are probing a PCI-PCI bridge it is because we found one by >>>>>>> enumerating >>>>>>> the devices on a PCI bus, so the bridge is definitely present. = A few >>>>>>> BIOSes report incorrect status (_STA) for some bridges that = claimed >>>>>>> they >>>>>>> were not present when in fact they were. >>>>>>>=20 >>>>>>> While here, move this check earlier for Host-PCI bridges so = attach >>>>>>> fails >>>>>>> before doing any work that needs to be torn down. >>>>>>>=20 >>>>>>> PR: kern/91594 >>>>>>> Approved by: re (marius) >>>>>>=20 >>>>>> I strongly doubt that this is related. It would be most helpful = if you >>>>>> could obtain a dmesg from the new kernel however (perhaps via a = serial >>>>>> console) to rule it out. All you would need to see is if the new >>>>>> kernel sees more "pcib" devices than the old one to see if this = change >>>>>> even has an effect on your system. >>>>>=20 >>>>> Unfortunately the USB keyboard is broken as well at the mount root >>>>> prompt and the workstation doesn't have a uart on it that I can = play >>>>> with (it's my home box), so I'm dead in the water when it panics = at the >>>>> mount root prompt right now. >>>>>=20 >>>>> I guess I can revert this and a handful of other amd64/ata_cam/zfs >>>>> commits to see if this goes away, but I won't be getting to that = before >>>>> next Sunday probably as this is my file server and DNS server = now.>>>=20 >>>> I ran into the issue going from vanilla 9.2-RELEASE-p10 to >>>> 9.3-RELEASE as well :(. I=92ve filed this bug to track the = issue: >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192183 . = I=92ll >>>> see if GENERIC can boot my system sometime this week (the = KERNCONF >>>> has been working for several releases, but it could be an = issue >>>> with that that=92s being overlooked by accident).>>=20 >>>> Thanks! >>=20 >> ... >>=20 >>> Also, you would need to get verbose dmesg's of old and new kernels = as a >>> first step in narrowing it down. >> I can't do trivial debugging because my USB keyboard doesn't work at >> the mountroot prompt ( >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D133989 ), I don't >> have a PS/2 keyboard, and the system only has VGA access :(. I'll try >> working on disabling the PS/2 controller in the BIOS and a few other >> things to force the system to stop ignoring the USB keyboard to get >> scrollback, because that appeared to work for some folks with this >> issue according to the ukbd bug I referenced. >=20 > Do you have a serial port so you could use a serial console (or is = this a=20 > laptop)? I wish my motherboard had an RS232 port, but unfortunately it doesn=92t; = I don=92t have 2 USB RS-232 converters either (and I=92m not sure a USB = serial adapter would work for boot2sio, would it?) :/. If the legacy USB keyboard route doesn=92t work out, I have a USB to = PS/2 converter coming in the mail. It would be nice if bug 133989 was fixed. I=92ll talk to hps@ about it=85 Thanks! -Garrett= From owner-freebsd-stable@FreeBSD.ORG Thu Jul 31 01:39:40 2014 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 ESMTPS id 3651BE70 for ; Thu, 31 Jul 2014 01:39:40 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B4C62098 for ; Thu, 31 Jul 2014 01:39:40 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 68E42A654; Wed, 30 Jul 2014 18:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1406770779; x=1406785179; bh=0bp57e9xW30xV4ADHsMFYk0h5x98e9xcvdL+0lFo8i8=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=0xw2SNujNyxaaAnoNjJNtRJgZUfeEy5sg8HDfvDNTjkclBOlVyKfh3bcRJ28RR68T TmqwS01Mw+pYSmxrJVDaQFu3qEsXvDRLCHlOLPoFERzH41px9qfuYC/mMo/iwkb/Mk ev1pucXskid2RVhazQY5A8PE7RNRZlMWWRq2wfyQ= Message-ID: <53D99E5A.10702@delphij.net> Date: Wed, 30 Jul 2014 18:39:38 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Michael Jung , "freebsd-stable@freebsd.org" Subject: Re: r269147 fails to boot after ZFS pool upgrade and new boot code installation References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 31 Jul 2014 01:39:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07/29/14 07:04, Michael Jung wrote: > Everyone, > > The freebsd-fs was silent about this post so I'm hoping someone > will chime in here. > > 10-stable r269147: Upgraded the zfs pool to 5000 and installed new > bootcode. The system was working fine prior to upgrading the pool. > > NOTE: Due to the BIOS not supporting drives > 2TB in ACHI mode > this MB is running in legacy IDE mode. I understand the speed > implications of this - it is just a test box. > > ZFS MIRROR BOOT ada0/ada1 > > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad0 gpart > bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad1 > > Loading Operating System ... ZFS: i/o error - all block copies > unavailable ZFS: can't read object set for dataset u ZFS: can't > open root filesystem gptzsboot: failed to mount default pool zroot > > FreBSD/x86 boot Default zroot: boot: > > I tried to recover using > > FreeBSD-Stable USB Live CD r268571 but could not import the pool. The feature was merged in r268649 so this is expected. > FreeBSD-11-Current r268622 LIVE CD (USB) imports the pool fine. > > Only two mirrored drives attached to onboard SATA. Both drives > show up in = BIOS as first two boot devices. > > I attempted to install the r269147 bootcode again like: > > # zpool import -f -N zroot # mkdir /tmp/zroot # mount -r -t zfs > zroot/ROOT/default /tmp/zroot # gpart bootcode -b > /tmp/zroot/boot/pmbr -p /tmp/zroot/boot/gptzfsboot -i 1= ada0 # > gpart bootcode -b /tmp/zroot/boot/pmbr -p > /tmp/zroot/boot/gptzfsboot -i 1= ada1 > > > but resulted in same problem. I also tried installing 11-current > bootcode = r268622 which also fails to boot. > > (I did not export the pool. I even tried power reset after writing > bootcod= e) This shouldn't matter. > gpart list/show: > > > 34 5860533101 ada0 GPT (2.7T) > > 34 6 - free - (3.0K) > > 40 1024 1 freebsd-boot (512K) > > 1064 25165824 2 freebsd-swap (12G) > > 25166888 5835366240 3 freebsd-zfs (2.7T) > > 5860533128 7 - free - (3.5K) Just a wild guess -- how much space have you used in the pool? And what's the exact BIOS limitation on 2TB drives? I'm asking because the gptzfsboot stage, there is no driver present and the system still rely on BIOS's functionality to do disk access. If the data is located outside BIOS's reach -- there are some strange ones of them, like 137GB, 2TiB, etc., then the gptzfsboot may not be able to read data from the pool if it has to reach out these portion of disk. Note that it's generally a good idea to use a small, dedicated zfs pool located at the beginning of disk(s) as root pool anyways. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0 iQIcBAEBCgAGBQJT2Z5aAAoJEJW2GBstM+nsePwP/AhJCWmyVOJwb0hTTtwnKV8O eqJNe2u5NwBns+5kSSCDnYKodgOlq2MXaW5UFswg+Rh6Qiyze/xyj1UBHq+oA5rR YBNgh5XwAxGfdWeSO/26WLtylRjwcnYoqjUpbWauqpvxjxOd7AoAkaXUz6BkIu26 tKhjJnN4kiUdhUsHmWP4A2PU/sRqetWIp/MusgR4+NLVhI6Gw6G+RbRo+YFXPbPO KTKMOJeg+bGX8W4SUMM3MVWKNh8ju37IYo5cqBN1EfYgr3CT/y7uSQes+v3iC8nQ jYsghIp4YMZzh8NDLAPX83cBb6FsXNjd17HmByX+kagOYEDP8/fe7dsuXm0KYTYF dtAeGRuup6Gl2RNyfbo2z/INXgWYUPlT5I4a9b7bohLK2bCm2MQZ/IUER3NYjx2b +BqvCwn7P21V54e+iXbMCdQYyXf0fAkNqVFxsoIjHPxPD9wLPHx7+KF+um0Qrpm5 luGLtV9j4t1xOCyxsGZmndDPKgFfVtnNq/5Ykj+cD2oJhIQc7UZwa2UfahO0NwPb tmkZEtkkwD/H0pRcWx8Os51Adm9anXzbhwXF33HZaaF8sXnsgIgaAv1clwC4gEI5 g1r6mGEN3J2ty49Y7xDqQ3FVwj8VVSZ6PObKhgtWnS05CFI4OPtIyjOlD8FSj4tr BnNsREoSSsQKgGDUzz3J =stUo -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Aug 1 14:45:09 2014 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 ESMTPS id AC4EF97B for ; Fri, 1 Aug 2014 14:45:09 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 38EF8295B for ; Fri, 1 Aug 2014 14:45:09 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s71Ej5Ht064664 for ; Fri, 1 Aug 2014 16:45:05 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 8A45A38A2; Fri, 1 Aug 2014 16:45:05 +0200 (CEST) Message-ID: <53DBA7F0.90502@omnilan.de> Date: Fri, 01 Aug 2014 16:45:04 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "freebsd-stable@freebsd.org" Subject: 'zfs snapshot' interfering with make_dev() 63 character limit X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7C4D2C1D51B74B152187CF41" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Fri, 01 Aug 2014 16:45:05 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 14:45:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7C4D2C1D51B74B152187CF41 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, doing 'zfs snapshot' allows me a snapname length longer than make_dev_p() accepts (63 past /dev/). This leads to the situation that I can create a snashot of a zvol, but afterwards it's not accessable because there's no dev available: g_dev_taste: make_dev_p() failed (gp->name=3Dzvol/=E2=80=A6@test63limit, = error=3D63) Is it desirable to allow longer dev names or limit snapshot names for zfs volumes? I haven't looked what zfs limits are, but I frequently have zfs names longer than 63 characters=E2=80=A6 Bad choosen? Or do others too have the= need for longer dev names? Thanks, -Harry --------------enig7C4D2C1D51B74B152187CF41 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlPbp/EACgkQLDqVQ9VXb8grJwCfXArYE9njAOA8UDiRqELipLus MSoAoLqF4q7SsZucnZPRj5/PBWsg/ck6 =C9T7 -----END PGP SIGNATURE----- --------------enig7C4D2C1D51B74B152187CF41-- From owner-freebsd-stable@FreeBSD.ORG Fri Aug 1 15:53:55 2014 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 ESMTPS id 4E564F4F for ; Fri, 1 Aug 2014 15:53:55 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E561421DF for ; Fri, 1 Aug 2014 15:53:54 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 4C4F91FE027 for ; Fri, 1 Aug 2014 17:53:51 +0200 (CEST) Message-ID: <53DBB82B.70802@selasky.org> Date: Fri, 01 Aug 2014 17:54:19 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: FreeBSD Stable Subject: [RFC] Partial MFC of SYSCTL changes in -current Content-Type: multipart/mixed; boundary="------------000409020107080108090808" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 15:53:55 -0000 This is a multi-part message in MIME format. --------------000409020107080108090808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Partial MFC of r267961, r267973, r267985, r267992, r267993, r268005: Backport some macro definitions so to make backporting code from FreeBSD head easier. MFC after: 1 week Any objections? --HPS --------------000409020107080108090808 Content-Type: text/x-diff; name="sysctl_mfc.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sysctl_mfc.diff" Index: sys/kern/kern_mib.c =================================================================== --- sys/kern/kern_mib.c (revision 269386) +++ sys/kern/kern_mib.c (working copy) @@ -55,35 +55,35 @@ #include #include -SYSCTL_NODE(, 0, sysctl, CTLFLAG_RW, 0, +SYSCTL_ROOT_NODE(0, sysctl, CTLFLAG_RW, 0, "Sysctl internal magic"); -SYSCTL_NODE(, CTL_KERN, kern, CTLFLAG_RW|CTLFLAG_CAPRD, 0, +SYSCTL_ROOT_NODE(CTL_KERN, kern, CTLFLAG_RW|CTLFLAG_CAPRD, 0, "High kernel, proc, limits &c"); -SYSCTL_NODE(, CTL_VM, vm, CTLFLAG_RW, 0, +SYSCTL_ROOT_NODE(CTL_VM, vm, CTLFLAG_RW, 0, "Virtual memory"); -SYSCTL_NODE(, CTL_VFS, vfs, CTLFLAG_RW, 0, +SYSCTL_ROOT_NODE(CTL_VFS, vfs, CTLFLAG_RW, 0, "File system"); -SYSCTL_NODE(, CTL_NET, net, CTLFLAG_RW, 0, +SYSCTL_ROOT_NODE(CTL_NET, net, CTLFLAG_RW, 0, "Network, (see socket.h)"); -SYSCTL_NODE(, CTL_DEBUG, debug, CTLFLAG_RW, 0, +SYSCTL_ROOT_NODE(CTL_DEBUG, debug, CTLFLAG_RW, 0, "Debugging"); SYSCTL_NODE(_debug, OID_AUTO, sizeof, CTLFLAG_RW, 0, "Sizeof various things"); -SYSCTL_NODE(, CTL_HW, hw, CTLFLAG_RW, 0, +SYSCTL_ROOT_NODE(CTL_HW, hw, CTLFLAG_RW, 0, "hardware"); -SYSCTL_NODE(, CTL_MACHDEP, machdep, CTLFLAG_RW, 0, +SYSCTL_ROOT_NODE(CTL_MACHDEP, machdep, CTLFLAG_RW, 0, "machine dependent"); -SYSCTL_NODE(, CTL_USER, user, CTLFLAG_RW, 0, +SYSCTL_ROOT_NODE(CTL_USER, user, CTLFLAG_RW, 0, "user-level"); -SYSCTL_NODE(, CTL_P1003_1B, p1003_1b, CTLFLAG_RW, 0, +SYSCTL_ROOT_NODE(CTL_P1003_1B, p1003_1b, CTLFLAG_RW, 0, "p1003_1b, (see p1003_1b.h)"); -SYSCTL_NODE(, OID_AUTO, compat, CTLFLAG_RW, 0, +SYSCTL_ROOT_NODE(OID_AUTO, compat, CTLFLAG_RW, 0, "Compatibility code"); -SYSCTL_NODE(, OID_AUTO, security, CTLFLAG_RW, 0, +SYSCTL_ROOT_NODE(OID_AUTO, security, CTLFLAG_RW, 0, "Security"); #ifdef REGRESSION -SYSCTL_NODE(, OID_AUTO, regression, CTLFLAG_RW, 0, +SYSCTL_ROOT_NODE(OID_AUTO, regression, CTLFLAG_RW, 0, "Regression test MIB"); #endif Index: sys/sys/sysctl.h =================================================================== --- sys/sys/sysctl.h (revision 269386) +++ sys/sys/sysctl.h (working copy) @@ -92,6 +92,7 @@ #define CTLFLAG_CAPRD 0x00008000 /* Can be read in capability mode */ #define CTLFLAG_CAPWR 0x00004000 /* Can be written in capability mode */ #define CTLFLAG_STATS 0x00002000 /* Statistics, not a tuneable */ +#define CTLFLAG_NOFETCH 0x00001000 /* Don't fetch tunable from getenv() */ #define CTLFLAG_CAPRW (CTLFLAG_CAPRD|CTLFLAG_CAPWR) /* @@ -206,6 +207,7 @@ /* Hide these in macros. */ #define SYSCTL_CHILDREN(oid_ptr) \ (struct sysctl_oid_list *)(oid_ptr)->oid_arg1 +#define SYSCTL_PARENT(oid_ptr) NULL /* not supported */ #define SYSCTL_CHILDREN_SET(oid_ptr, val) (oid_ptr)->oid_arg1 = (val) #define SYSCTL_STATIC_CHILDREN(oid_name) (&sysctl_##oid_name##_children) @@ -296,6 +298,10 @@ #define SYSCTL_ADD_OID(ctx, parent, nbr, name, kind, a1, a2, handler, fmt, descr) \ sysctl_add_oid(ctx, parent, nbr, name, kind, a1, a2, handler, fmt, __DESCR(descr)) +/* This constructs a root node from which other nodes can hang. */ +#define SYSCTL_ROOT_NODE(nbr, name, access, handler, descr) \ + SYSCTL_NODE(, nbr, name, access, handler, descr) + /* This constructs a node from which other oids can hang. */ #define SYSCTL_NODE(parent, nbr, name, access, handler, descr) \ struct sysctl_oid_list SYSCTL_NODE_CHILDREN(parent, name); \ @@ -302,6 +308,9 @@ SYSCTL_OID(parent, nbr, name, CTLTYPE_NODE|(access), \ (void*)&SYSCTL_NODE_CHILDREN(parent, name), 0, handler, "N", descr) +#define SYSCTL_ADD_ROOT_NODE(ctx, nbr, name, access, handler, descr) \ + SYSCTL_ADD_NODE(ctx, SYSCTL_STATIC_CHILDREN(), nbr, name, access, handler, descr) + #define SYSCTL_ADD_NODE(ctx, parent, nbr, name, access, handler, descr) \ sysctl_add_oid(ctx, parent, nbr, name, CTLTYPE_NODE|(access), \ NULL, 0, handler, "N", __DESCR(descr)) Index: . =================================================================== --- . (revision 269386) +++ . (working copy) Property changes on: . ___________________________________________________________________ Modified: svn:mergeinfo Merged /head:r267961,267973,267985,267992-267993,268005 --------------000409020107080108090808-- From owner-freebsd-stable@FreeBSD.ORG Fri Aug 1 21:36:51 2014 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 ESMTPS id 1C58B778 for ; Fri, 1 Aug 2014 21:36:51 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id D87182A22 for ; Fri, 1 Aug 2014 21:36:50 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAAsI3FODaFve/2dsb2JhbABbhDqCdNBpgSJ3hC2BCwINGQJfiFWhZY8rl1gXgSyNbIM0gVIFsFSDZSGBdA X-IronPort-AV: E=Sophos;i="5.01,782,1400040000"; d="scan'208";a="144908507" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 01 Aug 2014 17:36:43 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id EB0A579294 for ; Fri, 1 Aug 2014 17:36:43 -0400 (EDT) Date: Fri, 1 Aug 2014 17:36:43 -0400 (EDT) From: Rick Macklem To: freebsd-stable Message-ID: <758128830.6432172.1406929003953.JavaMail.root@uoguelph.ca> Subject: HEADSUP: NFSv4.1 server merge into stable/10 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 21:36:51 -0000 Hi, I just did a rather large MFC from head to stable/10 of the NFSv4.1 server. I also bumped __FreeBSD_version, since this MFC changes the internal function call interfaces between the NFS and krpc related modules. This patch hasn't caused problems for head as far as I know, but it is pretty large, so I thought I'd let people know. rick From owner-freebsd-stable@FreeBSD.ORG Fri Aug 1 22:03:16 2014 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 ESMTPS id 523A9F6A for ; Fri, 1 Aug 2014 22:03:16 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1962B2D7A for ; Fri, 1 Aug 2014 22:03:16 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XDKuv-000ETy-8i for freebsd-stable@freebsd.org; Fri, 01 Aug 2014 22:03:13 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1XDKuv-000Mvc-6Q for freebsd-stable@freebsd.org; Fri, 01 Aug 2014 23:03:13 +0100 To: freebsd-stable@freebsd.org Subject: Is it possible to get xf86-video-ati-7.2 added to the new_xorg pkg repository ? Message-Id: From: Pete French Date: Fri, 01 Aug 2014 23:03:13 +0100 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 22:03:16 -0000 After the help I got a few eeks ago I have been using this quite happily with new_xorg, using the patch for ports I was sent and building by hand. But it wold be nie to get it added to the new_xorg repository so that I could just use biary packages - preseumably this affects all ATI usrs trying to use that repository actually ? any chance ? thanks, -pete. From owner-freebsd-stable@FreeBSD.ORG Fri Aug 1 23:42:09 2014 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 ESMTPS id 2CE24DCF for ; Fri, 1 Aug 2014 23:42:09 +0000 (UTC) Received: from hades.sorbs.net (hades.sorbs.net [67.231.146.201]) by mx1.freebsd.org (Postfix) with ESMTP id 1CB75288E for ; Fri, 1 Aug 2014 23:42:08 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0N9N00E5PJC38V00@hades.sorbs.net> for freebsd-stable@freebsd.org; Fri, 01 Aug 2014 16:45:40 -0700 (PDT) Message-id: <53DC25C7.3000006@shellsshots.com> Date: Sat, 02 Aug 2014 01:41:59 +0200 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: freebsd-stable@freebsd.org Subject: Panic/core... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 23:42:09 -0000 Thoughts anyone: any thoughts anyone: http://www.mhix.org/Guest-Cores/core.txt.0 ? (the other files from the dump are there as well) This was a guest OS in Virtualbox running 4.3.12 on a FreeBSD platform. (I have about 12 VMs and see various zfs panics on each and have been trying to determine the cause, GuestOS, Vbox, HostOS - or all three doing their little bit and just making everything worse together.) Regards, Michelle -- Michelle Sullivan http://www.mhix.org/