Re: tmpfs deadlock on stable/9
On Thu, 8 Dec 2011, Dmitry Morozovsky wrote: It is available at http://bsd.woozle.net/tmpfs-lock-20111207.txt (~260k) BTW, at least some of the debugger commands referenced (show locks, show alllocks) are no longer exist This means that you do not have witness in your kernel. Look at the reference I pointed you once more. Ah I see, my bad. I'll test this with WITNESS-enabled kernel tomorrow and return with updated results. Hmm, I'd rebuilt kernel with WITNESS/WITNESS_SKIPSPIN and can't reproduce this deadlock. Will try further. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
WITHOUT_OPENSSH=true in src.conf
Hi, on my 9.0-PRERELEASE I'm trying to build a system stripped off several things from world, I'd rather like to install via ports (bind9, ssh and others). If I put WITHOUT_BIND into src.conf, the world ist built without bind, after installworld I can call make delete-old and make delete-old-libs and the remains of the base supplied bind get removed, thus leaving me with the one I installed from ports. I tried the same for WITHOUT_OPENSSH. make delete-old(-libs) doesn't remove the old ssh related files from the base. The thigs don't get build/updated, thus leaving you with old binaries/libs around, the old ssh binary taking preference in the default PATH over the one installed from ports. Sure, I can remove the old ones manually or use the overwrite base option in the openssh ports, but this seems a POLA violation to me? - Oliver -- | Oliver Brandmueller http://sysadm.in/ o...@sysadm.in | |Ich bin das Internet. Sowahr ich Gott helfe. | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: tmpfs deadlock on stable/9
On Thu, 8 Dec 2011, Dmitry Morozovsky wrote: It is available at http://bsd.woozle.net/tmpfs-lock-20111207.txt (~260k) BTW, at least some of the debugger commands referenced (show locks, show alllocks) are no longer exist This means that you do not have witness in your kernel. Look at the reference I pointed you once more. Ah I see, my bad. I'll test this with WITNESS-enabled kernel tomorrow and return with updated results. Hmm, I'd rebuilt kernel with WITNESS/WITNESS_SKIPSPIN and can't reproduce this deadlock. Will try further. On the other hand, after boot I see several LORs: Dec 8 02:34:18 kern.crit beaver kernel: lock order reversal: Dec 8 02:34:18 kern.crit beaver kernel: 1st 0xfe005163b818 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:829 Dec 8 02:34:18 kern.crit beaver kernel: 2nd 0xfe005163cbd8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2166 Dec 8 02:34:18 kern.crit beaver kernel: KDB: stack backtrace: Dec 8 02:34:18 kern.crit beaver kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Dec 8 02:34:18 kern.crit beaver kernel: kdb_backtrace() at kdb_backtrace+0x37 Dec 8 02:34:18 kern.crit beaver kernel: _witness_debugger() at _witness_debugger+0x2c Dec 8 02:34:18 kern.crit beaver kernel: witness_checkorder() at witness_checkorder+0x651 Dec 8 02:34:18 kern.crit beaver kernel: __lockmgr_args() at __lockmgr_args+0xb98 Dec 8 02:34:18 kern.crit beaver kernel: vop_stdlock() at vop_stdlock+0x39 Dec 8 02:34:18 kern.crit beaver kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0x46 Dec 8 02:34:18 kern.crit beaver kernel: _vn_lock() at _vn_lock+0x47 Dec 8 02:34:18 kern.crit beaver kernel: vget() at vget+0x56 Dec 8 02:34:18 kern.crit beaver kernel: devfs_allocv() at devfs_allocv+0x13f Dec 8 02:34:18 kern.crit beaver kernel: devfs_root() at devfs_root+0x4d Dec 8 02:34:18 kern.crit beaver kernel: vfs_donmount() at vfs_donmount+0xdcb Dec 8 02:34:18 kern.crit beaver kernel: sys_nmount() at sys_nmount+0x63 Dec 8 02:34:18 kern.crit beaver kernel: amd64_syscall() at amd64_syscall+0x25a Dec 8 02:34:18 kern.crit beaver kernel: Xfast_syscall() at Xfast_syscall+0xf7 Dec 8 02:34:18 kern.crit beaver kernel: --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x800ab5ecc, rsp = 0x7fffccc8, rbp = 0x801009048 --- Dec 8 02:34:29 kern.crit beaver kernel: 4-i386.lab.rinet.ru Dec 8 02:34:32 kern.crit beaver kernel: 6-i386.lab.rinet.ru. Dec 8 02:41:15 kern.crit beaver kernel: lock order reversal: Dec 8 02:41:15 kern.crit beaver kernel: 1st 0xfe004ea069f8 tmpfs (tmpfs) @ /usr/src/sys/fs/nullfs/null_vnops.c:597 Dec 8 02:41:15 kern.crit beaver kernel: 2nd 0xfe019db46bd8 zfs (zfs) @ /usr/src/sys/fs/nullfs/null_vnops.c:597 Dec 8 02:41:15 kern.crit beaver kernel: KDB: stack backtrace: Dec 8 02:41:15 kern.crit beaver kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Dec 8 02:41:15 kern.crit beaver kernel: kdb_backtrace() at kdb_backtrace+0x37 Dec 8 02:41:15 kern.crit beaver kernel: _witness_debugger() at _witness_debugger+0x2c Dec 8 02:41:15 kern.crit beaver kernel: witness_checkorder() at witness_checkorder+0x651 Dec 8 02:41:15 kern.crit beaver kernel: __lockmgr_args() at __lockmgr_args+0xb98 Dec 8 02:41:15 kern.crit beaver kernel: vop_stdlock() at vop_stdlock+0x39 Dec 8 02:41:15 kern.crit beaver kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0x46 Dec 8 02:41:15 kern.crit beaver kernel: null_lock() at null_lock+0xbb Dec 8 02:41:15 kern.crit beaver kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0x46 Dec 8 02:41:15 kern.crit beaver kernel: _vn_lock() at _vn_lock+0x47 Dec 8 02:41:15 kern.crit beaver kernel: nullfs_root() at nullfs_root+0x45 Dec 8 02:41:15 kern.crit beaver kernel: vfs_donmount() at vfs_donmount+0xdcb Dec 8 02:41:15 kern.crit beaver kernel: sys_nmount() at sys_nmount+0x63 Dec 8 02:41:15 kern.crit beaver kernel: amd64_syscall() at amd64_syscall+0x25a Dec 8 02:41:15 kern.crit beaver kernel: Xfast_syscall() at Xfast_syscall+0xf7 Dec 8 02:41:15 kern.crit beaver kernel: --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x8008a1ecc, rsp = 0x7fffceb8, rbp = 0x7fffcf30 --- Dec 8 02:41:16 kern.crit beaver kernel: lock order reversal: Dec 8 02:41:16 kern.crit beaver kernel: 1st 0xfe0171868638 tmpfs (tmpfs) @ /usr/src/sys/fs/nullfs/null_vnops.c:597 Dec 8 02:41:16 kern.crit beaver kernel: 2nd 0xfe004ea0ebd8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2166 Dec 8 02:41:16 kern.crit beaver kernel: KDB: stack backtrace: Dec 8 02:41:16 kern.crit beaver kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Dec 8 02:41:16 kern.crit beaver kernel: kdb_backtrace() at kdb_backtrace+0x37 Dec 8 02:41:16 kern.crit beaver kernel: _witness_debugger() at _witness_debugger+0x2c Dec 8 02:41:16 kern.crit beaver kernel: witness_checkorder() at witness_checkorder+0x651 Dec 8 02:41:16 kern.crit beaver kernel: __lockmgr_args() at __lockmgr_args+0xb98 Dec 8 02:41:16 kern.crit beaver kernel:
FreeBSD 9.0-RC3 Available...
The third and what should be final Release Candidate build for the 9.0-RELEASE release cycle is now available. Since this is the beginning of a brand new branch (stable/9) I cross-post the announcements to both -current and -stable. But just so you know most of the developers active in head and stable/9 pay more attention to the -current mailing list. If you notice problems you can report them through the normal Gnats PR system or on the -current mailing list. This should be the last of the test builds. We hope to begin the final release builds in about a week. The 9.0-RELEASE cycle will be tracked here: http://wiki.freebsd.org/Releng/9.0TODO The location of the FTP install tree and ISOs is the same as it has been for BETA2/BETA3/RC1/RC2. The layout to a large degree is being dictated by the new build infrastructure and installer. But it's not particularly well suited to humans so I've added a shorter pathway to the ISOs. Unless there are lots of complaints about the layout we'll stick with this for the release. ISO images for amd64, i386, ia64, powerpc, powerpc64, and sparc64 are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.0/ That directory is a set of symbolic links to the ISO images for all of the supported architectures, and checksum files (for example there is a symlink named CHECKSUM.MD5-amd64 that points to the CHECKSUM.MD5 file for the amd64 architecture). MD5/SHA256 checksums are tacked on below. If you would like to use csup/cvsup mechanisms to access the source tree the branch tag to use is now RELENG_9_0, if you use . (head) you will get 10-CURRENT. If you would like to access the source tree via SVN it is svn://svn.freebsd.org/base/releng/9.0/. We still have the nit that the creation of a new SVN branch winds up causing what looks like a check-in of the entire tree in CVS (a side-effect of the svn2cvs exporter) so mergemaster -F is your friend if you are using csup/cvsup. FreeBSD Update -- The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 7.[34]-RELEASE, 8.[12]-RELEASE, 9.0-BETA[123], or 9.0-RC[1,2] can upgrade as follows: First, a minor change must be made to the freebsd-update code in order for it to accept file names appearing in FreeBSD 9.0 which contain the '%' and '@' characters; without this change, freebsd-update will error out with the message The update metadata is correctly signed, but failed an integrity check. # sed -i '' -e 's/=_/=%@_/' /usr/sbin/freebsd-update Now freebsd-update can fetch bits belonging to 9.0-RC3. During this process freebsd-update will ask for help in merging configuration files. # freebsd-update upgrade -r 9.0-RC3 Due to changes in the way that FreeBSD is packaged on the release media, two complications may arise in this process if upgrading from FreeBSD 7.x or 8.x: 1. The FreeBSD kernel, which previously could appear in either /boot/kernel or /boot/GENERIC, now only appears as /boot/kernel. As a result, any kernel appearing in /boot/GENERIC will be deleted. Please carefully read the output printed by freebsd-update and confirm that an updated kernel will be placed into /boot/kernel before proceeding beyond this point. 2. The FreeBSD source tree in /usr/src (if present) will be deleted. (Normally freebsd-update will update a source tree, but in this case the changes in release packaging result in freebsd-update not recognizing that the source tree from the old release and the source tree from the new release correspond to the same part of FreeBSD.) # freebsd-update install The system must now be rebooted with the newly installed kernel before the non-kernel components are updated. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install At this point, users of systems being upgraded from FreeBSD 8.2-RELEASE or earlier will be prompted by freebsd-update to rebuild all third-party applications (e.g., ports installed from the ports tree) due to updates in system libraries. After updating installed third-party applications (and again, only if freebsd-update printed a message indicating that this was necessary), run freebsd-update again so that it can delete the old (no longer used) system libraries: # freebsd-update install Finally, reboot into 9.0-RC3: Checksums: MD5 (FreeBSD-9.0-RC3-amd64-bootonly.iso) = 53f2bc5a3d18124769bfb066e921559a MD5 (FreeBSD-9.0-RC3-amd64-disc1.iso) = b88eca54341523713712b184c6a7fc9a MD5 (FreeBSD-9.0-RC3-amd64-memstick.img) = a9b58348736d4a7a179941e818d33986 MD5 (FreeBSD-9.0-RC3-i386-bootonly.iso) = 86f0410ffb1c55fcb8faf33814e6e95b MD5 (FreeBSD-9.0-RC3-i386-disc1.iso) = 3585047256b1b8f72319aa55ffa3c3ad MD5 (FreeBSD-9.0-RC3-i386-memstick.img) = 8be95b49c498e666f87957a8c10997ce MD5 (FreeBSD-9.0-RC3-ia64-bootonly.iso) = 7a8e99a61d21ae8a5f6be9fb7f878b11 MD5 (FreeBSD-9.0-RC3-ia64-memstick) =
