Re: [Call for testers] DRM device-independent code update to Linux 3.8
The -h patch Works for me, tested on a mac book pro. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
FreeBSD FUSE calls truncate() on read-only files
Hi, this came up when trying to port tup (https://github.com/gittup/tup) to FreeBSD. Even though we are opening the file read-only with cat, FUSE calls truncate() on it, which modifies its mtime and this screws up tup. See https://github.com/gittup/tup/issues/198 Anyone know why FreeBSD's FUSE is doing this? Thanks, Lars signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Shared object libsodium.so.13 not found, required by, dnscrypt-proxy
Although I'm not on CURRENT, I can reproduce this problem on my PC's running 10.1-RELEASE. It started on 31st January on only 1 PC and then appeared on others after a few days. I update ports on a daily basis, so that may be a hint. Strangely, only 3 of 5 of my computers are affected. Once it appears during a reboot, it never goes away during other reboots, so manual start of dnscrypt-proxy is required. The same also happens with fuse on another computer, but that is a separate issue. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
r279278 failed to build (yacc: maximum table size exceeded)
I have clean svn tree with base/head branch. I try to build world, but I have some mysterious bugs. The latest is yacc failed to make c file on phase 4.3: === usr.sbin/acpi/iasl (depend) m4 -P -I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslparser.y aslcompiler.y yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y yacc: 89 shift/reduce conflicts. yacc: f - maximum table size exceeded *** Error code 2 /etc/make.conf is /dev/null. I've also tried empty /etc/src.conf with no luck. -- Eir Nym ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r279278 failed to build (yacc: maximum table size exceeded)
On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin wrote: I have clean svn tree with base/head branch. I try to build world, but I have some mysterious bugs. The latest is yacc failed to make c file on phase 4.3: === usr.sbin/acpi/iasl (depend) m4 -P -I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslparser.y aslcompiler.y yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y yacc: 89 shift/reduce conflicts. yacc: f - maximum table size exceeded *** Error code 2 /etc/make.conf is /dev/null. I've also tried empty /etc/src.conf with no luck. Out of curiosity, is your src tree mounted via NFS? Glen pgpH8fbYd6jcE.pgp Description: PGP signature
Re: pcie Realtek 8168G issues (re driver)
Hi, thanks you all for the replies. Unfortunately, the network chip is still not working and I updated the PR (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535) with the last tests. It seems that received packets are not transferred to mbuf or they are transferred, but later, after the mbuf is already freed; moreover, the ring entries are written without looping, overwriting and messing up the whole kernel memory. It looks like a DMA issues, but Apparently it seems a hardware error, but using a Linux distro, it works :( Has someone maybe any other ideas? In the meanwhile I'll get another board with the same chip :O Best regards, Luca On Tue, Feb 17, 2015 at 7:31 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Am Tue, 17 Feb 2015 18:32:22 +0100 Luca Pizzamiglio luca.pizzamig...@gmail.com schrieb: Hi Ben, thanks for the tip! tso was already disabled. I tried anyway and unfortunately it crashes as before. I filled a bug report (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535) and marius@ is giving me a big help on it. Best regards, Luca On Fri, Feb 13, 2015 at 7:34 PM, Ben Perrault ben.perra...@gmail.com wrote: Luca, I've had the same issue with this interface on both PCIe boards and embedded in a handful of Lenovo products. The one, fairly ugly workaround I've found that makes it work well enough is disable tso ( i.e. ifconfig re0 down ifconfig re0 -tso ifconfig re0 up ). This also seems to stop the panics under current. I'm not sure it will work for you - but it has on everyone of those interfaces I've dealt with. Good luck, -bp On Feb 13, 2015, at 8:06 AM, Luca Pizzamiglio luca.pizzamig...@gmail.com wrote: Hi, I'm Luca, I've some issues using a PCIe Realtek Ethernet board: re0@pci0:3:0:0: class=0x02 card=0x012310ec chip=0x816810ec rev=0x0c hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0x1000, size 256, enabled bar [18] = type Memory, range 64, base 0x9050, size 4096, enabled bar [20] = type Prefetchable Memory, range 64, base 0x9040, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 2 endpoint IRQ 1 max data 128(128) link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) cap 11[b0] = MSI-X supports 4 messages Table in map 0x20[0x0], PBA in map 0x20[0x800] cap 03[d0] = VPD ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC0 ecap 0003[160] = Serial 1 0100684ce000 ecap 0018[170] = LTR 1 Rx and Tx don't work. After some minutes the interface is activated I get kernel panic. I've already tried to disable MSIx and MSI. It seems a DMA problem, rx fill the 256 descriptors and the nothing else until the panic. netstat -s shows now new packets. I filled a bug report with more infos: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535 could someone kindly pointing some ideas? Best regards, Luca ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org In September 2014 I filed allready a bug acoording to strange behaviour with a Lenovo ThinkPad E540 with a Realtek chip: Bug 193743 - RTL8111/8168B PCI Express Gigabit Ethernet controller: doesn't work properly, problems getting UP automatically ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r279278 failed to build (yacc: maximum table size exceeded)
В Wed, 25 Feb 2015 15:43:27 + Glen Barber g...@freebsd.org пишет: On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin wrote: I have clean svn tree with base/head branch. I try to build world, but I have some mysterious bugs. The latest is yacc failed to make c file on phase 4.3: === usr.sbin/acpi/iasl (depend) m4 -P -I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslparser.y aslcompiler.y yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y yacc: 89 shift/reduce conflicts. yacc: f - maximum table size exceeded *** Error code 2 /etc/make.conf is /dev/null. I've also tried empty /etc/src.conf with no luck. Out of curiosity, is your src tree mounted via NFS? Glen I have a similar problem on revision /usr/src # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213 Node Kind: directory Schedule: normal Last Changed Author: glebius Last Changed Rev: 279213 Last Changed Date: 2015-02-23 20:57:09 +0200 (Mon, 23 Feb 2015) http://pastebin.com/FuAUkBmX Source tree is on the zfs /usr/src # zfs list zroot/usr/src NAMEUSED AVAIL REFER MOUNTPOINT zroot/usr/src 1.35G 408G 1.35G /usr/src what is most surprising, the same revision successfully building for the other 2 computers, including amd64|zfs and i386|ufs. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r279278 failed to build (yacc: maximum table size exceeded)
On 2015-02-25 11:22, Ivan Klymenko wrote: В Wed, 25 Feb 2015 15:43:27 + Glen Barber g...@freebsd.org пишет: On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin wrote: I have clean svn tree with base/head branch. I try to build world, but I have some mysterious bugs. The latest is yacc failed to make c file on phase 4.3: === usr.sbin/acpi/iasl (depend) m4 -P -I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslparser.y aslcompiler.y yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y yacc: 89 shift/reduce conflicts. yacc: f - maximum table size exceeded *** Error code 2 /etc/make.conf is /dev/null. I've also tried empty /etc/src.conf with no luck. Out of curiosity, is your src tree mounted via NFS? Glen I have a similar problem on revision /usr/src # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213 Node Kind: directory Schedule: normal Last Changed Author: glebius Last Changed Rev: 279213 Last Changed Date: 2015-02-23 20:57:09 +0200 (Mon, 23 Feb 2015) http://pastebin.com/FuAUkBmX Source tree is on the zfs /usr/src # zfs list zroot/usr/src NAMEUSED AVAIL REFER MOUNTPOINT zroot/usr/src 1.35G 408G 1.35G /usr/src what is most surprising, the same revision successfully building for the other 2 computers, including amd64|zfs and i386|ufs. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org I am having the same problem building r279268 on r269358 Revision: 279268 Last Changed Author: arybchik Last Changed Rev: 279268 Last Changed Date: 2015-02-25 06:20:42 + (Wed, 25 Feb 2015) not over NFS or anything, local ZFS. === usr.bin/dirname (depend) --- usr.sbin.depend__D --- yacc: f - maximum table size exceeded *** [aslcompilerparse.c] Error code 2 make[5]: stopped in /usr/src/usr.sbin/acpi/iasl 1 error -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: r279278 failed to build (yacc: maximum table size exceeded)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/25/2015 11:22, Ivan Klymenko wrote: В Wed, 25 Feb 2015 15:43:27 + Glen Barber g...@freebsd.org пишет: On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin wrote: I have clean svn tree with base/head branch. I try to build world, but I have some mysterious bugs. The latest is yacc failed to make c file on phase 4.3: === usr.sbin/acpi/iasl (depend) m4 -P -I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslparser.y aslcompiler.y yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y yacc: 89 shift/reduce conflicts. yacc: f - maximum table size exceeded *** Error code 2 /etc/make.conf is /dev/null. I've also tried empty /etc/src.conf with no luck. Out of curiosity, is your src tree mounted via NFS? Glen I have a similar problem on revision /usr/src # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213 Node Kind: directory Schedule: normal Last Changed Author: glebius Last Changed Rev: 279213 Last Changed Date: 2015-02-23 20:57:09 +0200 (Mon, 23 Feb 2015) http://pastebin.com/FuAUkBmX Source tree is on the zfs /usr/src # zfs list zroot/usr/src NAME USED AVAIL REFER MOUNTPOINT zroot/usr/src 1.35G 408G 1.35G /usr/src what is most surprising, the same revision successfully building for the other 2 computers, including amd64|zfs and i386|ufs. Your installed yacc(1) is too old, i.e., your world was built from head before r274460. FYI, this commit fixes the above problem for building from stable: https://svnweb.freebsd.org/changeset/base/278975 For building from old head (pre-r274460), you have to manually bootstrap yacc first, e.g., something like this: cd /usr/src/usr.bin/yacc make clean cleandepend make all make install make clean cleandepend cd /usr/src make buildworld Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJU7gXkAAoJEHyflib82/FGAsMH/iw2oNbyOPY7t/GIm+7QpqKS 4jOZisFY9WD8UCpziqwnp5Ia1A4YC4rn7W5G6wKALHMTuo3kT8lFEWV5sIVhc0dm 7to624zTVsNZqBhCFODRMZSXSlpMNCkjWtixGT1spEmyUAeKSEq5dPLaj3JyOOUw XvZbY6l4f/jFr+68z/uIHRJi3NbP5SODIYuUanO7X0nVuxI0PQNE45o3p2dj7lRJ 9eV0G5/SJUT8uWSuXy2kOY+TZWAk8VTTz/nb+krKPtwBdsv+nhSu3NDuaTJQk4gm KaA+FaOgP/vhyxrF61qBOVq+MDy66/XuU4s/9IKrRoeUrZX0j5X4JoGC1p2+cgU= =lpVt -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bombarded with LOR's with recent install
On Wed, 25 Feb 2015 08:56:14 -0800 Chris H bsd-li...@bsdforge.com wrote I see somebody also reported something along these lines, recently; http://freebsd.1045724.n5.nabble.com/ufs-devfs-quot-lock-order-reversal-quot-on-poweroff-td5989901.html But there was no reported resolution. --Chris I just wiped a system last night to perform a fresh install from the 11-CURRENT-amd64-20150223 disk1 CD. After the install, and choosing the reboot system, resulted in a LOR. I wasn't able to capture the output. But I'm still plagued with LOR's. They almost always follow the halt(8) command, and almost always occur during the final stages of the boot. But aren't always restricted to those events. The LOR's output seem indicative of fs related issues. This system has *always* worked w/o fail, and prior to this install, has never indicated hardware issues. Aside from the dmesg(8) attached, here are 2 of the examples. NOTE the numbers, and files are not always the same, from LOR to LOR; lock order reversal: 1st 0xf8000474f7c8 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1229 2nd 0xf80004caf5f0 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0120c27570 witness_checkorder() at witness_checkorder+0xe45/frame 0xfe0120c27600 __lockmgr_args() at __lockmgr_args+0xacf/frame 0xfe0120c27730 vop_stdlock() at vop_stdlock+0x3c/frame 0xfe0120c27750 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfe0120c27780 _vn_lock() at _vn_lock+0x8a/frame 0xfe0120c277f0 ffs_flushfiles() at ffs_flushfiles+0x113/frame 0xfe0120c27860 softdep_flushfiles() at softdep_flushfiles+0x273/frame 0xfe0120c278d0 ffs_unmount() at ffs_unmount+0x81/frame 0xfe0120c27930 dounmount() at dounmount+0x42c/frame 0xfe0120c279b0 sys_unmount() at sys_unmount+0x2ec/frame 0xfe0120c27ae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfe0120c27bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0120c27bf0 --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x8008990ea, rsp = 0x7ff fe348, rbp = 0x7fffe460 --- lock order reversal: 1st 0xfe00f749ddc8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3097 2nd 0xf80004f28c00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:2 85 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0120c6d470 witness_checkorder() at witness_checkorder+0xe45/frame 0xfe0120c6d500 _sx_xlock() at _sx_xlock+0x75/frame 0xfe0120c6d540 ufsdirhash_add() at ufsdirhash_add+0x3a/frame 0xfe0120c6d580 ufs_direnter() at ufs_direnter+0x641/frame 0xfe0120c6d640 ufs_rename() at ufs_rename+0xffe/frame 0xfe0120c6d830 VOP_RENAME_APV() at VOP_RENAME_APV+0xfc/frame 0xfe0120c6d860 kern_renameat() at kern_renameat+0x4bc/frame 0xfe0120c6dae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfe0120c6dbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0120c6dbf0 --- syscall (128, FreeBSD ELF64, sys_rename), rip = 0x801ca4d2a, rsp = 0x7ff fded8, rbp = 0x7fffdee0 --- and another lock order reversal: 1st 0xf800048979a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2176 2nd 0xfe00f72442e0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:263 3rd 0xf80004871068 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2176 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0120ae9e20 witness_checkorder() at witness_checkorder+0xe45/frame 0xfe0120ae9eb0 __lockmgr_args() at __lockmgr_args+0xacf/frame 0xfe0120ae9fe0 ffs_lock() at ffs_lock+0x84/frame 0xfe0120aea030 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfe0120aea060 _vn_lock() at _vn_lock+0x8a/frame 0xfe0120aea0d0 vget() at vget+0x67/frame 0xfe0120aea110 vfs_hash_get() at vfs_hash_get+0xdc/frame 0xfe0120aea160 ffs_vgetf() at ffs_vgetf+0x40/frame 0xfe0120aea1f0 softdep_sync_buf() at softdep_sync_buf+0xa90/frame 0xfe0120aea2d0 ffs_syncvnode() at ffs_syncvnode+0x259/frame 0xfe0120aea350 ffs_truncate() at ffs_truncate+0x671/frame 0xfe0120aea530 ufs_direnter() at ufs_direnter+0x7d1/frame 0xfe0120aea5f0 ufs_makeinode() at ufs_makeinode+0x5bf/frame 0xfe0120aea7b0 ufs_create() at ufs_create+0x2d/frame 0xfe0120aea7d0 VOP_CREATE_APV() at VOP_CREATE_APV+0xf1/frame 0xfe0120aea800 vn_open_cred() at vn_open_cred+0x2c6/frame 0xfe0120aea960 kern_openat() at kern_openat+0x257/frame 0xfe0120aeaae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfe0120aeabf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0120aeabf0 --- syscall (499, FreeBSD ELF64, sys_openat), rip = 0x800b4c79a, rsp = 0x7ff fd598, rbp = 0x7fffd670 --- I *really* need to build/install world/kernel on this box. But am fairly confident that there will be issues as I LOR's to occur during the process. Any insight || help with
bombarded with LOR's with recent install
I just wiped a system last night to perform a fresh install from the 11-CURRENT-amd64-20150223 disk1 CD. After the install, and choosing the reboot system, resulted in a LOR. I wasn't able to capture the output. But I'm still plagued with LOR's. They almost always follow the halt(8) command, and almost always occur during the final stages of the boot. But aren't always restricted to those events. The LOR's output seem indicative of fs related issues. This system has *always* worked w/o fail, and prior to this install, has never indicated hardware issues. Aside from the dmesg(8) attached, here are 2 of the examples. NOTE the numbers, and files are not always the same, from LOR to LOR; lock order reversal: 1st 0xf8000474f7c8 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1229 2nd 0xf80004caf5f0 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0120c27570 witness_checkorder() at witness_checkorder+0xe45/frame 0xfe0120c27600 __lockmgr_args() at __lockmgr_args+0xacf/frame 0xfe0120c27730 vop_stdlock() at vop_stdlock+0x3c/frame 0xfe0120c27750 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfe0120c27780 _vn_lock() at _vn_lock+0x8a/frame 0xfe0120c277f0 ffs_flushfiles() at ffs_flushfiles+0x113/frame 0xfe0120c27860 softdep_flushfiles() at softdep_flushfiles+0x273/frame 0xfe0120c278d0 ffs_unmount() at ffs_unmount+0x81/frame 0xfe0120c27930 dounmount() at dounmount+0x42c/frame 0xfe0120c279b0 sys_unmount() at sys_unmount+0x2ec/frame 0xfe0120c27ae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfe0120c27bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0120c27bf0 --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x8008990ea, rsp = 0x7ff fe348, rbp = 0x7fffe460 --- lock order reversal: 1st 0xfe00f749ddc8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3097 2nd 0xf80004f28c00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:2 85 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0120c6d470 witness_checkorder() at witness_checkorder+0xe45/frame 0xfe0120c6d500 _sx_xlock() at _sx_xlock+0x75/frame 0xfe0120c6d540 ufsdirhash_add() at ufsdirhash_add+0x3a/frame 0xfe0120c6d580 ufs_direnter() at ufs_direnter+0x641/frame 0xfe0120c6d640 ufs_rename() at ufs_rename+0xffe/frame 0xfe0120c6d830 VOP_RENAME_APV() at VOP_RENAME_APV+0xfc/frame 0xfe0120c6d860 kern_renameat() at kern_renameat+0x4bc/frame 0xfe0120c6dae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfe0120c6dbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0120c6dbf0 --- syscall (128, FreeBSD ELF64, sys_rename), rip = 0x801ca4d2a, rsp = 0x7ff fded8, rbp = 0x7fffdee0 --- and another lock order reversal: 1st 0xf800048979a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2176 2nd 0xfe00f72442e0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:263 3rd 0xf80004871068 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2176 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0120ae9e20 witness_checkorder() at witness_checkorder+0xe45/frame 0xfe0120ae9eb0 __lockmgr_args() at __lockmgr_args+0xacf/frame 0xfe0120ae9fe0 ffs_lock() at ffs_lock+0x84/frame 0xfe0120aea030 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfe0120aea060 _vn_lock() at _vn_lock+0x8a/frame 0xfe0120aea0d0 vget() at vget+0x67/frame 0xfe0120aea110 vfs_hash_get() at vfs_hash_get+0xdc/frame 0xfe0120aea160 ffs_vgetf() at ffs_vgetf+0x40/frame 0xfe0120aea1f0 softdep_sync_buf() at softdep_sync_buf+0xa90/frame 0xfe0120aea2d0 ffs_syncvnode() at ffs_syncvnode+0x259/frame 0xfe0120aea350 ffs_truncate() at ffs_truncate+0x671/frame 0xfe0120aea530 ufs_direnter() at ufs_direnter+0x7d1/frame 0xfe0120aea5f0 ufs_makeinode() at ufs_makeinode+0x5bf/frame 0xfe0120aea7b0 ufs_create() at ufs_create+0x2d/frame 0xfe0120aea7d0 VOP_CREATE_APV() at VOP_CREATE_APV+0xf1/frame 0xfe0120aea800 vn_open_cred() at vn_open_cred+0x2c6/frame 0xfe0120aea960 kern_openat() at kern_openat+0x257/frame 0xfe0120aeaae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfe0120aeabf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0120aeabf0 --- syscall (499, FreeBSD ELF64, sys_openat), rip = 0x800b4c79a, rsp = 0x7ff fd598, rbp = 0x7fffd670 --- I *really* need to build/install world/kernel on this box. But am fairly confident that there will be issues as I LOR's to occur during the process. Any insight || help with this, greatly appreciated. Thanks! --Chris -- domain=0, bus=1, slot=10, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 map[10]: type I/O Port, range 32, base 0xbc00, size 5, enabled pcib1: allocated I/O
Re: r279278 failed to build (yacc: maximum table size exceeded)
On 25 February 2015 at 22:14, Jung-uk Kim j...@freebsd.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/25/2015 14:05, Glen Barber wrote:
On Wed, Feb 25, 2015 at 10:51:31PM +0400, Arseny Nasokin wrote:
On 25 February 2015 at 20:27, Jung-uk Kim j...@freebsd.org
wrote:
Your installed yacc(1) is too old, i.e., your world was built
from head before r274460. FYI, this commit fixes the above
problem for building from stable:
https://svnweb.freebsd.org/changeset/base/278975
For building from old head (pre-r274460), you have to manually
bootstrap yacc first, e.g., something like this:
cd /usr/src/usr.bin/yacc make clean cleandepend make all
make install make clean cleandepend cd /usr/src make
buildworld
Hi, guys,
I've found the fix by forcing to add yacc(1) to bootstrap build.
Makefile.inc1, line 1277:
if ${BOOTSTRAPPING} 1001506 _yacc= lib/liby \
change to:
if ${BOOTSTRAPPING} 1201506 ## It is for test purposes only!!!
_yacc= lib/liby \
This can be set to 1001507 now; __FreeBSD_version was bumped
earlier today.
Nope, 1001506 is correct, i.e., the change was MFC'ed to stable/10 and
__FreeBSD_version was bumped to reflect it.
https://svnweb.freebsd.org/changeset/base/277087
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJU7h8dAAoJEHyflib82/FGL9cH/A3wsEEjtUNGcmOfYHN2+l50
K9xCxRwLvioxOjFygnHoNTvxhSMxjMCvX7UtyLR3CWD/31FJEsGgv7uFoavAMUPq
hk5vAUJgoAbue4FwF6Ow7Lmm59dl+4ukVqEawepYFlYn6njLgJt1itF74VD9aufi
D1oRk72KhhPXe66DYJsXzybgq5ba2/eJy0/YLsheRnsb2zB7fEcHGGca1icAVgjm
794BQdk0kOG7+EkQcafIElY4HJb+mJCE4iFg3NCrhrs7wEYZZQXlqDUVKRd0R5kN
U4u4EiXckiyDVPrzicnpVCtQD5vdxH5BBfWC1FQIFnzTJgLZuRihLpfmDZOeHS8=
=+AsC
-END PGP SIGNATURE-
Jung,
I have FreeBSD 11.0-CURRENT r265265 with OSRELDATE 1100020 and invalid
YACC. So This conditional expression must be fixed to check if this 11.x
and yacc is not changed.
In my hypothetical patch I set OSRELDATE to invalid abstract future
version, because it's only concept and I have no time to fix it correctly
now.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r279278 failed to build (yacc: maximum table size exceeded)
There's no bikeshed to be had. Either the tool meets some specific version / API requirement in order to be used how it's used, or something has to be built in its place. Since tools are now getting backported during a stable branch in order to grow new features, we can't just assume oh stable/10 cat will always support these options. So, checking some version string to see if the utility meets the requirements is fine. The only bikeshed I'd introduce is having each tool take a --version style option to print out its own program API version, so we can match on things as appropriate. But BOOTSTRAPPING is fine. -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r279278 failed to build (yacc: maximum table size exceeded)
On Feb 25, 2015, at 11:10, Jung-uk Kim j...@freebsd.org wrote:
Signed PGP part
On 02/25/2015 13:55, Garrett Cooper wrote:
On Feb 25, 2015, at 10:51, Arseny Nasokin eir...@gmail.com
wrote:
On 25 February 2015 at 20:27, Jung-uk Kim j...@freebsd.org
wrote:
On 02/25/2015 11:22, Ivan Klymenko wrote:
В Wed, 25 Feb 2015 15:43:27 + Glen Barber
g...@freebsd.org пишет:
On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin
wrote:
I have clean svn tree with base/head branch. I try to
build world, but I have some mysterious bugs. The
latest is yacc failed to make c file on phase 4.3:
=== usr.sbin/acpi/iasl (depend) m4 -P
-I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler
/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslparser.y
aslcompiler.y
yacc -d -pAslCompiler -oaslcompilerparse.c
aslcompiler.y yacc: 89 shift/reduce conflicts. yacc: f
- maximum table size exceeded *** Error code 2
/etc/make.conf is /dev/null. I've also tried empty
/etc/src.conf with no luck.
Out of curiosity, is your src tree mounted via NFS?
Glen
I have a similar problem on revision /usr/src # svn info
Path: . Working Copy Root Path: /usr/src URL:
svn://svn.freebsd.org/base/head Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/base Repository
UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213
Node Kind: directory Schedule: normal Last Changed Author:
glebius Last Changed Rev: 279213 Last Changed Date:
2015-02-23 20:57:09 +0200 (Mon, 23 Feb 2015)
http://pastebin.com/FuAUkBmX
Source tree is on the zfs /usr/src # zfs list zroot/usr/src
NAME USED AVAIL REFER MOUNTPOINT zroot/usr/src 1.35G
408G 1.35G /usr/src
what is most surprising, the same revision successfully
building for the other 2 computers, including amd64|zfs and
i386|ufs.
Your installed yacc(1) is too old, i.e., your world was built from
head before r274460. FYI, this commit fixes the above problem for
building from stable:
https://svnweb.freebsd.org/changeset/base/278975
For building from old head (pre-r274460), you have to manually
bootstrap yacc first, e.g., something like this:
cd /usr/src/usr.bin/yacc make clean cleandepend make all make
install make clean cleandepend cd /usr/src make buildworld
Jung-uk Kim
Hi, guys,
I've found the fix by forcing to add yacc(1) to bootstrap build.
Makefile.inc1, line 1277:
if ${BOOTSTRAPPING} 1001506 _yacc= lib/liby \
change to:
if ${BOOTSTRAPPING} 1201506 ## It is for test purposes only!!!
_yacc= lib/liby \
It takes a few seconds to build this on my laptop — can we just
explicitly turn this on to be sure we’re using the right thing?
% (cd lib/liby; time sh -c 'make obj; make depend; make all')
real0m0.326s user0m0.031s sys 0m0.111s
% (cd usr.bin/yacc/; time sh -c 'make obj; make depend; make all')
real0m3.431s user0m2.631s sys 0m0.363s
With me parallelizing bootstrap-tools on HEAD it should be less of
an issue stacking on items like this.
Then, this argument also applies to other conditional bootstrap-tools,
e.g., bin/cat.
I know we have long tradition of painting bikesheds with different
colors and it will probably never end. However, I will not
participate in this one, sorry.
I was going to propose something a bit more radical — I can remove the
BOOTSTRAPPING conditionals and simplify the code on 10-STABLE / 11-CURRENT.
Maintaining BOOTSTRAPPING is error prone and it’s not saving much time in the
long run in builds (it's taking longer to diagnose issues, test them, and
commit fixes which will break at a later date). I’ve been bitten by this once
because I don’t run ancient CURRENT/STABLE (r279198) and here are a couple
follow up commits bumping tools versions in the past (e.g. r278975, r269662,
etc).
Just a thought.
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: r279278 failed to build (yacc: maximum table size exceeded)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/25/2015 14:59, Arseny Nasokin wrote:
On 25 February 2015 at 22:14, Jung-uk Kim j...@freebsd.org
mailto:j...@freebsd.org wrote:
On 02/25/2015 14:05, Glen Barber wrote:
On Wed, Feb 25, 2015 at 10:51:31PM +0400, Arseny Nasokin wrote:
On 25 February 2015 at 20:27, Jung-uk Kim j...@freebsd.org
mailto:j...@freebsd.org
wrote:
Your installed yacc(1) is too old, i.e., your world was
built from head before r274460. FYI, this commit fixes the
above problem for building from stable:
https://svnweb.freebsd.org/changeset/base/278975
For building from old head (pre-r274460), you have to
manually bootstrap yacc first, e.g., something like this:
cd /usr/src/usr.bin/yacc make clean cleandepend make all
make install make clean cleandepend cd /usr/src make
buildworld
Hi, guys,
I've found the fix by forcing to add yacc(1) to bootstrap
build.
Makefile.inc1, line 1277:
if ${BOOTSTRAPPING} 1001506 _yacc= lib/liby \
change to:
if ${BOOTSTRAPPING} 1201506 ## It is for test purposes
only!!! _yacc= lib/liby \
This can be set to 1001507 now; __FreeBSD_version was bumped
earlier today.
Nope, 1001506 is correct, i.e., the change was MFC'ed to stable/10
and __FreeBSD_version was bumped to reflect it.
https://svnweb.freebsd.org/changeset/base/277087
Jung-uk Kim
Jung,
I have FreeBSD 11.0-CURRENT r265265 with OSRELDATE 1100020 and
invalid YACC. So This conditional expression must be fixed to check
if this 11.x and yacc is not changed.
Wow, that's more than 9-month old now.
In my hypothetical patch I set OSRELDATE to invalid abstract
future version, because it's only concept and I have no time to fix
it correctly now.
If you insist, you can try this:
- --- Makefile.inc1
+++ Makefile.inc1
@@ -1274,7 +1274,8 @@
_awk= usr.bin/awk
.endif
- -.if ${BOOTSTRAPPING} 1001506
+.if ${BOOTSTRAPPING} 1001506 || \
+(${BOOTSTRAPPING} = 110 ${BOOTSTRAPPING} 1100046)
_yacc= lib/liby \
usr.bin/yacc
(but I won't commit it.)
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJU7i1kAAoJEHyflib82/FGh9kH/07QOQ+xlPQVApJD+x1u/c4b
G1g4mmOhEKKOjVK9dJFKY1hvTiLYkOB3UDwJH8rmzbglInY+eepbD9Ac15Dtl90b
RFvNEB3B7Rwzt9ljg2zH/OQ6HnPCHgreF31ggkmKLszQ/Rrv62KTmN9ML4dkx897
7jAPwwtMb2XfLzyAc2fMNne3xl/zmdzafcqA+87UOUJ3Jb4rv35/x3kSrOqsMzvj
A3ufAepzG2J0+fH62ZP2L/FfuXoaKP0hlIpXZwNYAciSf+GAa7McYyu1aaRZQedF
1DSphDtSFnJKR+ltIvDL5WH98Zi0iOu5FHb9bLfW/s+bV+oxs4/ZQHtxsIejLN4=
=3xA9
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r279278 failed to build (yacc: maximum table size exceeded)
On 25 February 2015 at 20:27, Jung-uk Kim j...@freebsd.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/25/2015 11:22, Ivan Klymenko wrote:
В Wed, 25 Feb 2015 15:43:27 + Glen Barber g...@freebsd.org
пишет:
On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin wrote:
I have clean svn tree with base/head branch. I try to build
world, but I have some mysterious bugs. The latest is yacc
failed to make c file on phase 4.3:
=== usr.sbin/acpi/iasl (depend) m4 -P
-I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler
/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslparser.y
aslcompiler.y
yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y yacc:
89 shift/reduce conflicts. yacc: f - maximum table size
exceeded *** Error code 2
/etc/make.conf is /dev/null. I've also tried empty
/etc/src.conf with no luck.
Out of curiosity, is your src tree mounted via NFS?
Glen
I have a similar problem on revision /usr/src # svn info Path: .
Working Copy Root Path: /usr/src URL:
svn://svn.freebsd.org/base/head Relative URL: ^/head Repository
Root: svn://svn.freebsd.org/base Repository UUID:
ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213 Node Kind:
directory Schedule: normal Last Changed Author: glebius Last
Changed Rev: 279213 Last Changed Date: 2015-02-23 20:57:09 +0200
(Mon, 23 Feb 2015)
http://pastebin.com/FuAUkBmX
Source tree is on the zfs /usr/src # zfs list zroot/usr/src NAME
USED AVAIL REFER MOUNTPOINT zroot/usr/src 1.35G 408G 1.35G
/usr/src
what is most surprising, the same revision successfully building
for the other 2 computers, including amd64|zfs and i386|ufs.
Your installed yacc(1) is too old, i.e., your world was built from
head before r274460. FYI, this commit fixes the above problem for
building from stable:
https://svnweb.freebsd.org/changeset/base/278975
For building from old head (pre-r274460), you have to manually
bootstrap yacc first, e.g., something like this:
cd /usr/src/usr.bin/yacc
make clean cleandepend
make all make install
make clean cleandepend
cd /usr/src
make buildworld
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJU7gXkAAoJEHyflib82/FGAsMH/iw2oNbyOPY7t/GIm+7QpqKS
4jOZisFY9WD8UCpziqwnp5Ia1A4YC4rn7W5G6wKALHMTuo3kT8lFEWV5sIVhc0dm
7to624zTVsNZqBhCFODRMZSXSlpMNCkjWtixGT1spEmyUAeKSEq5dPLaj3JyOOUw
XvZbY6l4f/jFr+68z/uIHRJi3NbP5SODIYuUanO7X0nVuxI0PQNE45o3p2dj7lRJ
9eV0G5/SJUT8uWSuXy2kOY+TZWAk8VTTz/nb+krKPtwBdsv+nhSu3NDuaTJQk4gm
KaA+FaOgP/vhyxrF61qBOVq+MDy66/XuU4s/9IKrRoeUrZX0j5X4JoGC1p2+cgU=
=lpVt
-END PGP SIGNATURE-
Hi, guys,
I've found the fix by forcing to add yacc(1) to bootstrap build.
Makefile.inc1, line 1277:
if ${BOOTSTRAPPING} 1001506
_yacc= lib/liby \
change to:
if ${BOOTSTRAPPING} 1201506 ## It is for test purposes only!!!
_yacc= lib/liby \
-- Eir Nym
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r279278 failed to build (yacc: maximum table size exceeded)
On Wed, Feb 25, 2015 at 10:51:31PM +0400, Arseny Nasokin wrote:
On 25 February 2015 at 20:27, Jung-uk Kim j...@freebsd.org wrote:
Your installed yacc(1) is too old, i.e., your world was built from
head before r274460. FYI, this commit fixes the above problem for
building from stable:
https://svnweb.freebsd.org/changeset/base/278975
For building from old head (pre-r274460), you have to manually
bootstrap yacc first, e.g., something like this:
cd /usr/src/usr.bin/yacc
make clean cleandepend
make all make install
make clean cleandepend
cd /usr/src
make buildworld
Hi, guys,
I've found the fix by forcing to add yacc(1) to bootstrap build.
Makefile.inc1, line 1277:
if ${BOOTSTRAPPING} 1001506
_yacc= lib/liby \
change to:
if ${BOOTSTRAPPING} 1201506 ## It is for test purposes only!!!
_yacc= lib/liby \
This can be set to 1001507 now; __FreeBSD_version was bumped earlier
today.
Glen
pgpfqOC99cos6.pgp
Description: PGP signature
Re: bombarded with LOR's with recent install
On Wed, 25 Feb 2015 09:42:54 -0800 Chris H bsd-li...@bsdforge.com wrote On Wed, 25 Feb 2015 08:56:14 -0800 Chris H bsd-li...@bsdforge.com wrote I see somebody also reported something along these lines, recently; http://freebsd.1045724.n5.nabble.com/ufs-devfs-quot-lock-order-reversal-quot- on-poweroff-td5989901.html But there was no reported resolution. and again in January, as well. https://www.mail-archive.com/freebsd-current@freebsd.org/msg158784.html Is there any way to switch off WITNESS, INVARIANTS SKIPSPIN in the GENERIC that is installed, outside of building a new kernel? --Chris --Chris I just wiped a system last night to perform a fresh install from the 11-CURRENT-amd64-20150223 disk1 CD. After the install, and choosing the reboot system, resulted in a LOR. I wasn't able to capture the output. But I'm still plagued with LOR's. They almost always follow the halt(8) command, and almost always occur during the final stages of the boot. But aren't always restricted to those events. The LOR's output seem indicative of fs related issues. This system has *always* worked w/o fail, and prior to this install, has never indicated hardware issues. Aside from the dmesg(8) attached, here are 2 of the examples. NOTE the numbers, and files are not always the same, from LOR to LOR; lock order reversal: 1st 0xf8000474f7c8 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1229 2nd 0xf80004caf5f0 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0120c27570 witness_checkorder() at witness_checkorder+0xe45/frame 0xfe0120c27600 __lockmgr_args() at __lockmgr_args+0xacf/frame 0xfe0120c27730 vop_stdlock() at vop_stdlock+0x3c/frame 0xfe0120c27750 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfe0120c27780 _vn_lock() at _vn_lock+0x8a/frame 0xfe0120c277f0 ffs_flushfiles() at ffs_flushfiles+0x113/frame 0xfe0120c27860 softdep_flushfiles() at softdep_flushfiles+0x273/frame 0xfe0120c278d0 ffs_unmount() at ffs_unmount+0x81/frame 0xfe0120c27930 dounmount() at dounmount+0x42c/frame 0xfe0120c279b0 sys_unmount() at sys_unmount+0x2ec/frame 0xfe0120c27ae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfe0120c27bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0120c27bf0 --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x8008990ea, rsp = 0x7ff fe348, rbp = 0x7fffe460 --- lock order reversal: 1st 0xfe00f749ddc8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3097 2nd 0xf80004f28c00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:2 85 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0120c6d470 witness_checkorder() at witness_checkorder+0xe45/frame 0xfe0120c6d500 _sx_xlock() at _sx_xlock+0x75/frame 0xfe0120c6d540 ufsdirhash_add() at ufsdirhash_add+0x3a/frame 0xfe0120c6d580 ufs_direnter() at ufs_direnter+0x641/frame 0xfe0120c6d640 ufs_rename() at ufs_rename+0xffe/frame 0xfe0120c6d830 VOP_RENAME_APV() at VOP_RENAME_APV+0xfc/frame 0xfe0120c6d860 kern_renameat() at kern_renameat+0x4bc/frame 0xfe0120c6dae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfe0120c6dbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0120c6dbf0 --- syscall (128, FreeBSD ELF64, sys_rename), rip = 0x801ca4d2a, rsp = 0x7ff fded8, rbp = 0x7fffdee0 --- and another lock order reversal: 1st 0xf800048979a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2176 2nd 0xfe00f72442e0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:263 3rd 0xf80004871068 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2176 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0120ae9e20 witness_checkorder() at witness_checkorder+0xe45/frame 0xfe0120ae9eb0 __lockmgr_args() at __lockmgr_args+0xacf/frame 0xfe0120ae9fe0 ffs_lock() at ffs_lock+0x84/frame 0xfe0120aea030 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfe0120aea060 _vn_lock() at _vn_lock+0x8a/frame 0xfe0120aea0d0 vget() at vget+0x67/frame 0xfe0120aea110 vfs_hash_get() at vfs_hash_get+0xdc/frame 0xfe0120aea160 ffs_vgetf() at ffs_vgetf+0x40/frame 0xfe0120aea1f0 softdep_sync_buf() at softdep_sync_buf+0xa90/frame 0xfe0120aea2d0 ffs_syncvnode() at ffs_syncvnode+0x259/frame 0xfe0120aea350 ffs_truncate() at ffs_truncate+0x671/frame 0xfe0120aea530 ufs_direnter() at ufs_direnter+0x7d1/frame 0xfe0120aea5f0 ufs_makeinode() at ufs_makeinode+0x5bf/frame 0xfe0120aea7b0 ufs_create() at ufs_create+0x2d/frame 0xfe0120aea7d0 VOP_CREATE_APV() at VOP_CREATE_APV+0xf1/frame 0xfe0120aea800 vn_open_cred() at vn_open_cred+0x2c6/frame 0xfe0120aea960 kern_openat() at kern_openat+0x257/frame 0xfe0120aeaae0 amd64_syscall()
Re: r279278 failed to build (yacc: maximum table size exceeded)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/25/2015 14:05, Glen Barber wrote:
On Wed, Feb 25, 2015 at 10:51:31PM +0400, Arseny Nasokin wrote:
On 25 February 2015 at 20:27, Jung-uk Kim j...@freebsd.org
wrote:
Your installed yacc(1) is too old, i.e., your world was built
from head before r274460. FYI, this commit fixes the above
problem for building from stable:
https://svnweb.freebsd.org/changeset/base/278975
For building from old head (pre-r274460), you have to manually
bootstrap yacc first, e.g., something like this:
cd /usr/src/usr.bin/yacc make clean cleandepend make all
make install make clean cleandepend cd /usr/src make
buildworld
Hi, guys,
I've found the fix by forcing to add yacc(1) to bootstrap build.
Makefile.inc1, line 1277:
if ${BOOTSTRAPPING} 1001506 _yacc= lib/liby \
change to:
if ${BOOTSTRAPPING} 1201506 ## It is for test purposes only!!!
_yacc= lib/liby \
This can be set to 1001507 now; __FreeBSD_version was bumped
earlier today.
Nope, 1001506 is correct, i.e., the change was MFC'ed to stable/10 and
__FreeBSD_version was bumped to reflect it.
https://svnweb.freebsd.org/changeset/base/277087
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJU7h8dAAoJEHyflib82/FGL9cH/A3wsEEjtUNGcmOfYHN2+l50
K9xCxRwLvioxOjFygnHoNTvxhSMxjMCvX7UtyLR3CWD/31FJEsGgv7uFoavAMUPq
hk5vAUJgoAbue4FwF6Ow7Lmm59dl+4ukVqEawepYFlYn6njLgJt1itF74VD9aufi
D1oRk72KhhPXe66DYJsXzybgq5ba2/eJy0/YLsheRnsb2zB7fEcHGGca1icAVgjm
794BQdk0kOG7+EkQcafIElY4HJb+mJCE4iFg3NCrhrs7wEYZZQXlqDUVKRd0R5kN
U4u4EiXckiyDVPrzicnpVCtQD5vdxH5BBfWC1FQIFnzTJgLZuRihLpfmDZOeHS8=
=+AsC
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r279278 failed to build (yacc: maximum table size exceeded)
On Feb 25, 2015, at 10:51, Arseny Nasokin eir...@gmail.com wrote:
On 25 February 2015 at 20:27, Jung-uk Kim j...@freebsd.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/25/2015 11:22, Ivan Klymenko wrote:
В Wed, 25 Feb 2015 15:43:27 + Glen Barber g...@freebsd.org
пишет:
On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin wrote:
I have clean svn tree with base/head branch. I try to build
world, but I have some mysterious bugs. The latest is yacc
failed to make c file on phase 4.3:
=== usr.sbin/acpi/iasl (depend) m4 -P
-I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler
/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslparser.y
aslcompiler.y
yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y yacc:
89 shift/reduce conflicts. yacc: f - maximum table size
exceeded *** Error code 2
/etc/make.conf is /dev/null. I've also tried empty
/etc/src.conf with no luck.
Out of curiosity, is your src tree mounted via NFS?
Glen
I have a similar problem on revision /usr/src # svn info Path: .
Working Copy Root Path: /usr/src URL:
svn://svn.freebsd.org/base/head Relative URL: ^/head Repository
Root: svn://svn.freebsd.org/base Repository UUID:
ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213 Node Kind:
directory Schedule: normal Last Changed Author: glebius Last
Changed Rev: 279213 Last Changed Date: 2015-02-23 20:57:09 +0200
(Mon, 23 Feb 2015)
http://pastebin.com/FuAUkBmX
Source tree is on the zfs /usr/src # zfs list zroot/usr/src NAME
USED AVAIL REFER MOUNTPOINT zroot/usr/src 1.35G 408G 1.35G
/usr/src
what is most surprising, the same revision successfully building
for the other 2 computers, including amd64|zfs and i386|ufs.
Your installed yacc(1) is too old, i.e., your world was built from
head before r274460. FYI, this commit fixes the above problem for
building from stable:
https://svnweb.freebsd.org/changeset/base/278975
For building from old head (pre-r274460), you have to manually
bootstrap yacc first, e.g., something like this:
cd /usr/src/usr.bin/yacc
make clean cleandepend
make all make install
make clean cleandepend
cd /usr/src
make buildworld
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJU7gXkAAoJEHyflib82/FGAsMH/iw2oNbyOPY7t/GIm+7QpqKS
4jOZisFY9WD8UCpziqwnp5Ia1A4YC4rn7W5G6wKALHMTuo3kT8lFEWV5sIVhc0dm
7to624zTVsNZqBhCFODRMZSXSlpMNCkjWtixGT1spEmyUAeKSEq5dPLaj3JyOOUw
XvZbY6l4f/jFr+68z/uIHRJi3NbP5SODIYuUanO7X0nVuxI0PQNE45o3p2dj7lRJ
9eV0G5/SJUT8uWSuXy2kOY+TZWAk8VTTz/nb+krKPtwBdsv+nhSu3NDuaTJQk4gm
KaA+FaOgP/vhyxrF61qBOVq+MDy66/XuU4s/9IKrRoeUrZX0j5X4JoGC1p2+cgU=
=lpVt
-END PGP SIGNATURE-
Hi, guys,
I've found the fix by forcing to add yacc(1) to bootstrap build.
Makefile.inc1, line 1277:
if ${BOOTSTRAPPING} 1001506
_yacc= lib/liby \
change to:
if ${BOOTSTRAPPING} 1201506 ## It is for test purposes only!!!
_yacc= lib/liby \
It takes a few seconds to build this on my laptop — can we just explicitly turn
this on to be sure we’re using the right thing?
% (cd lib/liby; time sh -c 'make obj; make depend; make all')
real0m0.326s
user0m0.031s
sys 0m0.111s
% (cd usr.bin/yacc/; time sh -c 'make obj; make depend; make all')
real0m3.431s
user0m2.631s
sys 0m0.363s
With me parallelizing bootstrap-tools on HEAD it should be less of an issue
stacking on items like this.
Thanks!
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: r279278 failed to build (yacc: maximum table size exceeded)
On 25 February 2015 at 21:54, Adrian Chadd adr...@freebsd.org wrote:
should this be committed to -head?
-a
On 25 February 2015 at 10:51, Arseny Nasokin eir...@gmail.com wrote:
On 25 February 2015 at 20:27, Jung-uk Kim j...@freebsd.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/25/2015 11:22, Ivan Klymenko wrote:
В Wed, 25 Feb 2015 15:43:27 + Glen Barber g...@freebsd.org
пишет:
On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin wrote:
I have clean svn tree with base/head branch. I try to build
world, but I have some mysterious bugs. The latest is yacc
failed to make c file on phase 4.3:
=== usr.sbin/acpi/iasl (depend) m4 -P
-I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler
/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslparser.y
aslcompiler.y
yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y yacc:
89 shift/reduce conflicts. yacc: f - maximum table size
exceeded *** Error code 2
/etc/make.conf is /dev/null. I've also tried empty
/etc/src.conf with no luck.
Out of curiosity, is your src tree mounted via NFS?
Glen
I have a similar problem on revision /usr/src # svn info Path: .
Working Copy Root Path: /usr/src URL:
svn://svn.freebsd.org/base/head Relative URL: ^/head Repository
Root: svn://svn.freebsd.org/base Repository UUID:
ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213 Node Kind:
directory Schedule: normal Last Changed Author: glebius Last
Changed Rev: 279213 Last Changed Date: 2015-02-23 20:57:09 +0200
(Mon, 23 Feb 2015)
http://pastebin.com/FuAUkBmX
Source tree is on the zfs /usr/src # zfs list zroot/usr/src NAME
USED AVAIL REFER MOUNTPOINT zroot/usr/src 1.35G 408G 1.35G
/usr/src
what is most surprising, the same revision successfully building
for the other 2 computers, including amd64|zfs and i386|ufs.
Your installed yacc(1) is too old, i.e., your world was built from
head before r274460. FYI, this commit fixes the above problem for
building from stable:
https://svnweb.freebsd.org/changeset/base/278975
For building from old head (pre-r274460), you have to manually
bootstrap yacc first, e.g., something like this:
cd /usr/src/usr.bin/yacc
make clean cleandepend
make all make install
make clean cleandepend
cd /usr/src
make buildworld
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJU7gXkAAoJEHyflib82/FGAsMH/iw2oNbyOPY7t/GIm+7QpqKS
4jOZisFY9WD8UCpziqwnp5Ia1A4YC4rn7W5G6wKALHMTuo3kT8lFEWV5sIVhc0dm
7to624zTVsNZqBhCFODRMZSXSlpMNCkjWtixGT1spEmyUAeKSEq5dPLaj3JyOOUw
XvZbY6l4f/jFr+68z/uIHRJi3NbP5SODIYuUanO7X0nVuxI0PQNE45o3p2dj7lRJ
9eV0G5/SJUT8uWSuXy2kOY+TZWAk8VTTz/nb+krKPtwBdsv+nhSu3NDuaTJQk4gm
KaA+FaOgP/vhyxrF61qBOVq+MDy66/XuU4s/9IKrRoeUrZX0j5X4JoGC1p2+cgU=
=lpVt
-END PGP SIGNATURE-
Hi, guys,
I've found the fix by forcing to add yacc(1) to bootstrap build.
Makefile.inc1, line 1277:
if ${BOOTSTRAPPING} 1001506
_yacc= lib/liby \
change to:
if ${BOOTSTRAPPING} 1201506 ## It is for test purposes only!!!
_yacc= lib/liby \
-- Eir Nym
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
Adrian,
In this form this must not be committed, but this is good clue where to fix
it.
-- Eir Nym
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bombarded with LOR's with recent install
On Feb 25, 2015, at 10:19, Chris H bsd-li...@bsdforge.com wrote: On Wed, 25 Feb 2015 09:42:54 -0800 Chris H bsd-li...@bsdforge.com wrote On Wed, 25 Feb 2015 08:56:14 -0800 Chris H bsd-li...@bsdforge.com wrote I see somebody also reported something along these lines, recently; http://freebsd.1045724.n5.nabble.com/ufs-devfs-quot-lock-order-reversal-quot- on-poweroff-td5989901.html But there was no reported resolution. and again in January, as well. https://www.mail-archive.com/freebsd-current@freebsd.org/msg158784.html Is there any way to switch off WITNESS, INVARIANTS SKIPSPIN in the GENERIC that is installed, outside of building a new kernel? debug.witness.watch=0 disables witness watching -1 turns it off altogether (and according to the code requires a reboot, but I haven’t tested that assertion). As for all of the LORs reported, I’ve seen them a lot running CURRENT and at $work :(... I’m working on printing out those stacks via log(9) though — I’ll publish my new diff on Phabricator soon: https://reviews.freebsd.org/D1794 . Cheers! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: bombarded with LOR's with recent install
On Wed, 25 Feb 2015 10:59:11 -0800 Garrett Cooper yaneurab...@gmail.com wrote On Feb 25, 2015, at 10:19, Chris H bsd-li...@bsdforge.com wrote: On Wed, 25 Feb 2015 09:42:54 -0800 Chris H bsd-li...@bsdforge.com wrote On Wed, 25 Feb 2015 08:56:14 -0800 Chris H bsd-li...@bsdforge.com wrote I see somebody also reported something along these lines, recently; http://freebsd.1045724.n5.nabble.com/ufs-devfs-quot-lock-order-reversal-quot- on-poweroff-td5989901.html But there was no reported resolution. and again in January, as well. https://www.mail-archive.com/freebsd-current@freebsd.org/msg158784.html Is there any way to switch off WITNESS, INVARIANTS SKIPSPIN in the GENERIC that is installed, outside of building a new kernel? debug.witness.watch=0 disables witness watching -1 turns it off altogether (and according to the code requires a reboot, but I haven’t tested that assertion). Thank you, Garrett. That's great to know. As for all of the LORs reported, I’ve seen them a lot running CURRENT and at $work :(... I’m working on printing out those stacks via log(9) though — I’ll publish my new diff on Phabricator soon: https://reviews.freebsd.org/D1794 . I'll be watching this. Thanks! Cheers! --Chris -- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r279278 failed to build (yacc: maximum table size exceeded)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/25/2015 13:55, Garrett Cooper wrote:
On Feb 25, 2015, at 10:51, Arseny Nasokin eir...@gmail.com
wrote:
On 25 February 2015 at 20:27, Jung-uk Kim j...@freebsd.org
wrote:
On 02/25/2015 11:22, Ivan Klymenko wrote:
В Wed, 25 Feb 2015 15:43:27 + Glen Barber
g...@freebsd.org пишет:
On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin
wrote:
I have clean svn tree with base/head branch. I try to
build world, but I have some mysterious bugs. The
latest is yacc failed to make c file on phase 4.3:
=== usr.sbin/acpi/iasl (depend) m4 -P
-I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler
/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslparser.y
aslcompiler.y
yacc -d -pAslCompiler -oaslcompilerparse.c
aslcompiler.y yacc: 89 shift/reduce conflicts. yacc: f
- maximum table size exceeded *** Error code 2
/etc/make.conf is /dev/null. I've also tried empty
/etc/src.conf with no luck.
Out of curiosity, is your src tree mounted via NFS?
Glen
I have a similar problem on revision /usr/src # svn info
Path: . Working Copy Root Path: /usr/src URL:
svn://svn.freebsd.org/base/head Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/base Repository
UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213
Node Kind: directory Schedule: normal Last Changed Author:
glebius Last Changed Rev: 279213 Last Changed Date:
2015-02-23 20:57:09 +0200 (Mon, 23 Feb 2015)
http://pastebin.com/FuAUkBmX
Source tree is on the zfs /usr/src # zfs list zroot/usr/src
NAME USED AVAIL REFER MOUNTPOINT zroot/usr/src 1.35G
408G 1.35G /usr/src
what is most surprising, the same revision successfully
building for the other 2 computers, including amd64|zfs and
i386|ufs.
Your installed yacc(1) is too old, i.e., your world was built from
head before r274460. FYI, this commit fixes the above problem for
building from stable:
https://svnweb.freebsd.org/changeset/base/278975
For building from old head (pre-r274460), you have to manually
bootstrap yacc first, e.g., something like this:
cd /usr/src/usr.bin/yacc make clean cleandepend make all make
install make clean cleandepend cd /usr/src make buildworld
Jung-uk Kim
Hi, guys,
I've found the fix by forcing to add yacc(1) to bootstrap build.
Makefile.inc1, line 1277:
if ${BOOTSTRAPPING} 1001506 _yacc= lib/liby \
change to:
if ${BOOTSTRAPPING} 1201506 ## It is for test purposes only!!!
_yacc= lib/liby \
It takes a few seconds to build this on my laptop — can we just
explicitly turn this on to be sure we’re using the right thing?
% (cd lib/liby; time sh -c 'make obj; make depend; make all')
real0m0.326s user0m0.031s sys 0m0.111s
% (cd usr.bin/yacc/; time sh -c 'make obj; make depend; make all')
real0m3.431s user0m2.631s sys 0m0.363s
With me parallelizing bootstrap-tools on HEAD it should be less of
an issue stacking on items like this.
Then, this argument also applies to other conditional bootstrap-tools,
e.g., bin/cat.
I know we have long tradition of painting bikesheds with different
colors and it will probably never end. However, I will not
participate in this one, sorry.
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJU7h4zAAoJEHyflib82/FGEPkH/0SoSYzFfCifBUS14JiSn6hC
0O544JmeJE4giPAfk6h/vbKzJ43Q/NTvPRrayj2XZHNLJzzwH4fZsInFlqdfirna
Yqv0WTXHt2ZycsaP8ZxANF020eG8MV9L9q4r6xo1piiiWZMC9NlgbI8SQGC56Rbd
nTSL4sKIcCBdfImpUMLnVBvIMFrP4FbxBdqAYNbc6JlwxWtIWPesJMdgpHJgg/5F
tBJIHq3SgChOQjxxmIwwdiv/m25jx9b4247gxjdITpxUfaaUephsMa7qZ35RlURU
AMsUWeINzZmvWbOORSnxHKCClxkDav+kPGVk105tzNv4P6FnyhWgoGm+cb1hlNI=
=dSyP
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r279278 failed to build (yacc: maximum table size exceeded)
should this be committed to -head?
-a
On 25 February 2015 at 10:51, Arseny Nasokin eir...@gmail.com wrote:
On 25 February 2015 at 20:27, Jung-uk Kim j...@freebsd.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/25/2015 11:22, Ivan Klymenko wrote:
В Wed, 25 Feb 2015 15:43:27 + Glen Barber g...@freebsd.org
пишет:
On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin wrote:
I have clean svn tree with base/head branch. I try to build
world, but I have some mysterious bugs. The latest is yacc
failed to make c file on phase 4.3:
=== usr.sbin/acpi/iasl (depend) m4 -P
-I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler
/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslparser.y
aslcompiler.y
yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y yacc:
89 shift/reduce conflicts. yacc: f - maximum table size
exceeded *** Error code 2
/etc/make.conf is /dev/null. I've also tried empty
/etc/src.conf with no luck.
Out of curiosity, is your src tree mounted via NFS?
Glen
I have a similar problem on revision /usr/src # svn info Path: .
Working Copy Root Path: /usr/src URL:
svn://svn.freebsd.org/base/head Relative URL: ^/head Repository
Root: svn://svn.freebsd.org/base Repository UUID:
ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213 Node Kind:
directory Schedule: normal Last Changed Author: glebius Last
Changed Rev: 279213 Last Changed Date: 2015-02-23 20:57:09 +0200
(Mon, 23 Feb 2015)
http://pastebin.com/FuAUkBmX
Source tree is on the zfs /usr/src # zfs list zroot/usr/src NAME
USED AVAIL REFER MOUNTPOINT zroot/usr/src 1.35G 408G 1.35G
/usr/src
what is most surprising, the same revision successfully building
for the other 2 computers, including amd64|zfs and i386|ufs.
Your installed yacc(1) is too old, i.e., your world was built from
head before r274460. FYI, this commit fixes the above problem for
building from stable:
https://svnweb.freebsd.org/changeset/base/278975
For building from old head (pre-r274460), you have to manually
bootstrap yacc first, e.g., something like this:
cd /usr/src/usr.bin/yacc
make clean cleandepend
make all make install
make clean cleandepend
cd /usr/src
make buildworld
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJU7gXkAAoJEHyflib82/FGAsMH/iw2oNbyOPY7t/GIm+7QpqKS
4jOZisFY9WD8UCpziqwnp5Ia1A4YC4rn7W5G6wKALHMTuo3kT8lFEWV5sIVhc0dm
7to624zTVsNZqBhCFODRMZSXSlpMNCkjWtixGT1spEmyUAeKSEq5dPLaj3JyOOUw
XvZbY6l4f/jFr+68z/uIHRJi3NbP5SODIYuUanO7X0nVuxI0PQNE45o3p2dj7lRJ
9eV0G5/SJUT8uWSuXy2kOY+TZWAk8VTTz/nb+krKPtwBdsv+nhSu3NDuaTJQk4gm
KaA+FaOgP/vhyxrF61qBOVq+MDy66/XuU4s/9IKrRoeUrZX0j5X4JoGC1p2+cgU=
=lpVt
-END PGP SIGNATURE-
Hi, guys,
I've found the fix by forcing to add yacc(1) to bootstrap build.
Makefile.inc1, line 1277:
if ${BOOTSTRAPPING} 1001506
_yacc= lib/liby \
change to:
if ${BOOTSTRAPPING} 1201506 ## It is for test purposes only!!!
_yacc= lib/liby \
-- Eir Nym
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r279278 failed to build (yacc: maximum table size exceeded)
On Wed, Feb 25, 2015 at 02:14:37PM -0500, Jung-uk Kim wrote:
On 02/25/2015 14:05, Glen Barber wrote:
On Wed, Feb 25, 2015 at 10:51:31PM +0400, Arseny Nasokin wrote:
On 25 February 2015 at 20:27, Jung-uk Kim j...@freebsd.org
wrote:
Your installed yacc(1) is too old, i.e., your world was built
from head before r274460. FYI, this commit fixes the above
problem for building from stable:
https://svnweb.freebsd.org/changeset/base/278975
For building from old head (pre-r274460), you have to manually
bootstrap yacc first, e.g., something like this:
cd /usr/src/usr.bin/yacc make clean cleandepend make all
make install make clean cleandepend cd /usr/src make
buildworld
Hi, guys,
I've found the fix by forcing to add yacc(1) to bootstrap build.
Makefile.inc1, line 1277:
if ${BOOTSTRAPPING} 1001506 _yacc= lib/liby \
change to:
if ${BOOTSTRAPPING} 1201506 ## It is for test purposes only!!!
_yacc= lib/liby \
This can be set to 1001507 now; __FreeBSD_version was bumped
earlier today.
Nope, 1001506 is correct, i.e., the change was MFC'ed to stable/10 and
__FreeBSD_version was bumped to reflect it.
https://svnweb.freebsd.org/changeset/base/277087
Ah, right. Thank you for the correction.
Glen
pgp_QWHaQfNKT.pgp
Description: PGP signature
Re: r279278 failed to build (yacc: maximum table size exceeded)
On 25 February 2015 at 23:15, Jung-uk Kim j...@freebsd.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/25/2015 14:59, Arseny Nasokin wrote:
On 25 February 2015 at 22:14, Jung-uk Kim j...@freebsd.org
mailto:j...@freebsd.org wrote:
On 02/25/2015 14:05, Glen Barber wrote:
On Wed, Feb 25, 2015 at 10:51:31PM +0400, Arseny Nasokin wrote:
On 25 February 2015 at 20:27, Jung-uk Kim j...@freebsd.org
mailto:j...@freebsd.org
wrote:
Your installed yacc(1) is too old, i.e., your world was
built from head before r274460. FYI, this commit fixes the
above problem for building from stable:
https://svnweb.freebsd.org/changeset/base/278975
For building from old head (pre-r274460), you have to
manually bootstrap yacc first, e.g., something like this:
cd /usr/src/usr.bin/yacc make clean cleandepend make all
make install make clean cleandepend cd /usr/src make
buildworld
Hi, guys,
I've found the fix by forcing to add yacc(1) to bootstrap
build.
Makefile.inc1, line 1277:
if ${BOOTSTRAPPING} 1001506 _yacc= lib/liby \
change to:
if ${BOOTSTRAPPING} 1201506 ## It is for test purposes
only!!! _yacc= lib/liby \
This can be set to 1001507 now; __FreeBSD_version was bumped
earlier today.
Nope, 1001506 is correct, i.e., the change was MFC'ed to stable/10
and __FreeBSD_version was bumped to reflect it.
https://svnweb.freebsd.org/changeset/base/277087
Jung-uk Kim
Jung,
I have FreeBSD 11.0-CURRENT r265265 with OSRELDATE 1100020 and
invalid YACC. So This conditional expression must be fixed to check
if this 11.x and yacc is not changed.
Wow, that's more than 9-month old now.
In my hypothetical patch I set OSRELDATE to invalid abstract
future version, because it's only concept and I have no time to fix
it correctly now.
If you insist, you can try this:
- --- Makefile.inc1
+++ Makefile.inc1
@@ -1274,7 +1274,8 @@
_awk= usr.bin/awk
.endif
- -.if ${BOOTSTRAPPING} 1001506
+.if ${BOOTSTRAPPING} 1001506 || \
+(${BOOTSTRAPPING} = 110 ${BOOTSTRAPPING} 1100046)
_yacc= lib/liby \
usr.bin/yacc
(but I won't commit it.)
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJU7i1kAAoJEHyflib82/FGh9kH/07QOQ+xlPQVApJD+x1u/c4b
G1g4mmOhEKKOjVK9dJFKY1hvTiLYkOB3UDwJH8rmzbglInY+eepbD9Ac15Dtl90b
RFvNEB3B7Rwzt9ljg2zH/OQ6HnPCHgreF31ggkmKLszQ/Rrv62KTmN9ML4dkx897
7jAPwwtMb2XfLzyAc2fMNne3xl/zmdzafcqA+87UOUJ3Jb4rv35/x3kSrOqsMzvj
A3ufAepzG2J0+fH62ZP2L/FfuXoaKP0hlIpXZwNYAciSf+GAa7McYyu1aaRZQedF
1DSphDtSFnJKR+ltIvDL5WH98Zi0iOu5FHb9bLfW/s+bV+oxs4/ZQHtxsIejLN4=
=3xA9
-END PGP SIGNATURE-
Thank you,
It works well for me.
-- Eir Nym
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r279278 failed to build (yacc: maximum table size exceeded)
В Wed, 25 Feb 2015 12:27:06 -0500 Jung-uk Kim j...@freebsd.org пишет: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/25/2015 11:22, Ivan Klymenko wrote: В Wed, 25 Feb 2015 15:43:27 + Glen Barber g...@freebsd.org пишет: On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin wrote: I have clean svn tree with base/head branch. I try to build world, but I have some mysterious bugs. The latest is yacc failed to make c file on phase 4.3: === usr.sbin/acpi/iasl (depend) m4 -P -I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslparser.y aslcompiler.y yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y yacc: 89 shift/reduce conflicts. yacc: f - maximum table size exceeded *** Error code 2 /etc/make.conf is /dev/null. I've also tried empty /etc/src.conf with no luck. Out of curiosity, is your src tree mounted via NFS? Glen I have a similar problem on revision /usr/src # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213 Node Kind: directory Schedule: normal Last Changed Author: glebius Last Changed Rev: 279213 Last Changed Date: 2015-02-23 20:57:09 +0200 (Mon, 23 Feb 2015) http://pastebin.com/FuAUkBmX Source tree is on the zfs /usr/src # zfs list zroot/usr/src NAME USED AVAIL REFER MOUNTPOINT zroot/usr/src 1.35G 408G 1.35G /usr/src what is most surprising, the same revision successfully building for the other 2 computers, including amd64|zfs and i386|ufs. Your installed yacc(1) is too old, i.e., your world was built from head before r274460. FYI, this commit fixes the above problem for building from stable: https://svnweb.freebsd.org/changeset/base/278975 For building from old head (pre-r274460), you have to manually bootstrap yacc first, e.g., something like this: cd /usr/src/usr.bin/yacc make clean cleandepend make all make install make clean cleandepend cd /usr/src make buildworld Thank you - it solved the problem. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] load network config file from netif init script
On Monday, February 02, 2015 12:21:19 PM Roger Pau Monné wrote: Hello, r272959 broke compatibility with mfsBSD that stores the default network config file in /etc/rc.conf.d/network. In order to fix that load the network config file from netif also. I'm attaching a patch to restore previous functionality, but since I'm not an expert on rc.d init scripts I would like some feedback on whether this is the right approach or not. Thanks, Roger. If you are still looking for review, you can try freebsd-rc@ perhaps? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r279278 failed to build (yacc: maximum table size exceeded)
On Wednesday, February 25, 2015 03:15:36 PM Jung-uk Kim wrote:
On 02/25/2015 14:59, Arseny Nasokin wrote:
On 25 February 2015 at 22:14, Jung-uk Kim j...@freebsd.org
mailto:j...@freebsd.org wrote:
On 02/25/2015 14:05, Glen Barber wrote:
On Wed, Feb 25, 2015 at 10:51:31PM +0400, Arseny Nasokin wrote:
On 25 February 2015 at 20:27, Jung-uk Kim j...@freebsd.org
mailto:j...@freebsd.org
wrote:
Your installed yacc(1) is too old, i.e., your world was
built from head before r274460. FYI, this commit fixes the
above problem for building from stable:
https://svnweb.freebsd.org/changeset/base/278975
For building from old head (pre-r274460), you have to
manually bootstrap yacc first, e.g., something like this:
cd /usr/src/usr.bin/yacc make clean cleandepend make all
make install make clean cleandepend cd /usr/src make
buildworld
Hi, guys,
I've found the fix by forcing to add yacc(1) to bootstrap
build.
Makefile.inc1, line 1277:
if ${BOOTSTRAPPING} 1001506 _yacc= lib/liby \
change to:
if ${BOOTSTRAPPING} 1201506 ## It is for test purposes
only!!! _yacc= lib/liby \
This can be set to 1001507 now; __FreeBSD_version was bumped
earlier today.
Nope, 1001506 is correct, i.e., the change was MFC'ed to stable/10
and __FreeBSD_version was bumped to reflect it.
https://svnweb.freebsd.org/changeset/base/277087
Jung-uk Kim
Jung,
I have FreeBSD 11.0-CURRENT r265265 with OSRELDATE 1100020 and
invalid YACC. So This conditional expression must be fixed to check
if this 11.x and yacc is not changed.
Wow, that's more than 9-month old now.
In my hypothetical patch I set OSRELDATE to invalid abstract
future version, because it's only concept and I have no time to fix
it correctly now.
If you insist, you can try this:
--- Makefile.inc1
+++ Makefile.inc1
@@ -1274,7 +1274,8 @@
_awk=usr.bin/awk
.endif
-.if ${BOOTSTRAPPING} 1001506
+.if ${BOOTSTRAPPING} 1001506 || \
+(${BOOTSTRAPPING} = 110 ${BOOTSTRAPPING} 1100046)
_yacc= lib/liby \
usr.bin/yacc
(but I won't commit it.)
Maybe just make the check always be 1100046? It doesn't really hurt to
build yacc on more recent 10 stable does it?
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bombarded with LOR's with recent install
On Wednesday, February 25, 2015 10:19:32 AM Chris H wrote: On Wed, 25 Feb 2015 09:42:54 -0800 Chris H bsd-li...@bsdforge.com wrote On Wed, 25 Feb 2015 08:56:14 -0800 Chris H bsd-li...@bsdforge.com wrote I see somebody also reported something along these lines, recently; http://freebsd.1045724.n5.nabble.com/ufs-devfs-quot-lock-order-reversal-qu ot- on-poweroff-td5989901.html But there was no reported resolution. and again in January, as well. https://www.mail-archive.com/freebsd-current@freebsd.org/msg158784.html Is there any way to switch off WITNESS, INVARIANTS SKIPSPIN in the GENERIC that is installed, outside of building a new kernel? The VFS ones are more complicated. You can add options 'WITNESS_NO_VNODE' to your kernel config to limit the noise. (Someone should turn that into a sysctl/tunable so it can be enabled in a stock kernel.) -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: msk0 watchdog timeout Marvel 88E8071
On Monday, February 23, 2015 09:00:24 AM David Demelier wrote: Le 21/02/2015 23:46, Roosevelt Littleton a écrit : My msk0 is not even functional and my wifi is my only usable connection to the internet. I have the same problem with my Marvell Yukon 2. Working fine in 10.0, now broken in 10.1. Can you narrow down the commit that broke it for you? I know there were some msk(4) changes merged between 10.0 and 10.1 that fixed msk(4) for some other folks. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Shared object libsodium.so.13 not found, required by dnscrypt-proxy
On Tue, Feb 24, 2015 at 6:05 PM, Miguel Clara miguelmcl...@gmail.com
wrote:
On Wed, Feb 25, 2015 at 1:58 AM, Miguel Clara miguelmcl...@gmail.com
wrote:
On Wed, Feb 25, 2015 at 12:26 AM, Miguel Clara miguelmcl...@gmail.com
wrote:
On Tue, Feb 24, 2015 at 11:11 PM, Kevin Oberman rkober...@gmail.com
wrote:
On Tue, Feb 24, 2015 at 10:53 AM, Miguel Clara miguelmcl...@gmail.com
wrote:
On Tue, Feb 24, 2015 at 6:13 PM, Garrett Cooper yaneurab...@gmail.com
wrote:
On Feb 24, 2015, at 6:35, Miguel Clara miguelmcl...@gmail.com
wrote:
]# rcorder /etc/rc.d/* /usr/local/etc/rc.d/* /dev/null
rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown
provision
`kerberos'
rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown
provision
`named'
rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before
unknown
provision `unbound'
rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'.
rcorder: Circular dependency on provision `dbus' in file
`/usr/local/etc/rc.d/webcamd'.
rcorder: Circular dependency on provision `ldconfig' in file
`/usr/local/etc/rc.d/dnscrypt-proxy'.
rcorder: Circular dependency on provision `mountcritremote' in file
`/etc/rc.d/devfs'.
rcorder: Circular dependency on provision `mountcritremote' in file
`/etc/rc.d/mdconfig2'.
rcorder: Circular dependency on provision `mountcritremote' in file
`/etc/rc.d/newsyslog'.
rcorder: Circular dependency on provision `mountcritremote' in file
`/etc/rc.d/syslogd'.
rcorder: Circular dependency on provision `NETWORKING' in file
`/etc/rc.d/kdc'.
rcorder: Circular dependency on provision `ldconfig' in file
`/etc/rc.d/SERVERS'.
rcorder: Circular dependency on provision `mountcritremote' in file
`/etc/rc.d/archdep'.
rcorder: Circular dependency on provision `mountcritremote' in file
`/etc/rc.d/SERVERS'.
rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' has
no
providers.
rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'.
rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has
no
providers.
# rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | awk
‘/SERVERS|cleanvar|ldconfig|dbus/ { print NR, $0 }’
rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown
provision
`kerberos'
rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown
provision
`named'
rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before
unknown
provision `unbound'
rcorder: Circular dependency on file `/usr/local/etc/rc.d/webcamd'.
rcorder: Circular dependency on provision `dbus' in file
`/usr/local/etc/rc.d/webcamd'.
rcorder: Circular dependency on provision `ldconfig' in file
`/usr/local/etc/rc.d/dnscrypt-proxy'.
rcorder: Circular dependency on provision `mountcritremote' in file
`/etc/rc.d/devfs'.
rcorder: Circular dependency on provision `mountcritremote' in file
`/etc/rc.d/mdconfig2'.
rcorder: Circular dependency on provision `mountcritremote' in file
`/etc/rc.d/newsyslog'.
rcorder: Circular dependency on provision `mountcritremote' in file
`/etc/rc.d/syslogd'.
rcorder: Circular dependency on provision `NETWORKING' in file
`/etc/rc.d/kdc'.
rcorder: Circular dependency on provision `ldconfig' in file
`/etc/rc.d/SERVERS'.
rcorder: Circular dependency on provision `mountcritremote' in file
`/etc/rc.d/archdep'.
rcorder: Circular dependency on provision `mountcritremote' in file
`/etc/rc.d/SERVERS'.
rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' has
no
providers.
rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'.
rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald' has
no
providers.
cleanvar: Command not found.
dbus/: Command not found.
Note that this is still with the change to dnscrypt-ptoxy REQUIRE
(adding ldconfig)
Your rcorder is 50 shades of broken :(. Please remove all local
modifications to scripts, then repost the output of the rcorder
commands
again. I suspect what’s going wrong is the result of some of my
changes to
remove etc/rc.d based on build knobs…
Cheers,
So much like the movies them... damn :X
I don't recall any changes to the rc.d scripts except the one to
dnscrypt-proxy (adding the ldconfig REQUIRE)
I also don't really know what to make of the output... expect this
part:
Circular dependency on provision, but the man says:
A set of files has a circular dependency which was detected while
processing the stated condition.
So it should mean that 'A' requires 'B' but 'B' requires 'A'... but
this
does not seem to be the case...
I guess I'll have to go one by one and see if I can identify issue. But
first I'll make sure the ports that use those rc.d scripts are up to
date.
Just to save a bit of time, many RC scripts are messed up at install
time.
One of the worst I have is for security/trousers-tddl. It is a mess. It
wants kerberos and
Re: Shared object libsodium.so.13 not found, required by dnscrypt-proxy
On Wed, Feb 25, 2015 at 9:58 PM, Kevin Oberman rkober...@gmail.com wrote:
On Tue, Feb 24, 2015 at 6:05 PM, Miguel Clara miguelmcl...@gmail.com
wrote:
On Wed, Feb 25, 2015 at 1:58 AM, Miguel Clara miguelmcl...@gmail.com
wrote:
On Wed, Feb 25, 2015 at 12:26 AM, Miguel Clara miguelmcl...@gmail.com
wrote:
On Tue, Feb 24, 2015 at 11:11 PM, Kevin Oberman rkober...@gmail.com
wrote:
On Tue, Feb 24, 2015 at 10:53 AM, Miguel Clara miguelmcl...@gmail.com
wrote:
On Tue, Feb 24, 2015 at 6:13 PM, Garrett Cooper
yaneurab...@gmail.com
wrote:
On Feb 24, 2015, at 6:35, Miguel Clara miguelmcl...@gmail.com
wrote:
]# rcorder /etc/rc.d/* /usr/local/etc/rc.d/* /dev/null
rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown
provision
`kerberos'
rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown
provision
`named'
rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before
unknown
provision `unbound'
rcorder: Circular dependency on file
`/usr/local/etc/rc.d/webcamd'.
rcorder: Circular dependency on provision `dbus' in file
`/usr/local/etc/rc.d/webcamd'.
rcorder: Circular dependency on provision `ldconfig' in file
`/usr/local/etc/rc.d/dnscrypt-proxy'.
rcorder: Circular dependency on provision `mountcritremote' in
file
`/etc/rc.d/devfs'.
rcorder: Circular dependency on provision `mountcritremote' in
file
`/etc/rc.d/mdconfig2'.
rcorder: Circular dependency on provision `mountcritremote' in
file
`/etc/rc.d/newsyslog'.
rcorder: Circular dependency on provision `mountcritremote' in
file
`/etc/rc.d/syslogd'.
rcorder: Circular dependency on provision `NETWORKING' in file
`/etc/rc.d/kdc'.
rcorder: Circular dependency on provision `ldconfig' in file
`/etc/rc.d/SERVERS'.
rcorder: Circular dependency on provision `mountcritremote' in
file
`/etc/rc.d/archdep'.
rcorder: Circular dependency on provision `mountcritremote' in
file
`/etc/rc.d/SERVERS'.
rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd'
has no
providers.
rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'.
rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald'
has no
providers.
# rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | awk
‘/SERVERS|cleanvar|ldconfig|dbus/ { print NR, $0 }’
rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown
provision
`kerberos'
rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown
provision
`named'
rcorder: file `/usr/local/etc/rc.d/dnscrypt-proxy' is before
unknown
provision `unbound'
rcorder: Circular dependency on file
`/usr/local/etc/rc.d/webcamd'.
rcorder: Circular dependency on provision `dbus' in file
`/usr/local/etc/rc.d/webcamd'.
rcorder: Circular dependency on provision `ldconfig' in file
`/usr/local/etc/rc.d/dnscrypt-proxy'.
rcorder: Circular dependency on provision `mountcritremote' in
file
`/etc/rc.d/devfs'.
rcorder: Circular dependency on provision `mountcritremote' in
file
`/etc/rc.d/mdconfig2'.
rcorder: Circular dependency on provision `mountcritremote' in
file
`/etc/rc.d/newsyslog'.
rcorder: Circular dependency on provision `mountcritremote' in
file
`/etc/rc.d/syslogd'.
rcorder: Circular dependency on provision `NETWORKING' in file
`/etc/rc.d/kdc'.
rcorder: Circular dependency on provision `ldconfig' in file
`/etc/rc.d/SERVERS'.
rcorder: Circular dependency on provision `mountcritremote' in
file
`/etc/rc.d/archdep'.
rcorder: Circular dependency on provision `mountcritremote' in
file
`/etc/rc.d/SERVERS'.
rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd'
has no
providers.
rcorder: Circular dependency on file `/usr/local/etc/rc.d/uuidd'.
rcorder: requirement `usbd' in file `/usr/local/etc/rc.d/hald'
has no
providers.
cleanvar: Command not found.
dbus/: Command not found.
Note that this is still with the change to dnscrypt-ptoxy REQUIRE
(adding ldconfig)
Your rcorder is 50 shades of broken :(. Please remove all local
modifications to scripts, then repost the output of the rcorder
commands
again. I suspect what’s going wrong is the result of some of my
changes to
remove etc/rc.d based on build knobs…
Cheers,
So much like the movies them... damn :X
I don't recall any changes to the rc.d scripts except the one to
dnscrypt-proxy (adding the ldconfig REQUIRE)
I also don't really know what to make of the output... expect this
part:
Circular dependency on provision, but the man says:
A set of files has a circular dependency which was detected while
processing the stated condition.
So it should mean that 'A' requires 'B' but 'B' requires 'A'... but
this
does not seem to be the case...
I guess I'll have to go one by one and see if I can identify issue.
But
first I'll make sure the ports that use those rc.d scripts are up to
date.
Just to save a bit of time, many RC scripts are messed up at install
time.
Re: Shared object libsodium.so.13 not found, required by dnscrypt-proxy
On Feb 25, 2015, at 14:19, Miguel Clara miguelmcl...@gmail.com wrote: ... I noticed this too, but in that case why doesn't it affect all users? (or all the ones using dnscrypt+local_unbound) maybe something changed in NETWORKING recently? Hum: https://svnweb.freebsd.org/base/head/etc/rc.d/NETWORKING?r1=275299r2=278704 Interesting, as I am using the most recent version which does not REQUIRE local_unbound I'm even more confused now :| So it has to come after SERVERS but before local_unbound. But NETWORKING depends on local_unbound they are both dependent on NEWORKING which has to be after SERVERS. Can you say fubar! Clearly broken. And this means that removing SERVERS will re-shuffle the order more appropriately. It seems that the behavior of rcorder is not as documented as well as being undefined when circular dependencies occur. The man page says that rcorder aborts when it encounters a circular dependency, but that is not the case. It probably is best that it not die, but that leaves things in an unknown and inconsistant state, which is also a very bad idea. I guess when a circular dependency is encountered, a dichotomy occurs. Now you know why I’m so curious about all of this stuff. When I was working on ^/projects/building-blocks, I was able to move most of these pieces around by changing REQUIRE: to BEFORE:, but I noticed that it changes the rcorder a bit, so I haven’t been super gung ho in implementing my change. I think there are a couple bugs present on 9-STABLE/10-STABLE/11-CURRENT: - Things go awry if named is removed/not installed. - Things go awry if local_unbound is removed (which would have been the case if the rc.d script was removed from your system, which existed before my changes). - Other rc.d scripts not being present might break assumptions. I need to create dummy providers for certain logical stages (DNS is one of them) to solve part of this problem and provide third parties with a mechanism that can be depended on (I wish applications were written in a more robust manner to fail gracefully and retry instead of failing flat on their face, but as I’ve seen at several jobs, getting developers to fail, then retry is hard :(…). Another short-term hack: Install dummy/no-op providers so the ordering is preserved, then remove the hacks after all of the bugs have been shaken out. Thanks! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Shared object libsodium.so.13 not found, required by dnscrypt-proxy
On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper yaneurab...@gmail.com wrote: On Feb 25, 2015, at 14:19, Miguel Clara miguelmcl...@gmail.com wrote: ... I noticed this too, but in that case why doesn't it affect all users? (or all the ones using dnscrypt+local_unbound) maybe something changed in NETWORKING recently? Hum: https://svnweb.freebsd.org/base/head/etc/rc.d/NETWORKING?r1=275299r2=278704 Interesting, as I am using the most recent version which does not REQUIRE local_unbound I'm even more confused now :| So it has to come after SERVERS but before local_unbound. But NETWORKING depends on local_unbound they are both dependent on NEWORKING which has to be after SERVERS. Can you say fubar! Clearly broken. And this means that removing SERVERS will re-shuffle the order more appropriately. It seems that the behavior of rcorder is not as documented as well as being undefined when circular dependencies occur. The man page says that rcorder aborts when it encounters a circular dependency, but that is not the case. It probably is best that it not die, but that leaves things in an unknown and inconsistant state, which is also a very bad idea. I guess when a circular dependency is encountered, a dichotomy occurs. Now you know why I’m so curious about all of this stuff. When I was working on ^/projects/building-blocks, I was able to move most of these pieces around by changing REQUIRE: to BEFORE:, but I noticed that it changes the rcorder a bit, so I haven’t been super gung ho in implementing my change. I think there are a couple bugs present on 9-STABLE/10-STABLE/11-CURRENT: - Things go awry if named is removed/not installed. - Things go awry if local_unbound is removed (which would have been the case if the rc.d script was removed from your system, which existed before my changes). - Other rc.d scripts not being present might break assumptions. I need to create dummy providers for certain logical stages (DNS is one of them) to solve part of this problem and provide third parties with a mechanism that can be depended on (I wish applications were written in a more robust manner to fail gracefully and retry instead of failing flat on their face, but as I’ve seen at several jobs, getting developers to fail, then retry is hard :(…). Another short-term hack: Install dummy/no-op providers so the ordering is preserved, then remove the hacks after all of the bugs have been shaken out. Thanks! Garret, Also undocumented (except in rcorder.c) is that the lack of a provider is not an error. This effectively makes a list of providers into an OR. So, for name service the normal list is named local_unbound unbound and any will work for ordering and having none is a no-op, so if you don't run any nameserver (or kerberos or whatever provider), it is not an issue. As long as rcorder finds a provider, it will be used to set the order, but the lack of any or all providers just means that the specified provider is ignored and if a REQUIRES or BEFORE lists no existing providers, the statement is simply ignored. The real problem is that there is no defined rule for behavior in the event of a circular dependency and any change to any decision point in the ordering process may change the way the ordering flips. That is why these things are such a royal pain to debug. A change in any rc.d script may cause the ordering of seemingly unrelated scripts to change, perhaps drastically, and the error messages, while not misleading, is only a starting point in tracking this down. This means there may be time bombs that break working ports without their being touched or even re-installed. And the triggering change my, itself be correct. -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Shared object libsodium.so.13 not found, required by dnscrypt-proxy
On Feb 25, 2015, at 18:08, Kevin Oberman rkober...@gmail.com wrote: On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper yaneurab...@gmail.com wrote: On Feb 25, 2015, at 14:19, Miguel Clara miguelmcl...@gmail.com wrote: ... I noticed this too, but in that case why doesn't it affect all users? (or all the ones using dnscrypt+local_unbound) maybe something changed in NETWORKING recently? Hum: https://svnweb.freebsd.org/base/head/etc/rc.d/NETWORKING?r1=275299r2=278704 Interesting, as I am using the most recent version which does not REQUIRE local_unbound I'm even more confused now :| So it has to come after SERVERS but before local_unbound. But NETWORKING depends on local_unbound they are both dependent on NEWORKING which has to be after SERVERS. Can you say fubar! Clearly broken. And this means that removing SERVERS will re-shuffle the order more appropriately. It seems that the behavior of rcorder is not as documented as well as being undefined when circular dependencies occur. The man page says that rcorder aborts when it encounters a circular dependency, but that is not the case. It probably is best that it not die, but that leaves things in an unknown and inconsistant state, which is also a very bad idea. I guess when a circular dependency is encountered, a dichotomy occurs. Now you know why I’m so curious about all of this stuff. When I was working on ^/projects/building-blocks, I was able to move most of these pieces around by changing REQUIRE: to BEFORE:, but I noticed that it changes the rcorder a bit, so I haven’t been super gung ho in implementing my change. I think there are a couple bugs present on 9-STABLE/10-STABLE/11-CURRENT: - Things go awry if named is removed/not installed. - Things go awry if local_unbound is removed (which would have been the case if the rc.d script was removed from your system, which existed before my changes). - Other rc.d scripts not being present might break assumptions. I need to create dummy providers for certain logical stages (DNS is one of them) to solve part of this problem and provide third parties with a mechanism that can be depended on (I wish applications were written in a more robust manner to fail gracefully and retry instead of failing flat on their face, but as I’ve seen at several jobs, getting developers to fail, then retry is hard :(…). Another short-term hack: Install dummy/no-op providers so the ordering is preserved, then remove the hacks after all of the bugs have been shaken out. Thanks! Garret, Also undocumented (except in rcorder.c) is that the lack of a provider is not an error. This effectively makes a list of providers into an OR. So, for name service the normal list is named local_unbound unbound and any will work for ordering and having none is a no-op, so if you don't run any nameserver (or kerberos or whatever provider), it is not an issue. As long as rcorder finds a provider, it will be used to set the order, but the lack of any or all providers just means that the specified provider is ignored and if a REQUIRES or BEFORE lists no existing providers, the statement is simply ignored. The real problem is that there is no defined rule for behavior in the event of a circular dependency and any change to any decision point in the ordering process may change the way the ordering flips. That is why these things are such a royal pain to debug. A change in any rc.d script may cause the ordering of seemingly unrelated scripts to change, perhaps drastically, and the error messages, while not misleading, is only a starting point in tracking this down. This means there may be time bombs that break working ports without their being touched or even re-installed. And the triggering change my, itself be correct. Or etc/rc.d/named... PROVIDES: DNS I'm going to post a fix up for this on arch@/rc@ because it needs to be solved in a saner way -- especially for systems that are pedantic about rcorder, like our version at $work. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bombarded with LOR's with recent install
On Wed, 25 Feb 2015 16:09:50 -0500 John Baldwin j...@freebsd.org wrote On Wednesday, February 25, 2015 10:19:32 AM Chris H wrote: On Wed, 25 Feb 2015 09:42:54 -0800 Chris H bsd-li...@bsdforge.com wrote On Wed, 25 Feb 2015 08:56:14 -0800 Chris H bsd-li...@bsdforge.com wrote I see somebody also reported something along these lines, recently; http://freebsd.1045724.n5.nabble.com/ufs-devfs-quot-lock-order-reversal-qu ot- on-poweroff-td5989901.html But there was no reported resolution. and again in January, as well. https://www.mail-archive.com/freebsd-current@freebsd.org/msg158784.html Is there any way to switch off WITNESS, INVARIANTS SKIPSPIN in the GENERIC that is installed, outside of building a new kernel? The VFS ones are more complicated. You can add options 'WITNESS_NO_VNODE' to your kernel config to limit the noise. (Someone should turn that into a sysctl/tunable so it can be enabled in a stock kernel.) Aside from my own concerns, I thought it might be useful for others to know, as the LOR's were produced by the kernel installed from the distribution media (disk 1). Also, in the event I'm not the *only* one experiencing these LOR's. It might be nice replace the kernel that's currently on the media, with one that won't do this. As I imagine many who install FreeBSD from the media, might never build their own. The sysctl/tunable sounds like a real winner. :) Thanks for taking the time to respond, John. --Chris -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
