Re: Kernel Panic in frag6_slowtimeo
On 21.11.2014 09:10, Shawn Webb wrote: Looks like I’m getting a kernel panic on heavy work loads (poudriere run with 10 build slaves on an Intel Core i7 box). Below is a link to an imgur album of screenshots I took with my phone. Do you have VIMAGE option in your kernel? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [HEADSUP] man(1) now uses mandoc
Thanks! 2014-11-23 1:18 GMT+01:00 Baptiste Daroussin b...@freebsd.org: Hi, The default renderer on HEAD has been switched to mandoc(1) by default The man(1) command has been instrumented to first test the manpage and fallback on groff if the man page cannot be rendered with mandoc(1). If base is built without groff then man(1) recommands to install groff from packages. makewhatis(1), apropos(1) have not yet been switched to mandoc(1) equivalent. Best regards, Bapt ___ 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: [HEADSUP] man(1) now uses mandoc
Thank you. — Joel 23 nov 2014 kl. 01:18 skrev Baptiste Daroussin b...@freebsd.org: Hi, The default renderer on HEAD has been switched to mandoc(1) by default The man(1) command has been instrumented to first test the manpage and fallback on groff if the man page cannot be rendered with mandoc(1). If base is built without groff then man(1) recommands to install groff from packages. makewhatis(1), apropos(1) have not yet been switched to mandoc(1) equivalent. Best regards, Bapt ___ 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: [HEADSUP] man(1) now uses mandoc
On Sun, 23 Nov 2014, Baptiste Daroussin wrote: The default renderer on HEAD has been switched to mandoc(1) by default The man(1) command has been instrumented to first test the manpage and fallback on groff if the man page cannot be rendered with mandoc(1). If base is built without groff then man(1) recommands to install groff from packages. makewhatis(1), apropos(1) have not yet been switched to mandoc(1) equivalent. Thanks and congratulations to all involved! ___ 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: zfs/vfs lockups, via poudriere
On Sun, 2014-11-23 at 00:09 +0200, Andriy Gapon wrote: On 22/11/2014 21:20, Sean Bruno wrote: bdrewery reported a vfs/zfs condition where operations will stall out and block (rm, mv, file) during a poudriere build. I've hit this now and it seems to be alleviated by setting vfs.lookup_shared=0 I seem to be able to trivially reproduce this on my builders and want to know if anyone is looking to diagnose this further. original message: https://lists.freebsd.org/pipermail/freebsd-fs/2014-September/020035.html On my builders I see: procstat -kka | grep zfs 0 100666 kernel zfs_vn_rele_task mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x2ad taskqueue_thread_loop+0xf5 fork_exit+0x9a fork_trampoline+0xe 3 100151 zfskern arc_reclaim_thre mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x1ad arc_reclaim_thread+0x288 fork_exit+0x9a fork_trampoline+0xe 3 100152 zfskern l2arc_feed_threa mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x1ad l2arc_feed_thread+0x16f fork_exit+0x9a fork_trampoline+0xe 3 100657 zfskern trim zroot mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x1ad trim_thread+0x9e fork_exit+0x9a fork_trampoline+0xe 3 100675 zfskern txg_thread_enter mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x190 txg_quiesce_thread+0x39b fork_exit+0x9a fork_trampoline+0xe 3 100676 zfskern txg_thread_enter mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x1ad txg_sync_thread+0x1dc fork_exit+0x9a fork_trampoline+0xe 31071 100995 rm -mi_switch+0xe1 sleepq_wait+0x3a sleeplk+0x18d __lockmgr_args+0x9ab vop_stdlock+0x3c VOP_LOCK1_APV+0xab _vn_lock+0x43 zfs_lookup+0x45d zfs_freebsd_lookup+0x6d VOP_CACHEDLOOKUP_APV+0xa1 vfs_cache_lookup+0xd6 VOP_LOOKUP_APV+0xa1 lookup+0x5a1 namei+0x534 kern_rmdirat+0x8d amd64_syscall+0x3fb Xfast_syscall+0xfb 31075 100693 mv -mi_switch+0xe1 sleepq_wait+0x3a sleeplk+0x18d __lockmgr_args+0xd5d vop_stdlock+0x3c VOP_LOCK1_APV+0xab _vn_lock+0x4 The last line looks incomplete. hrm ... cut-n-paste fail I guess. procstat -kka | grep zfs 0 100666 kernel zfs_vn_rele_task mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x2ad taskqueue_thread_loop+0xf5 fork_exit+0x9a fork_trampoline+0xe 3 100151 zfskern arc_reclaim_thre mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x1ad arc_reclaim_thread+0x288 fork_exit+0x9a fork_trampoline+0xe 3 100152 zfskern l2arc_feed_threa mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x1ad l2arc_feed_thread+0x16f fork_exit+0x9a fork_trampoline+0xe 3 100657 zfskern trim zroot mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x1ad trim_thread+0x9e fork_exit+0x9a fork_trampoline+0xe 3 100675 zfskern txg_thread_enter mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x190 txg_quiesce_thread+0x39b fork_exit+0x9a fork_trampoline+0xe 3 100676 zfskern txg_thread_enter mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x1ad txg_sync_thread+0x1dc fork_exit+0x9a fork_trampoline+0xe 31071 100995 rm -mi_switch+0xe1 sleepq_wait+0x3a sleeplk+0x18d __lockmgr_args+0x9ab vop_stdlock+0x3c VOP_LOCK1_APV+0xab _vn_lock+0x43 zfs_lookup+0x45d zfs_freebsd_lookup+0x6d VOP_CACHEDLOOKUP_APV+0xa1 vfs_cache_lookup+0xd6 VOP_LOOKUP_APV+0xa1 lookup+0x5a1 namei+0x534 kern_rmdirat+0x8d amd64_syscall+0x3fb Xfast_syscall+0xfb 31075 100693 mv -mi_switch+0xe1 sleepq_wait+0x3a sleeplk+0x18d __lockmgr_args+0xd5d vop_stdlock+0x3c VOP_LOCK1_APV+0xab _vn_lock+0x43 vputx+0x28a zfs_rename_unlock+0x3e zfs_freebsd_rename+0xe39 VOP_RENAME_APV+0xab kern_renameat+0x4a6 amd64_syscall+0x3fb Xfast_syscall+0xfb signature.asc Description: This is a digitally signed message part
Re: Kernel Panic in frag6_slowtimeo
On Sun, 23 Nov 2014 12:45:24 +0300 Andrey V. Elsukov bu7c...@yandex.ru wrote: On 21.11.2014 09:10, Shawn Webb wrote: Looks like I?m getting a kernel panic on heavy work loads (poudriere run with 10 build slaves on an Intel Core i7 box). Below is a link to an imgur album of screenshots I took with my phone. Do you have VIMAGE option in your kernel? I do not. Here's my kernel config: https://github.com/HardenedBSD/hardenedBSD/blob/hardened/current/master/sys/amd64/conf/LATT-SEC Thanks, Shawn ___ 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
[RFC] Moving troff only documentation to the doc repository
Hi all,
I would like to move the troff documentation which is not very useful anymore on
a recent FreeBSD system but still part of history into the doc repository, a
dedicated branch will probably fit (anyone has an idea for the name of the
branch?)
FYI the troff only docs concern:
share/docs/{papers,psd,smm,usd}
Anyone has a concern about that?
Regards,
Bapt
pgpayodQlnge7.pgp
Description: PGP signature
Re: [RFC] Moving troff only documentation to the doc repository
On 23 Nov 2014, at 20:10, Baptiste Daroussin b...@freebsd.org wrote:
Hi all,
I would like to move the troff documentation which is not very useful anymore
on
a recent FreeBSD system but still part of history into the doc repository, a
dedicated branch will probably fit (anyone has an idea for the name of the
branch?)
FYI the troff only docs concern:
share/docs/{papers,psd,smm,usd}
Anyone has a concern about that?
Not from me, I actually have never read the documentation.
How about doc-history, or something where we can archive documentation that has
high historic value?
Cheers
Remko
Regards,
Bapt
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [RFC] Moving troff only documentation to the doc repository
In message ad7bf4d8-895f-420f-b42a-8ad1fae4a...@freebsd.org, Remko Lodder wri tes: How about doc-history, or something where we can archive documentation that has high historic value? It's about time the FreeBSD project starts to think about history preservation in general, but I'm not sure how one goes about doing that in an Open Source Project. Do we have any volunteers at Computer History Museum in our ranks ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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
Build failed in Jenkins: FreeBSD_HEAD #1900
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/1900/changes
Changes:
[joel] Misc mdoc fixes:
- Remove superfluous paragraph macros.
- Remove/fix empty or incorrect macros.
- Sort sections into conventional order.
- Terminate quoted strings properly.
- Remove EOL whitespace.
[ian] Consider the negation operator (!) to be a word even if it is not followed
by whitespace. This allows optional !foo which is what most programmers
are naturally going to tend to do as opposed to optional ! foo.
[glebius] \n at end of panicstr is redundant.
Submitted by: alc
[dim] Fix the following -Werror warning from clang 3.5.0, while building the
ath kernel module:
sys/dev/ath/ath_hal/ar5212/ar5212_reset.c:2642:7: error: taking the absolute
value of unsigned type 'unsigned int' has no effect [-Werror,-Wabsolute-value]
if (abs(lp[0] * EEP_SCALE - target) EEP_DELTA) {
^
sys/dev/ath/ah_osdep.h:74:18: note: expanded from macro 'abs'
#define abs(_a) __builtin_abs(_a)
^
sys/dev/ath/ath_hal/ar5212/ar5212_reset.c:2642:7: note: remove the call to
'__builtin_abs' since unsigned values cannot be negative
sys/dev/ath/ah_osdep.h:74:18: note: expanded from macro 'abs'
#define abs(_a) __builtin_abs(_a)
^
1 error generated.
This warning occurs because both lp[0] and target are unsigned, so the
subtraction expression is also unsigned, and calling abs() is a no-op.
However, the intention was to look at the absolute difference between
the two unsigned quantities. Introduce a small static function to
clarify what we're doing, and call that instead.
Reviewed by:adrian
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D1212
--
[...truncated 91672 lines...]
--- asn1_HDB_Ext_PKINIT_hash.o ---
cc -O2 -pipe
-Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/hdb
-Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/asn1
-Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/roken
-Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/sqlite
-Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/krb5
-I. -DHDB_DB_DIR=\/var/heimdal\ -DHAVE_CONFIG_H
-Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libhdb/../../include
-std=gnu99 -fstack-protector -Qunused-arguments -c
asn1_HDB_Ext_PKINIT_hash.c -o asn1_HDB_Ext_PKINIT_hash.o
--- asn1_HDB_Ext_PKINIT_hash.So ---
cc -fpic -DPIC -O2 -pipe
-Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/hdb
-Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/asn1
-Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/roken
-Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/sqlite
-Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/krb5
-I. -DHDB_DB_DIR=\/var/heimdal\ -DHAVE_CONFIG_H
-Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libhdb/../../include
-std=gnu99 -fstack-protector -Qunused-arguments -c
asn1_HDB_Ext_PKINIT_hash.c -o asn1_HDB_Ext_PKINIT_hash.So
--- asn1_HDB_Ext_Constrained_delegation_acl.o ---
cc -O2 -pipe
-Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/hdb
-Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/asn1
-Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/roken
-Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/sqlite
-Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/krb5
-I. -DHDB_DB_DIR=\/var/heimdal\ -DHAVE_CONFIG_H
-Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libhdb/../../include
-std=gnu99 -fstack-protector -Qunused-arguments -c
asn1_HDB_Ext_Constrained_delegation_acl.c -o
asn1_HDB_Ext_Constrained_delegation_acl.o
--- asn1_HDB_Ext_Constrained_delegation_acl.So ---
cc -fpic -DPIC -O2 -pipe
-Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/hdb
-Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/asn1
-Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/roken
Jenkins build is back to normal : FreeBSD_HEAD #1901
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/1901/changes ___ 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] Moving troff only documentation to the doc repository
On Sun, 23 Nov 2014, Remko Lodder wrote:
On 23 Nov 2014, at 20:10, Baptiste Daroussin b...@freebsd.org wrote:
Hi all,
I would like to move the troff documentation which is not very useful anymore on
a recent FreeBSD system but still part of history into the doc repository, a
dedicated branch will probably fit (anyone has an idea for the name of the
branch?)
FYI the troff only docs concern:
share/docs/{papers,psd,smm,usd}
Anyone has a concern about that?
Not from me, I actually have never read the documentation.
How about doc-history, or something where we can archive documentation that has
high historic value?
There is the doc archive: https://docs.freebsd.org/doc/
___
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: [HEADSUP] man(1) now uses mandoc
On Sun, Nov 23, 2014 at 6:07 AM, Warren Block wbl...@wonkity.com wrote: On Sun, 23 Nov 2014, Baptiste Daroussin wrote: The default renderer on HEAD has been switched to mandoc(1) by default The man(1) command has been instrumented to first test the manpage and fallback on groff if the man page cannot be rendered with mandoc(1). If base is built without groff then man(1) recommands to install groff from packages. makewhatis(1), apropos(1) have not yet been switched to mandoc(1) equivalent. Thanks and congratulations to all involved! I've been hoping to see this for at least a decade. Thanks so much for all of your work on this!. -- R. 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: [RFC] Moving troff only documentation to the doc repository
On Sun, 23 Nov 2014 20:10:57 +0100 Baptiste Daroussin b...@freebsd.org wrote
Hi all,
I would like to move the troff documentation which is not very useful anymore
on a recent FreeBSD system but still part of history into the doc repository,
a dedicated branch will probably fit (anyone has an idea for the name of the
branch?)
FYI the troff only docs concern:
share/docs/{papers,psd,smm,usd}
Anyone has a concern about that?
I had implemented a FreeBSD documentation generator largely in
Perl, intended to replace the current one. It required/awaited
this transition.
Huge thanks to all responsible for this transition!
Thanks, Baptiste, for the great news!
--Chris
Regards,
Bapt
___
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
