Re: make delete-old/delete-old-libs issue after r264673 build
On Sat, Apr 19, 2014 at 1:05 AM, Jung-uk Kim j...@freebsd.org wrote: On 2014-04-18 23:46:46 -0400, Thomas Hoffmann wrote: After building at -CURRENT amd64 r264673, I got the following errors running 'make delete-old' and 'make delete-old-libs': ... This should be fixed in r264674. Jung-uk Kim With r264674, I no longer see those errors reported at delete-old or delete-old-libs, however, I now see those errors reported at the beginning of buildworld, buildkernel, installkernel, and installworld. With r264673 I only saw the errors at delete-old and delete-old-libs. -Tom ___ 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: make delete-old/delete-old-libs issue after r264673 build
On 2014-04-19 02:14:58 -0400, Thomas Hoffmann wrote: On Sat, Apr 19, 2014 at 1:05 AM, Jung-uk Kim j...@freebsd.org mailto:j...@freebsd.org wrote: On 2014-04-18 23:46:46 -0400, Thomas Hoffmann wrote: After building at -CURRENT amd64 r264673, I got the following errors running 'make delete-old' and 'make delete-old-libs': ... This should be fixed in r264674. Jung-uk Kim With r264674, I no longer see those errors reported at delete-old or delete-old-libs, however, I now see those errors reported at the beginning of buildworld, buildkernel, installkernel, and installworld. With r264673 I only saw the errors at delete-old and delete-old-libs. I can't reproduce it. Do you have the bsd.mkopt.mk in /usr/share/mk, i.e., did you do installworld? Jung-uk Kim ___ 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: make delete-old/delete-old-libs issue after r264673 build
On Sat, Apr 19, 2014 at 2:27 AM, Jung-uk Kim j...@freebsd.org wrote: On 2014-04-19 02:14:58 -0400, Thomas Hoffmann wrote: On Sat, Apr 19, 2014 at 1:05 AM, Jung-uk Kim j...@freebsd.org mailto:j...@freebsd.org wrote: On 2014-04-18 23:46:46 -0400, Thomas Hoffmann wrote: After building at -CURRENT amd64 r264673, I got the following errors running 'make delete-old' and 'make delete-old-libs': ... This should be fixed in r264674. Jung-uk Kim With r264674, I no longer see those errors reported at delete-old or delete-old-libs, however, I now see those errors reported at the beginning of buildworld, buildkernel, installkernel, and installworld. With r264673 I only saw the errors at delete-old and delete-old-libs. I can't reproduce it. Do you have the bsd.mkopt.mk in /usr/share/mk, i.e., did you do installworld? Jung-uk Kim Had I taken a bit more time to think on it before my last post, I would have realized that what I was seeing is exactly what I should have expected. In order to reproduce my problem, you would have had to build at r264673 and then again at r264674. When I built at r264673, I was using the last good *.mk installed from r264633. That is why I did not see the errors for buildworld, buildkernel, installkernel and installworld. But, since installworld at r264673 installed the bad *.mk, that is why I saw the errors for the subsequent delete-old and delete-old-libs. When I re-built at r264674, I was still using the bad *.mk installed from r264673. That is why I saw the errors for buildworld, buildkernel, installkernel and installworld. But, since installworld at r264674 installed the good (i.e., fixed) *.mk, that is why I no longer saw the errors for the subsequent delete-old and delete-old-libs. My apologies for not realizing this earlier. -Tom ___ 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
UFS lock order reversal stack trace with r264677 on i386
I've noticed this as of late on my i386 -CURRENT Thinkpad T43 when I perform some file operations, but an exact reproduction case I've not yet stumbled upon: Apr 20 01:29:32 lemon kernel: lock order reversal: Apr 20 01:29:32 lemon kernel: 1st 0xc5832358 bufwait (bufwait) @ /usr/home/tyler/source/github/freebsd/sys/kern/vfs_bio.c:3081 Apr 20 01:29:32 lemon kernel: 2nd 0xc6f1d600 dirhash (dirhash) @ /usr/home/tyler/source/github/freebsd/sys/ufs/ufs/ufs_dirhash.c:284 Apr 20 01:29:32 lemon kernel: KDB: stack backtrace: Apr 20 01:29:32 lemon kernel: db_trace_self_wrapper(c115aa9d,79732f64,66752f73,66752f73,66752f73,...) at db_trace_self_wrapper+0x2d/frame 0xe93ba918 Apr 20 01:29:32 lemon kernel: kdb_backtrace(c115e882,c6f1d600,c1192fe7,c5dae950,c1192c15,...) at kdb_backtrace+0x30/frame 0xe93ba980 Apr 20 01:29:32 lemon kernel: witness_checkorder(c6f1d600,9,c1192c15,11c,0,...) at witness_checkorder+0xd04/frame 0xe93ba9cc Apr 20 01:29:32 lemon kernel: _sx_xlock(c6f1d600,0,c1192c15,11c,c5832300,...) at _sx_xlock+0x75/frame 0xe93ba9fc Apr 20 01:29:32 lemon kernel: ufsdirhash_remove(c6c26bc8,db6e02fc,2fc,e93baa58,e93baa54,...) at ufsdirhash_remove+0x37/frame 0xe93baa24 Apr 20 01:29:32 lemon kernel: ufs_dirremove(c6c1f238,c73c0d98,400800c,0,c6c1f238,...) at ufs_dirremove+0x12c/frame 0xe93baa68 Apr 20 01:29:32 lemon kernel: ufs_remove(e93bac00,c11683ae,a8b,e93babfc,0,...) at ufs_remove+0x76/frame 0xe93baaac Apr 20 01:29:32 lemon kernel: VOP_REMOVE_APV(c13e8d1c,e93bac00,c73c2e6c,e93babd4,81a5b18,...) at VOP_REMOVE_APV+0xfe/frame 0xe93baad8 Apr 20 01:29:32 lemon kernel: kern_unlinkat(c6958000,ff9c,81a5b18,0,0) at kern_unlinkat+0x27a/frame 0xe93bac24 Apr 20 01:29:32 lemon kernel: sys_unlink(c6958000,e93bacc8,c0feeaef,c1c25c90,0,...) at sys_unlink+0x32/frame 0xe93bac40 Apr 20 01:29:32 lemon kernel: syscall(e93bad08) at syscall+0x30c/frame 0xe93bacfc Apr 20 01:29:32 lemon kernel: Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe93bacfc Apr 20 01:29:32 lemon kernel: --- syscall (10, FreeBSD ELF32, sys_unlink), eip = 0x2848bd37, esp = 0xbfbfd1bc, ebp = 0xbfbfd248 --- Apr 20 01:29:54 lemon kernel: lock order reversal: Apr 20 01:29:54 lemon kernel: 1st 0xc699e388 ufs (ufs) @ /usr/home/tyler/source/github/freebsd/sys/kern/vfs_subr.c:2101 Apr 20 01:29:54 lemon kernel: 2nd 0xc5859e98 bufwait (bufwait) @ /usr/home/tyler/source/github/freebsd/sys/ufs/ffs/ffs_vnops.c:262 Apr 20 01:29:54 lemon kernel: 3rd 0xc7d27c68 ufs (ufs) @ /usr/home/tyler/source/github/freebsd/sys/kern/vfs_subr.c:2101 Apr 20 01:29:54 lemon kernel: KDB: stack backtrace: Apr 20 01:29:54 lemon kernel: db_trace_self_wrapper(c115aa9d,762f6e72,735f7366,2e726275,31323a63,...) at db_trace_self_wrapper+0x2d/frame 0xe93ba260 Apr 20 01:29:54 lemon kernel: kdb_backtrace(c115e89b,c7d27c68,c1144d4e,c5dae8e8,c11683ae,...) at kdb_backtrace+0x30/frame 0xe93ba2c4 Apr 20 01:29:54 lemon kernel: witness_checkorder(c7d27c68,9,c11683ae,835,c7d27c88,...) at witness_checkorder+0xd04/frame 0xe93ba310 Apr 20 01:29:54 lemon kernel: __lockmgr_args(c7d27c68,80100,c7d27c88,0,0,...) at __lockmgr_args+0x8f3/frame 0xe93ba3f0 Apr 20 01:29:54 lemon kernel: ffs_lock(e93ba470,c116537f,c5d8d110,c5d93840,c5d8d110,...) at ffs_lock+0x87/frame 0xe93ba42c Apr 20 01:29:54 lemon kernel: VOP_LOCK1_APV(c13e8d1c,e93ba470,c116537f,227,c13fe1f0,...) at VOP_LOCK1_APV+0x10a/frame 0xe93ba458 Apr 20 01:29:54 lemon kernel: _vn_lock(c7d27c34,80100,c11683ae,835,c11675a0,...) at Apr 20 01:29:54 lemon kernel: _vn_lock+0xa6/frame 0xe93ba498 Apr 20 01:29:54 lemon kernel: vget(c7d27c34,80100,c6958000,57,0,...) at vget+0x74/frame 0xe93ba4d0 Apr 20 01:29:54 lemon kernel: vfs_hash_get(c63fad20,70aa44,8,c6958000,e93ba5d0,...) at vfs_hash_get+0xfc/frame 0xe93ba4fc Apr 20 01:29:54 lemon kernel: ffs_vgetf(c63fad20,70aa44,8,e93ba5d0,1,...) at ffs_vgetf+0x44/frame 0xe93ba558 Apr 20 01:29:54 lemon kernel: softdep_sync_buf(c699e354,c5859e40,1,0,0,...) at softdep_sync_buf+0xbdf/frame 0xe93ba5e8 Apr 20 01:29:54 lemon kernel: ffs_syncvnode(c699e354,1,0,c13c3cdc,0,...) at ffs_syncvnode+0x2dd/frame 0xe93ba640 Apr 20 01:29:54 lemon kernel: ffs_truncate(c699e354,200,0,880,c5ed0300,...) at ffs_truncate+0x6eb/frame 0xe93ba Apr 20 01:29:54 lemon kernel: 7f0 Apr 20 01:29:54 lemon kernel: ufs_direnter(c699e354,c7d27c34,e93ba8b8,e93babcc,0,...) at ufs_direnter+0x79e/fra Apr 20 01:29:54 lemon kernel: me 0xe93ba870 Apr 20 01:29:54 lemon kernel: ufs_makeinode(e93babb8,e93babcc) at Apr 20 01:29:54 lemon kernel: ufs_makeinode+0x534/frame 0xe93ba9f0 Apr 20 01:29:54 lemon kernel: ufs_create(e93baad8,614,c63fad30,2,c63fad74,...) at Apr 20 01:29:54 lemon kernel: ufs_create+0x2f/frame 0xe93baa04 Apr 20 01:29:54 lemon kernel: VOP_CREATE_APV(c13e8d1c,e93baad8,e93babcc,e93baa68,c0acc930,...) at VOP_CREATE_APV+0xfe/frame 0xe93baa30 Apr 20 01:29:55 lemon kernel: vn_open_cred(e93bab70,e93babfc,180,0,c5ed0300,c6960118) at vn_open_cred+0x2f0/frame 0xe93bab00 Apr 20 01:29:55 lemon
Re: Ordering for network-sensitive rc scripts
On Apr 17, 2014, at 2:21 AM, David Chisnall thera...@freebsd.org wrote: For a little while, I've had an issue with the machine that sits on the edge of my network deciding to start avahi as soon as a network is available, meaning that it then runs mDNS advertisements on the external interface and not the wireless one, requiring a manual restart once the machine boots. I'm now seeing something similar with pf - it manages to start before the external interface comes up and so silently ignores all of the rules for routing packets off the network. Do we have a mechanism for stating that certain services should not be started until ALL of the interfaces are up, rather than just the first one? Or even of restarting them when a new network appears? devd network events will allow you to do this on a per-network basis. The script that you run can then determine if the relevant criteria are in place and then do something... Warner ___ 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: make delete-old/delete-old-libs issue after r264673 build
On Sat, Apr 19, 2014 at 9:29 PM, Warner Losh i...@bsdimp.com wrote: bad mk files? jkim@ resolved this for me w/ r264674. ___ 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: make delete-old/delete-old-libs issue after r264673 build
On Apr 19, 2014, at 4:11 AM, Thomas Hoffmann trh...@gmail.com wrote: On Sat, Apr 19, 2014 at 2:27 AM, Jung-uk Kim j...@freebsd.org wrote: On 2014-04-19 02:14:58 -0400, Thomas Hoffmann wrote: On Sat, Apr 19, 2014 at 1:05 AM, Jung-uk Kim j...@freebsd.org mailto:j...@freebsd.org wrote: On 2014-04-18 23:46:46 -0400, Thomas Hoffmann wrote: After building at -CURRENT amd64 r264673, I got the following errors running 'make delete-old' and 'make delete-old-libs': ... This should be fixed in r264674. Jung-uk Kim With r264674, I no longer see those errors reported at delete-old or delete-old-libs, however, I now see those errors reported at the beginning of buildworld, buildkernel, installkernel, and installworld. With r264673 I only saw the errors at delete-old and delete-old-libs. I can't reproduce it. Do you have the bsd.mkopt.mk in /usr/share/mk, i.e., did you do installworld? Jung-uk Kim Had I taken a bit more time to think on it before my last post, I would have realized that what I was seeing is exactly what I should have expected. In order to reproduce my problem, you would have had to build at r264673 and then again at r264674. When I built at r264673, I was using the last good *.mk installed from r264633. That is why I did not see the errors for buildworld, buildkernel, installkernel and installworld. But, since installworld at r264673 installed the bad *.mk, that is why I saw the errors for the subsequent delete-old and delete-old-libs. When I re-built at r264674, I was still using the bad *.mk installed from r264673. That is why I saw the errors for buildworld, buildkernel, installkernel and installworld. But, since installworld at r264674 installed the good (i.e., fixed) *.mk, that is why I no longer saw the errors for the subsequent delete-old and delete-old-libs. bad mk files? Warner ___ 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
