Re: ntpd does not re-query servers, when a new interface appears
On 09/03/2010 14:33, Jeremy Chadwick wrote: > On Tue, Mar 09, 2010 at 05:30:45AM -0800, Jeremy Chadwick wrote: >> On Tue, Mar 09, 2010 at 02:17:48PM +0100, Dominic Fandrey wrote: >>> On 09/03/2010 11:27, Ian Smith wrote: On Tue, 9 Mar 2010, Dominic Fandrey wrote: > ntpd tracks interface updates, however it does not requery > servers, when they occur. This was less than an hour ago, > at my university, the notebook boots and is not connected > to anything: > > 9 Mar 08:07:17 ntpd[1510]: logging to file /var/log/ntpd > 9 Mar 08:07:17 ntpd[1510]: precision = 2.234 usec > 9 Mar 08:07:17 ntpd[1510]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled > 9 Mar 08:07:17 ntpd[1510]: Listening on interface #1 wildcard, ::#123 Disabled > 9 Mar 08:07:17 ntpd[1510]: Listening on interface #2 bge0, 192.168.1.12#123 Enabled > 9 Mar 08:07:17 ntpd[1510]: Listening on interface #3 lo0, fe80::1#123 Enabled > 9 Mar 08:07:17 ntpd[1510]: Listening on interface #4 lo0, ::1#123 Enabled > 9 Mar 08:07:17 ntpd[1510]: Listening on interface #5 lo0, 127.0.0.1#123 Enabled > 9 Mar 08:07:17 ntpd[1510]: Listening on routing socket on fd #26 for interface updates > 9 Mar 08:07:17 ntpd[1510]: kernel time sync status 2040 > 9 Mar 08:07:17 ntpd[1510]: frequency initialized 3.155 PPM from /var/db/ntpd.drift > 9 Mar 08:07:20 ntpd[1542]: host name not found: 0.de.pool.ntp.org > 9 Mar 08:07:20 ntpd[1542]: couldn't resolve `0.de.pool.ntp.org', giving up on it > 9 Mar 08:07:20 ntpd[1542]: host name not found: 1.de.pool.ntp.org > 9 Mar 08:07:20 ntpd[1542]: couldn't resolve `1.de.pool.ntp.org', giving up on it > 9 Mar 08:07:20 ntpd[1542]: host name not found: 2.de.pool.ntp.org > 9 Mar 08:07:20 ntpd[1542]: couldn't resolve `2.de.pool.ntp.org', giving up on it > 9 Mar 08:07:20 ntpd[1542]: host name not found: ntp1.rz.uni-karlsruhe.de > 9 Mar 08:07:20 ntpd[1542]: couldn't resolve `ntp1.rz.uni-karlsruhe.de', giving up on it > 9 Mar 08:07:20 ntpd[1542]: host name not found: ntp1.rz.uni-karlsruhe.de > 9 Mar 08:07:20 ntpd[1542]: couldn't resolve `ntp1.rz.uni-karlsruhe.de', giving up on it > 9 Mar 08:07:20 ntpd[1542]: host name not found: ntp3.rz.uni-karlsruhe.de > 9 Mar 08:07:20 ntpd[1542]: couldn't resolve `ntp3.rz.uni-karlsruhe.de', giving up on it > 9 Mar 08:07:20 ntpd[1542]: host name not found: ntp4.rz.uni-karlsruhe.de > 9 Mar 08:07:20 ntpd[1542]: couldn't resolve `ntp4.rz.uni-karlsruhe.de', giving up on it > > So ntpd has given up on all the servers listed in the ntp.conf file. Yes, but it looks more like name service that's not operating, ntpd seems to be doing its best but can't resolve the hostnames? >>> >>> Why would I have named running on a notebook? This is a notebook, >>> which is not connected to the internet. >>> > I then proceed to connect to the wireless network and proceed to log > into two VPNs: > > 9 Mar 08:08:58 ntpd[1510]: Listening on interface #6 wlan0, 192.168.75.58#123 Enabled > 9 Mar 08:09:00 ntpd[1510]: Listening on interface #7 tun0, 193.196.120.15#123 Enabled > 9 Mar 08:09:04 ntpd[1510]: Listening on interface #8 tun1, 141.3.162.67#123 Enabled > > Over interface #8 some of the servers are actually available, but > ntpq -p still states: > No association ID's returned > > Only when I restart ntpd, it operates as expected: > remote refid st t when poll reach delay offset jitter > == > zit-net2.uni-pa .STEP. 16 u- 51200.0000.000 0.000 > alpha.rueckgr.a .STEP. 16 u- 51200.0000.000 0.000 > ntp.goneco.de .STEP. 16 u- 51200.0000.000 0.000 > +proxy4.rz.uni-k 129.13.64.17 2 u 30 128 2712.9372.530 1.891 > +proxy2.rz.uni-k 129.13.64.17 2 u 58 128 3753.593 -8.981 1.837 > *proxy1.rz.uni-k 129.13.64.17 2 u 15 128 2713.2978.244 1.487 I've always had to restart named after losing / regaining an interface, most noticeably after a suspend/resume (eg a low battery suspend), so I run /etc/rc.d/named restart from rc.resume. This looks like a similar issue perhaps, though I don't see why restarting only ntpd would fix it. >>> >>> As I said, named doesn't run at all. When the notebook gets an >>> internet connection, ntpd recognizes this. It somehow doesn't >>> occur to it, though, that it might be able to resolve the >>> servers, now. >> >> I
Re: Many processes stuck in zfs
On Mar 9, 2010, at 3:18 PM, Borja Marcos wrote: > > On Mar 9, 2010, at 1:58 PM, Pawel Jakub Dawidek wrote: > What kind of hardware do you have there? There is 3-way deadlock I've a fix for which would be hard to trigger on single or dual core machines. Feel free to try the fix: http://people.freebsd.org/~pjd/patches/zfs_3way_deadlock.patch >>> >>> Maybe related to the deadlock I reported when I was receiving an >>> incremental snapshot while the target dataset was being read? >> >> Could be. This deadlock is in general related to zfs recv functionality. > > Aye aye, Sir > > set fingers -position crossed > > testing :) Tested. Same deadlock remains. Borja. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: is dtrace usable?
Quoting "Robert N. M. Watson" (from Tue, 9 Mar
2010 16:39:09 +):
On Mar 9, 2010, at 2:16 PM, Alexander Leidinger wrote:
From this you can see that sys.mk is included and parsed before 'Makefile',
so the WITH_CTF=yes is not set until after sys.mk has been parsed.
I think we need to find a different solution for this. The need to
specify WITH_CTF at the command line is very error prone. :(
You are neither the first person to have made this observation, nor
the first person to have failed to propose a solution in the form of
a patch :-).
It is not a problem to provide a patch, the problem is something else.
Is it correct that the result of the ctfmerge/cftconvert stuff is not
covered by the CDDL?
If yes, why not use it by default if the programs are available (I've
read the comment for the NO_CTF part, but IMO we have a chicken&egg
situation here, dtrace will not become popular if it is not easy to
use it)? This default can be made only for the kernel (by making a
copy of the definition of CTFCONVERT into bsd.prog.mk and bsd.lib.mk,
or by undefining it there), or for kernel+userland (removing the
!WITH_CTF -> NO_CTF part from sys.mk).
Theoretically I have a patch for that, but somehow I stumple over
something strange which I don't understand. I have the following
(/usr/share/mk and /usr/src/share/mk are the same):
---snip---
--- bsd.lib.mk (revision 204031)
+++ bsd.lib.mk (working copy)
@@ -36,6 +36,18 @@
.if defined(DEBUG_FLAGS)
CFLAGS+= ${DEBUG_FLAGS}
+# Turn CTF conversion off by default for now. This default could be
+# changed later if DTrace becomes popular.
+NO_CTF= 1
+.if defined(WITH_CTF)
+.undef NO_CTF
+.endif
+
+.if defined(NO_CTF)
+.undef CTFCONVERT
+.undef CTFMERGE
+.endif
+
.if !defined(NO_CTF) && (${DEBUG_FLAGS:M-g} != "")
CTFFLAGS+= -g
.endif
[some more stuff to make the CTFCONVERT/CTFMERGE stuff working]
--- sys.mk (revision 204031)
+++ sys.mk (working copy)
@@ -46,12 +46,6 @@
.endif
PO_CFLAGS ?= ${CFLAGS}
-# Turn CTF conversion off by default for now. This default could be
-# changed later if DTrace becomes popular.
-.if !defined(WITH_CTF)
-NO_CTF = 1
-.endif
-
# C Type Format data is required for DTrace
CTFFLAGS ?= -L VERSION
[some more stuff to make the CTFCONVERT/CTFMERGE stuff working]
--- bsd.prog.mk (revision 204031)
+++ bsd.prog.mk (working copy)
@@ -19,6 +19,18 @@
CFLAGS+=${DEBUG_FLAGS}
CXXFLAGS+=${DEBUG_FLAGS}
+# Turn CTF conversion off by default for now. This default could be
+# changed later if DTrace becomes popular.
+NO_CTF= 1
+.if defined(WITH_CTF)
+.undef NO_CTF
+.endif
+
+.if defined(NO_CTF)
+.undef CTFCONVERT
+.undef CTFMERGE
+.endif
+
.if !defined(NO_CTF) && (${DEBUG_FLAGS:M-g} != "")
CTFFLAGS+= -g
.endif
[some more stuff to make the CTFCONVERT/CTFMERGE stuff working]
---snip---
When I go to /usr/src/bin/mv and run "make -V NO_CTF -V WITH_CTF" I
only get empty output. I would expect to see NO_CTF set to 1. And when
grepping for NO_CTF in /usr/share/mk I only see the undef of NO_CTF
which I added myself in the above patch.
Bye,
Alexander.
--
Life is just a bowl of cherries, but why do I always get the pits?
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Many processes stuck in zfs
On Wed, Mar 10, 2010 at 10:24:49AM +0100, Borja Marcos wrote: > Tested. Same deadlock remains. Ok, to track this down I need the following: Uncomment 'CFLAGS+=-DDEBUG=1' line in sys/modules/zfs/Makefile. Add the following lines to your kernel config: options WITNESS options WITNESS_SKIPSPIN options INVARIANTS options INVARIANT_SUPPORT options DEBUG_VFS_LOCKS options DEBUG_LOCKS options KDB options DDB Recompile your kernel and modules and reboot. Once the deadlock occur, enter DDB and send me the output of: ps show alllocks show lockedvnods show allchains alltrace Thanks. -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpsGx4nFhsJJ.pgp Description: PGP signature
Re: Many processes stuck in zfs
According to Stefan Bethke: > The situation seems to be triggered by zfs receive'ing snapshots from the > sister machine (both synchronize their active ZFS filesystems to each other, > using zfs send and zfs receive). It appears it's the receiving causing > trouble. Have you tuned kern.maxvnodes in /etc/sysctl.conf? When I move to this new machine, I forgot to get it much higher than the default (now I use 20) and it was locking up pretty soon. Had not a single lockup now. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Many processes stuck in zfs
Am 10.03.2010 um 12:35 schrieb Ollivier Robert: > According to Stefan Bethke: >> The situation seems to be triggered by zfs receive'ing snapshots from the >> sister machine (both synchronize their active ZFS filesystems to each other, >> using zfs send and zfs receive). It appears it's the receiving causing >> trouble. > > Have you tuned kern.maxvnodes in /etc/sysctl.conf? > > When I move to this new machine, I forgot to get it much higher than the > default (now I use 20) and it was locking up pretty soon. Had not a > single lockup now. I haven't, it's at the default of 10. How would I be able to tell if that limit is being reached? Right now: $ sysctl kern.maxvnodes vfs.numvnodes vfs.freevnodes kern.maxvnodes: 10 vfs.numvnodes: 87287 vfs.freevnodes: 24993 and on the sister host: $ sysctl kern.maxvnodes vfs.numvnodes vfs.freevnodes kern.maxvnodes: 10 vfs.numvnodes: 87681 vfs.freevnodes: 7600 Is there a rule of thumb what maxvnodes should be tuned to? Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Supplementary groups on LDAP cannot work with RELENG_8 +nss_ldap
On Wed, Mar 10, 2010 at 02:58:04PM +0800, Linghua Tseng wrote: > Thanks. > > I have tried to modify my /etc/nsswitch.conf to: > > group: compat > group_compat: ldap > hosts: files dns > networks: files > passwd: compat > passwd_compat: ldap > shells: files > services: compat > services_compat: nis > protocols: files > rpc: files Have you tried with group: files ldap group_compat: nis passwd: files ldap passwd_compat: nis > >> group: compat > >> -group_compat: nis > >> +group_compat: ldap nis > >> hosts: files dns > >> networks: files > >> passwd: compat > >> -passwd_compat: nis > >> +passwd_compat: ldap nis > >> shells: files > >> services: compat > >> services_compat: nis > >> > >> The line `+:*' has already put into /etc/master.passwd, > >> and the line `+:*::' has already put into /etc/group. I don't use the "+:*::" lines into master.passwd nor into group. -- Ricardo Campos Passanezi - Network Analyst PGP & GPG public key at: http://www.ige.unicamp.br/~riccp Institute of Geosciences - http://www.ige.unicamp.br - UNICAMP ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Supplementary groups on LDAP cannot work with RELENG_8 +nss_ldap
Have you tried with group: files ldap group_compat: nis passwd: files ldap passwd_compat: nis Yes, this setting works properly. Does it mean that I cannot put `ldap' into passwd_compat & group_compat? Sometimes I need the support of +/- in my passwd & group database. Was this feature gone since RELENG_8? I don't use the "+:*::" lines into master.passwd nor into group. Of course, these lines are required only if you put `ldap' into passwd_compat & group_compat. To put `ldap' into group & passwd doesn't need them. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Many processes stuck in zfs
On Mar 10, 2010, at 12:02 PM, Pawel Jakub Dawidek wrote: > On Wed, Mar 10, 2010 at 10:24:49AM +0100, Borja Marcos wrote: >> Tested. Same deadlock remains. > > Ok, to track this down I need the following: > > Uncomment 'CFLAGS+=-DDEBUG=1' line in sys/modules/zfs/Makefile. > > Add the following lines to your kernel config: > > options WITNESS > options WITNESS_SKIPSPIN > options INVARIANTS > options INVARIANT_SUPPORT > options DEBUG_VFS_LOCKS > options DEBUG_LOCKS > options KDB > options DDB > > Recompile your kernel and modules and reboot. > > Once the deadlock occur, enter DDB and send me the output of: > > ps > show alllocks > show lockedvnods > show allchains > alltrace Trying. I started my typical test: Machine 1 doing a make buildworld on a dataset with src and obj on it. Machine 1 replicating incremental snapshots of the dataset to machine 2. Machine 2 running some "tar cf - . | ( cd /pool/anotherdataset && tar xf - )" from the dataset being replicated, ie, doing read operations on the target dataset. This time, with all those debug options, there was no deadlock, but almost an instant trap entering DDB. Unfortunately, I tried to capture the output of "alltrace", etc using the capture option. But couldn't come back to the system to read it. Any ideas? I'm using VMWare Fusion to run FreeBSD for these tests and seems I'm out of luck, I don't see any console output mechanism. When rebooting I was greeted by some LORs lock order reversal: 1st 0xff000286c2e8 db->db_mtx (db->db_mtx) @ /pool/newsrc/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:549 2nd 0xff000286b0d8 dn->dn_mtx (dn->dn_mtx) @ /pool/newsrc/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c:1173 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _sx_xlock() at _sx_xlock+0x55 dnode_block_freed() at dnode_block_freed+0x8e dbuf_read() at dbuf_read+0x155 dmu_buf_hold_array_by_dnode() at dmu_buf_hold_array_by_dnode+0x12a dmu_read() at dmu_read+0x80 load_nvlist() at load_nvlist+0x85 spa_load() at spa_load+0x49a spa_open_common() at spa_open_common+0x12d spa_get_stats() at spa_get_stats+0x42 zfs_ioc_pool_stats() at zfs_ioc_pool_stats+0x2c zfsdev_ioctl() at zfsdev_ioctl+0x8d devfs_ioctl_f() at devfs_ioctl_f+0x76 kern_ioctl() at kern_ioctl+0xc5 ioctl() at ioctl+0xfd syscall() at syscall+0x118 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800fe7d1c, rsp = 0x7fffd808, rbp = 0x801224140 --- lock order reversal: 1st 0xff0002864e70 db->db_mtx (db->db_mtx) @ /pool/newsrc/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c:381 2nd 0xff00026e5140 osi->os_lock (osi->os_lock) @ /pool/newsrc/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c:323 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _sx_xlock() at _sx_xlock+0x55 dnode_destroy() at dnode_destroy+0xa6 dnode_buf_pageout() at dnode_buf_pageout+0xb2 dbuf_evict_user() at dbuf_evict_user+0x55 dbuf_clear() at dbuf_clear+0x5e dnode_evict_dbufs() at dnode_evict_dbufs+0x98 dmu_objset_evict_dbufs() at dmu_objset_evict_dbufs+0x11c dmu_objset_evict() at dmu_objset_evict+0xbf dsl_pool_close() at dsl_pool_close+0x52 spa_unload() at spa_unload+0xb2 spa_load() at spa_load+0x4da spa_open_common() at spa_open_common+0x12d spa_get_stats() at spa_get_stats+0x42 zfs_ioc_pool_stats() at zfs_ioc_pool_stats+0x2c zfsdev_ioctl() at zfsdev_ioctl+0x8d devfs_ioctl_f() at devfs_ioctl_f+0x76 kern_ioctl() at kern_ioctl+0xc5 ioctl() at ioctl+0xfd syscall() at syscall+0x118 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800fe7d1c, rsp = 0x7fffd808, rbp = 0x801224140 --- lock order reversal: 1st 0xff000286c058 db->db_mtx (db->db_mtx) @ /pool/newsrc/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1116 2nd 0xff0002591a38 dr->dt.di.dr_mtx (dr->dt.di.dr_mtx) @ /pool/newsrc/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1120 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _sx_xlock() at _sx_xlock+0x55 dbuf_dirty() at dbuf_dirty+0x892 dnode_setdirty() at dnode_setdirty+0x1a9 dbuf_dirty() at dbuf_dirty+0xa53 bplist_vacate() at bplist_vacate+0x4d spa_sync() at spa_sync+0x297 txg_sync_thread() at txg_sync_thread+0x2d7 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8012417d30
Re: Many processes stuck in zfs
According to Stefan Bethke: > $ sysctl kern.maxvnodes vfs.numvnodes vfs.freevnodes > kern.maxvnodes: 10 > vfs.numvnodes: 87681 > vfs.freevnodes: 7600 > > Is there a rule of thumb what maxvnodes should be tuned to? Not sure, I max'ed it to 20 and the machine has not locked up since. Try that, 30 if not and so on. The thing is, receiving snapshots is going to generate a lot of inodes/directories so vnodes shortage may be your problem. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Many processes stuck in zfs
On Wed, Mar 10, 2010 at 01:32:02PM +0100, Borja Marcos wrote: > Trying. I started my typical test: > > Machine 1 doing a make buildworld on a dataset with src and obj on it. > > Machine 1 replicating incremental snapshots of the dataset to machine 2. > > Machine 2 running some "tar cf - . | ( cd /pool/anotherdataset && tar xf - )" > from the dataset being replicated, ie, doing read operations on the target > dataset. > > This time, with all those debug options, there was no deadlock, but almost an > instant trap entering DDB. Unfortunately, I tried to capture the output of > "alltrace", etc using the capture option. But couldn't come back to the > system to read it. > > Any ideas? I'm using VMWare Fusion to run FreeBSD for these tests and seems > I'm out of luck, I don't see any console output mechanism. You should be able to use text dumps to capture output of those commands on panic. -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpDWmgFdBBAn.pgp Description: PGP signature
Re: is dtrace usable?
On Wednesday 10 March 2010 5:34:22 am Alexander Leidinger wrote: > Quoting "Robert N. M. Watson" (from Tue, 9 Mar > 2010 16:39:09 +): > > > > > On Mar 9, 2010, at 2:16 PM, Alexander Leidinger wrote: > > > >>> From this you can see that sys.mk is included and parsed before 'Makefile', > >>> so the WITH_CTF=yes is not set until after sys.mk has been parsed. > >> > >> I think we need to find a different solution for this. The need to > >> specify WITH_CTF at the command line is very error prone. :( > > > > You are neither the first person to have made this observation, nor > > the first person to have failed to propose a solution in the form of > > a patch :-). > > It is not a problem to provide a patch, the problem is something else. > > Is it correct that the result of the ctfmerge/cftconvert stuff is not > covered by the CDDL? > > If yes, why not use it by default if the programs are available (I've > read the comment for the NO_CTF part, but IMO we have a chicken&egg > situation here, dtrace will not become popular if it is not easy to > use it)? This default can be made only for the kernel (by making a > copy of the definition of CTFCONVERT into bsd.prog.mk and bsd.lib.mk, > or by undefining it there), or for kernel+userland (removing the > !WITH_CTF -> NO_CTF part from sys.mk). Unfortunately the ctf stuff breaks static binaries. I think that if that were fixed we would simply enable it by default and be done. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[releng_8 tinderbox] failure on arm/arm
TB --- 2010-03-10 14:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-10 14:00:00 - starting RELENG_8 tinderbox run for arm/arm TB --- 2010-03-10 14:00:00 - cleaning the object tree TB --- 2010-03-10 14:00:08 - cvsupping the source tree TB --- 2010-03-10 14:00:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/arm/arm/supfile TB --- 2010-03-10 14:00:26 - building world TB --- 2010-03-10 14:00:26 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-10 14:00:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-10 14:00:26 - TARGET=arm TB --- 2010-03-10 14:00:26 - TARGET_ARCH=arm TB --- 2010-03-10 14:00:26 - TZ=UTC TB --- 2010-03-10 14:00:26 - __MAKE_CONF=/dev/null TB --- 2010-03-10 14:00:26 - cd /src TB --- 2010-03-10 14:00:26 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 10 14:00:26 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/lib/libc/sys/sched_setparam.2 > sched_setparam.2.gz gzip -cn /src/lib/libc/sys/sched_setscheduler.2 > sched_setscheduler.2.gz gzip -cn /src/lib/libc/sys/sched_yield.2 > sched_yield.2.gz gzip -cn /src/lib/libc/sys/sctp_generic_recvmsg.2 > sctp_generic_recvmsg.2.gz gzip -cn /src/lib/libc/sys/sctp_generic_sendmsg.2 > sctp_generic_sendmsg.2.gz gzip -cn /src/lib/libc/sys/sctp_peeloff.2 > sctp_peeloff.2.gz gzip -cn /src/lib/libc/sys/select.2 > select.2.gz /libexec/ld-elf.so.1: Cannot open "/lib/libncurses.so.8" *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-10 14:28:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-10 14:28:18 - ERROR: failed to build world TB --- 2010-03-10 14:28:18 - 1165.76 user 320.11 system 1697.95 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-arm-arm.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[releng_8 tinderbox] failure on i386/pc98
TB --- 2010-03-10 14:28:19 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-10 14:28:19 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2010-03-10 14:28:19 - cleaning the object tree TB --- 2010-03-10 14:28:38 - cvsupping the source tree TB --- 2010-03-10 14:28:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/pc98/supfile TB --- 2010-03-10 14:29:22 - building world TB --- 2010-03-10 14:29:22 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-10 14:29:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-10 14:29:22 - TARGET=pc98 TB --- 2010-03-10 14:29:22 - TARGET_ARCH=i386 TB --- 2010-03-10 14:29:22 - TZ=UTC TB --- 2010-03-10 14:29:22 - __MAKE_CONF=/dev/null TB --- 2010-03-10 14:29:22 - cd /src TB --- 2010-03-10 14:29:22 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 10 14:29:23 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] ===> usr.bin/rpcgen (cleandir) rm -f rpcgen rpc_main.o rpc_clntout.o rpc_cout.o rpc_hout.o rpc_parse.o rpc_sample.o rpc_scan.o rpc_svcout.o rpc_tblout.o rpc_util.o rpcgen.1.gz rpcgen.1.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> usr.bin/rpcinfo (cleandir) rm -f rpcinfo rpcinfo.o rpcinfo.8.gz rpcinfo.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> usr.bin/rs (cleandir) /usr/bin/make: Permission denied *** Error code 126 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-10 14:30:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-10 14:30:21 - ERROR: failed to build world TB --- 2010-03-10 14:30:21 - 32.54 user 21.50 system 122.76 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[releng_8 tinderbox] failure on i386/i386
TB --- 2010-03-10 14:25:03 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-10 14:25:03 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2010-03-10 14:25:03 - cleaning the object tree TB --- 2010-03-10 14:25:28 - cvsupping the source tree TB --- 2010-03-10 14:25:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/i386/supfile TB --- 2010-03-10 14:25:42 - building world TB --- 2010-03-10 14:25:42 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-10 14:25:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-10 14:25:42 - TARGET=i386 TB --- 2010-03-10 14:25:42 - TARGET_ARCH=i386 TB --- 2010-03-10 14:25:42 - TZ=UTC TB --- 2010-03-10 14:25:42 - __MAKE_CONF=/dev/null TB --- 2010-03-10 14:25:42 - cd /src TB --- 2010-03-10 14:25:42 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 10 14:25:43 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies [...] ===> gnu/usr.bin/cc (depend) ===> gnu/usr.bin/cc/cc_tools (depend) cc -O2 -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/obj/i386/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -std=gnu89 -fstack-protector -c /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gengtype.c cc -O2 -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/obj/i386/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -std=gnu89 -fstack-protector -c gengtype-yacc+%DIKED.c cc -O2 -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/obj/i386/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -std=gnu89 -fstack-protector -c gengtype-lex.c cc -O2 -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/obj/i386/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -std=gnu89 -fstack-protector -c /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/errors.c cc -O2 -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/obj/i386/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -std=gnu89 -fstack-protector -o gengtype gengtype.o gengtype-yacc+%DIKED.o gengtype-lex.o errors.o libiberty.a libiberty.a: could not read symbols: File format not recognized *** Error code 1 Stop in /src/gnu/usr.bin/cc/cc_tools. *** Error code 1 Stop in /src/gnu/usr.bin/cc. *** Error code 1 Stop in /src/gnu/usr.bin. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-10 14:55:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-10 14:55:03 - ERROR: failed to build world TB --- 2010-03-10 14:55:03 - 1296.30 user 276.52 system 1799.38 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full __
Re: is dtrace usable?
Quoting John Baldwin (from Wed, 10 Mar 2010 08:12:29 -0500): On Wednesday 10 March 2010 5:34:22 am Alexander Leidinger wrote: Quoting "Robert N. M. Watson" (from Tue, 9 Mar 2010 16:39:09 +): > > On Mar 9, 2010, at 2:16 PM, Alexander Leidinger wrote: > >>> From this you can see that sys.mk is included and parsed before 'Makefile', >>> so the WITH_CTF=yes is not set until after sys.mk has been parsed. >> >> I think we need to find a different solution for this. The need to >> specify WITH_CTF at the command line is very error prone. :( > > You are neither the first person to have made this observation, nor > the first person to have failed to propose a solution in the form of > a patch :-). It is not a problem to provide a patch, the problem is something else. Is it correct that the result of the ctfmerge/cftconvert stuff is not covered by the CDDL? If yes, why not use it by default if the programs are available (I've read the comment for the NO_CTF part, but IMO we have a chicken&egg situation here, dtrace will not become popular if it is not easy to use it)? This default can be made only for the kernel (by making a copy of the definition of CTFCONVERT into bsd.prog.mk and bsd.lib.mk, or by undefining it there), or for kernel+userland (removing the !WITH_CTF -> NO_CTF part from sys.mk). Unfortunately the ctf stuff breaks static binaries. I think that if that were fixed we would simply enable it by default and be done. So it should work by enabling it by default for the kernel, and not for the userland (as we do not have a working PID provider, this shouldn't be a big problem anyway). And this is something which my patch is supposed to do, but doesn't because of the strange behavior described in the previous mail. Any ideas? Bye, Alexander. -- ... [concerning quotation marks] even if we *_d_i_d* quote anybody in this business, it probably would be gibberish. -- Thom McLeod http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: freebsd 8.0 stable amd64/x86 needs ~9min to bootup
This problem happened with me too. I don't know why boot loader makes
intensive reads when installed on partition created by another fdisk
(windows, linux, etc) and started by GRUB2.
There is a workaround for this, you have to create all partitions with
freebsd sysinstall included windows and linux partitions. After this do
install for all others OSes using those partitions created by sysinstall.
In my case there are 03 OSes installed on same HD:
1: Windows boot loader: 1023MB
2: Windows 7: 50GB
3: PCBSD 8.0: 70GB
* -> 5: Linux 108GB
6: Linux swap
This problem can be tested before install if you run sysinstall and
choses partiotion menu if you receive alerts like this: "Partition X
does not end on cylinder boundary" you will have problem with GRUB2.
I'm using GRUB2 from Ubuntu 9.10 with this entry in file
/etc/grub.d/40_custom:
menuentry "FreeBSD/PCBSD 8.0 AMD64" {
set root=(hd0,3)
chainloader +1
}
All works fine!
Paulo.
Em 05/02/2010 08:29, Zavam escreveu:
2010/1/28 Zavam, Vinícius :
2010/1/28 Bruce Simpson :
Try GRUB4DOS. I use this so on boxes where I have Windows installed, I can
keep GRUB in the NTFS partition.
I haven't seen this issue and am tracking -STABLE on an ASUS V-series
machine.
Simpson,
I forgot to mention... but I tested it using boot0 (freebsd's
bootmanager) with no success ;<
had no shots with grub4dos, gag, lilo or grub2; I assume it may not be
a bootmanager issue, but freebsd's btx bootstrap loader.
my gentoo and windows o.s. can be loaded using grub or boot0.
--
Zavam, Vinícius
gentlemen,
morning.
I just did new fresh installs using 80-STABLE/amd64 and
90-CURRENT/amd64 snapshots.
unfortunately, no success.
when tryied the 90-CURRENT I've created a slice to /boot (d) at the
beginning of the partition (ad4s4) and grub returned error code 18
[1].
strange. even installing in another slice, at the beginning of the
disk (ad4s1), the bootup process was slow too.
[1] http://wiki.linuxquestions.org/wiki/GRUB#Error_18
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ZFS question
I wasn't sure what the most appropriate mailing list to address this problem would be, so I'll go ahead and ask it here. This is probably most directed toward PJD, as he did directed the porting effort of zfs to freebsd. There are many read only sysctl handles to L2ARC and L1ARC caches, as well as performance stats. Some of these are self explanatory based on their naming conventions, however some are more vague than others. Could I perhaps get a detailed explanation of what those sysctls related to zfs actually are describing? I'm hoping to build a decent web interface with RRDTool that has accurate and useful information in regards to ZFS performance monitoring. Storage analytics are becoming an increasingly popular trend and are EMC's advantage over something like FreeNAS. My efforts are to make a nanoBSD based distro for NAS systems, but aim at different goals than FreeNAS (for example, including built in HAST support). I'm not sure if I'm going to use m0n0wall's framework or start from scratch, still evaluating which endeavor will be best to maintain and fit the job. Anyway, any explanation would be appreciated, even if you're not the great PJD :-p. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Many processes stuck in zfs
On Wed, Mar 10, 2010 at 04:12:36PM +0100, Borja Marcos wrote: > > On Mar 10, 2010, at 12:02 PM, Pawel Jakub Dawidek wrote: > > > Once the deadlock occur, enter DDB and send me the output of: > > > > ps > > show alllocks > > show lockedvnods > > show allchains > > alltrace > > (Again, crossposted to -fs, ZFS related) > > > Previous one was a panic when performing the test with several tar jobs > running in parallel. > > Now this is a capture of the deadlock itself, instead of a panic. (I called > panic from the debugger to generate a dump) [...] Hmm, interesting. Especially those two traces: Tracing command zfs pid 1820 tid 100105 td 0xff0002ca4000 [...] _cv_wait() at _cv_wait+0x17a txg_wait_synced() at txg_wait_synced+0x98 zfsvfs_teardown() at zfsvfs_teardown+0x1f6 zfs_suspend_fs() at zfs_suspend_fs+0x2b zfs_ioc_recv() at zfs_ioc_recv+0x28b zfsdev_ioctl() at zfsdev_ioctl+0x8d devfs_ioctl_f() at devfs_ioctl_f+0x76 kern_ioctl() at kern_ioctl+0xc5 ioctl() at ioctl+0xfd [...] Tracing command bsdtar pid 1699 tid 100093 td 0xff000262dae0 [...] _sx_slock_hard() at _sx_slock_hard+0x1b7 _sx_slock() at _sx_slock+0xc1 zfs_freebsd_reclaim() at zfs_freebsd_reclaim+0x63 VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xb5 vgonel() at vgonel+0x119 vnlru_free() at vnlru_free+0x345 getnewvnode() at getnewvnode+0x24f zfs_znode_cache_constructor() at zfs_znode_cache_constructor+0x43 zfs_znode_alloc() at zfs_znode_alloc+0x38 zfs_mknode() at zfs_mknode+0x259 zfs_freebsd_create() at zfs_freebsd_create+0x661 VOP_CREATE_APV() at VOP_CREATE_APV+0xb3 vn_open_cred() at vn_open_cred+0x473 kern_openat() at kern_openat+0x179 [...] This should be impossible. If we are that deep in zfsvfs_teardown(), it means that we hold the z_teardown_lock exclusively. And we do as 'show alllocks' output confirms. But if we are holding this lock exclusively we shouldn't be that deep in create code path, because we need hold this lock as reader. It isn't visible in 'show alllocks' output, because this lock is special (rrwlock.c). I see three possibilities: 1. We are looking at different file systems here. But where is deadlock coming from then? 2. There is a bug in rrwlock.c. Highly unlikely I think. 3. My thinking is incorrect somewhere. Let me do some more thinking and I'll get back to you (possibly with a patch that will help us to find right possibility). -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpy8LXOB6pAf.pgp Description: PGP signature
Re: Many processes stuck in zfs
on 10/03/2010 19:31 Pawel Jakub Dawidek said the following: > This should be impossible. If we are that deep in zfsvfs_teardown(), it means > that we hold the z_teardown_lock exclusively. And we do as 'show alllocks' > output confirms. But if we are holding this lock exclusively we shouldn't be > that deep in create code path, because we need hold this lock as reader. > It isn't visible in 'show alllocks' output, because this lock is special > (rrwlock.c). BTW, it seems that our 'stock' rwlock implements exactly the same thing as rrwlock.c - recursive readers, etc. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Many processes stuck in zfs
On Wed, Mar 10, 2010 at 07:42:43PM +0200, Andriy Gapon wrote: > on 10/03/2010 19:31 Pawel Jakub Dawidek said the following: > > This should be impossible. If we are that deep in zfsvfs_teardown(), it > > means > > that we hold the z_teardown_lock exclusively. And we do as 'show alllocks' > > output confirms. But if we are holding this lock exclusively we shouldn't be > > that deep in create code path, because we need hold this lock as reader. > > It isn't visible in 'show alllocks' output, because this lock is special > > (rrwlock.c). > > BTW, it seems that our 'stock' rwlock implements exactly the same thing as > rrwlock.c - recursive readers, etc. But you cannot sleep while holding our rwlock(9). -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpYxzVlJV5kS.pgp Description: PGP signature
Re: ZFS question
Hi, You may find some good information in arc_summary.pl script for FreebBSD by jhell: http://jhell.googlecode.com/files/arc_summary.pl I've also did some plugins for munin, where based on that, and looking on the code, I tried to provide some interpretation of L2ARC/ARC statistics (see attached scripts). I'm still not sure, if I have all the important stuff visible on the graphs. Cheers, Wiktor Niesiobedzki 2010/3/10 Adam Stylinski : > I wasn't sure what the most appropriate mailing list to address this problem > would be, so I'll go ahead and ask it here. This is probably most directed > toward PJD, as he did directed the porting effort of zfs to freebsd. There > are many read only sysctl handles to L2ARC and L1ARC caches, as well as > performance stats. Some of these are self explanatory based on their naming > conventions, however some are more vague than others. Could I perhaps get a > detailed explanation of what those sysctls related to zfs actually are > describing? I'm hoping to build a decent web interface with RRDTool that > has accurate and useful information in regards to ZFS performance > monitoring. Storage analytics are becoming an increasingly popular trend > and are EMC's advantage over something like FreeNAS. My efforts are to make > a nanoBSD based distro for NAS systems, but aim at different goals than > FreeNAS (for example, including built in HAST support). I'm not sure if I'm > going to use m0n0wall's framework or start from scratch, still evaluating > which endeavor will be best to maintain and fit the job. Anyway, any > explanation would be appreciated, even if you're not the great PJD :-p. > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD 7.2-RELEASE EoL delayed to end of June 2010
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Everyone, In keeping with the FreeBSD Security Team policy concerning the EoL dates for "Normal" support releases, "a minimum of 12 months after the release, and for sufficient additional time (if needed) to ensure that there is a newer release for at least 3 months before the older Normal release expires" the EoL date for FreeBSD 7.2-RELEASE has been adjusted from the end of May 2010 to the end of June 2010. Due to an unfortunate limitation in the freebsd-update(8) utility, it will warn about the upcoming EoL based on the original end-of-May date until the next time a security update is pushed out for 7.2-RELEASE. Please note that this is only a one month reprieve; we expect 7.3-RELEASE to be announced later this month, and users of 7.2-RELEASE are advised to utilize the months of April, May, and June to ensure that their systems are upgraded before 7.2-RELEASE ceases to be supported. Once they are released, 7.3-RELEASE and 8.1-RELEASE will both receive "Extended" (i.e., 24 month) support from the FreeBSD Security Team. - -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuYBpwACgkQFdaIBMps37KQnwCdGOnAcchaMeN0B/Ayo3MHqNPM zq4AnRyDMMmayIDr27RmL+KF+n/0Kzae =drwk -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS question
Am 10.03.2010 um 19:51 schrieb Wiktor Niesiobedzki: > I've also did some plugins for munin, where based on that, and looking > on the code, I tried to provide some interpretation of L2ARC/ARC > statistics (see attached scripts). I'm still not sure, if I have all > the important stuff visible on the graphs. The FreeBSD lists strip attachments. Would you mind posting a download link, or are they listed in Munin Exchange? TIA, Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ntpd does not re-query servers, when a new interface appears
On Mar 10, 2010, at 03:25, Dominic Fandrey wrote: In the meantime, your comments made me realize, that I can circumvent this problem by adding the ntp pools to my /etc/hosts file. Up to a point: using DNS, the results round-robin--which helps the server operators--and dead servers are also removed from the pool automatically (AFAIK). You'll lose the latter with a static host table, which may affect things if things break upstream. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ntpd does not re-query servers, when a new interface appears
On 10/03/2010 23:19, David Magda wrote: > On Mar 10, 2010, at 03:25, Dominic Fandrey wrote: > >> In the meantime, your comments made me realize, that I can circumvent >> this problem by adding the ntp pools to my /etc/hosts file. > > Up to a point: using DNS, the results round-robin--which helps the > server operators--and dead servers are also removed from the pool > automatically (AFAIK). > > You'll lose the latter with a static host table, which may affect things > if things break upstream. I checked that. I just added the IPs of the pools. As soon as I get online, the pools still serve me different IPs every time. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Many processes stuck in zfs
Quoting Pawel Jakub Dawidek (from Wed, 10 Mar 2010 18:31:43 +0100): On Wed, Mar 10, 2010 at 04:12:36PM +0100, Borja Marcos wrote: On Mar 10, 2010, at 12:02 PM, Pawel Jakub Dawidek wrote: > Once the deadlock occur, enter DDB and send me the output of: > >ps >show alllocks >show lockedvnods >show allchains >alltrace (Again, crossposted to -fs, ZFS related) Previous one was a panic when performing the test with several tar jobs running in parallel. Now this is a capture of the deadlock itself, instead of a panic. (I called panic from the debugger to generate a dump) [...] Hmm, interesting. Especially those two traces: Tracing command zfs pid 1820 tid 100105 td 0xff0002ca4000 [...] _cv_wait() at _cv_wait+0x17a txg_wait_synced() at txg_wait_synced+0x98 zfsvfs_teardown() at zfsvfs_teardown+0x1f6 zfs_suspend_fs() at zfs_suspend_fs+0x2b zfs_ioc_recv() at zfs_ioc_recv+0x28b zfsdev_ioctl() at zfsdev_ioctl+0x8d devfs_ioctl_f() at devfs_ioctl_f+0x76 kern_ioctl() at kern_ioctl+0xc5 ioctl() at ioctl+0xfd [...] Tracing command bsdtar pid 1699 tid 100093 td 0xff000262dae0 [...] _sx_slock_hard() at _sx_slock_hard+0x1b7 _sx_slock() at _sx_slock+0xc1 zfs_freebsd_reclaim() at zfs_freebsd_reclaim+0x63 VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xb5 vgonel() at vgonel+0x119 vnlru_free() at vnlru_free+0x345 getnewvnode() at getnewvnode+0x24f zfs_znode_cache_constructor() at zfs_znode_cache_constructor+0x43 zfs_znode_alloc() at zfs_znode_alloc+0x38 zfs_mknode() at zfs_mknode+0x259 zfs_freebsd_create() at zfs_freebsd_create+0x661 VOP_CREATE_APV() at VOP_CREATE_APV+0xb3 vn_open_cred() at vn_open_cred+0x473 kern_openat() at kern_openat+0x179 [...] This should be impossible. If we are that deep in zfsvfs_teardown(), it means that we hold the z_teardown_lock exclusively. And we do as 'show alllocks' output confirms. But if we are holding this lock exclusively we shouldn't be that deep in create code path, because we need hold this lock as reader. It isn't visible in 'show alllocks' output, because this lock is special (rrwlock.c). I see three possibilities: 1. We are looking at different file systems here. But where is deadlock coming from then? 2. There is a bug in rrwlock.c. Highly unlikely I think. 3. My thinking is incorrect somewhere. There is a 4th possibility, if you can rule out everything else: bugs in the CPU. I stumbled upon this with ZFS (but UFS was exposing the problem much faster). The problem in my case was that the BIOS was not recognizing the CPU and as such was not uploading microcode updates. Borja, can you confirm that the CPU is correctly announced in FreeBSD (just look at "dmesg | grep CPU:" output, if it tells you it is a AMD or Intel XXX CPU it is correctly detected by the BIOS)? Bye, Alexander. -- Kissing a fish is like smoking a bicycle. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
