Re: [RFC] rcexecr: rcorder in parallel
All functional parts are done (unless I forgot something..) patch for /etc is included (against CURRENT), and tested on my laptop. In my case, with rcexecr and the patch, the time for launching rc.d scripts reduces from 35s to 26s. manpage is updated, but I think my English needs some fix :p Regards, Buganini ___ 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: [HEADS UP] color and page width support in man(1)
On Sat, Jun 04, 2011 at 07:52:31AM -0400, Thomas Dickey wrote: > On Sat, Jun 04, 2011 at 05:54:49AM +0400, Andrey Chernov wrote: > > On Fri, Jun 03, 2011 at 02:48:59PM +, Ruslan Ermilov wrote: > > > On a freshly installed -CURRENT, to view a colorized manpage in color > > > and in full terminal width, try this: > > > > > > env MANCOLOR=yes MANWIDTH=tty man grotty > > > > > > > SGR presence can be easily autodetected analyzing termcap capibilities > > (for isatty() case). > > true - > but grotty doesn't pay any attention to the termcap or terminfo database. Our man is already a complex script, so can pass results of autodetection as an option to grotty. -- http://ache.vniz.net/ pgp5mbb6KryK6.pgp Description: PGP signature
Re: [poll / rfc] kdb_stop_cpus
2011/6/4 Andriy Gapon :
> on 03/06/2011 20:57 Robert N. M. Watson said the following:
>>
>> On 3 Jun 2011, at 16:13, Andriy Gapon wrote:
>>
>>> I wonder if anybody uses kdb_stop_cpus with non-default value. If, yes, I
>>> am very interested to learn about your usecase for it.
>>
>> The issue that prompted the sysctl was non-NMI IPIs being used to enter the
>> debugger or reboot following a core hanging with interrupts disabled. With
>> the switch to NMI IPIs in some of those circumstances, life is better -- at
>> least, on hardware that supports non-maskable IPIs. I seem to recall sparc64
>> doesn't, however?
>
> Seems to be so as Nathan has also pointed out for PPC.
> For this I also plan the following change:
>
> commit 458ebd9aca7e91fc6e0825c727c7220ab9f61016
>
> generic_stop_cpus: move timeout detection code from under DIAGNOSTIC
>
> ... and also increase it a bit.
> IMO it's better to detect and report the (rather serious) condition and
> allow a system to proceed somehow rather than be stuck in an endless
> loop.
>
> diff --git a/sys/kern/subr_smp.c b/sys/kern/subr_smp.c
> index ae52f4b..4bd766b 100644
> --- a/sys/kern/subr_smp.c
> +++ b/sys/kern/subr_smp.c
> @@ -232,12 +232,10 @@ generic_stop_cpus(cpumask_t map, u_int type)
> /* spin */
> cpu_spinwait();
> i++;
> -#ifdef DIAGNOSTIC
> - if (i == 10) {
> + if (i == 1) {
> printf("timeout stopping cpus\n");
> break;
> }
> -#endif
> }
>
> stopping_cpu = NOCPU;
I'd also add the ability, once the deadlock is detected, to break in
KDB, and put that under DIAGNOSTIC.
I had such a patch and I used it to debug some deadlocks on shutdown
code, but now it seems I can't find it anymore.
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
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: [poll / rfc] kdb_stop_cpus
2011/6/3 Nathan Whitehorn : > On 06/03/11 10:13, Andriy Gapon wrote: >> >> I wonder if anybody uses kdb_stop_cpus with non-default value. >> If, yes, I am very interested to learn about your usecase for it. >> >> I think that the default kdb behavior is the correct one, so it doesn't >> make sense >> to have a knob to turn on incorrect behavior. >> But I may be missing something obvious. >> >> The comment in the code doesn't really satisfy me: >> /* >> * Flag indicating whether or not to IPI the other CPUs to stop them on >> * entering the debugger. Sometimes, this will result in a deadlock as >> * stop_cpus() waits for the other cpus to stop, so we allow it to be >> * disabled. In order to maximize the chances of success, use a hard >> * stop for that. >> */ >> >> The hard stop should be sufficiently mighty. >> Yes, I am aware of supposedly extremely rare situations where a deadlock >> could >> happen even when using hard stop. But I'd rather fix that than have this >> switch. >> >> Oh, the commit message (from 2004) explains it: >>> >>> Add a new sysctl, debug.kdb.stop_cpus, which controls whether or not we >>> attempt to IPI other cpus when entering the debugger in order to stop >>> them while in the debugger. The default remains to issue the stop; >>> however, that can result in a hang if another cpu has interrupts disabled >>> and is spinning, since the IPI won't be received and the KDB will wait >>> indefinitely. We probably need to add a timeout, but this is a useful >>> stopgap in the mean time. >> >> But that was before we started using hard stop in this context (in 2009). > > Some non-x86 platforms (e.g. PPC) don't support real NMIs, and so this still > applies. Well, if I get Andriy's proposal right, he just wants to trim off the possibility to not stop the CPUs on entering KDB. I'm not entirely sure why there is a sysctl for disabling that and I really don't want it. Note that the missing of the NMI/privileged Interrupt is not going to be a factor on this request, unless you are worried a lot by the easy deadlock that a normal stop operation may lead. If that is the case, I think that the upcoming work on skipping locking during KDB/panic entering is going to help a lot for this case. At that point removing the possibility to turn off CPU stopping will be a good idea, IMHO. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: Weird issue with hastd(8)
Mikolaj, Upon further investigation it appears that there is a logic mistake in hastd's server/client buffering code. I've just applied a fix and it immediately solved the issue for me. Please see r222688 for details. I plan to MFC it ASAP, as otherwise hastd is not functional when compression is enabled. -Maxim ___ 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"
Divert socket problem (was: Re: svn commit: r222488 - in head/sys: contrib/pf/net netinet netinet/ipfw netinet6)
On 4 Jun 2011, at 15:30, Kristof Provost wrote: > div_bind probably also needs to surround the call to in_pcbbind with > INP_HASHW(UN)LOCK(...) > > I'm currently running 222680. I've only now seen the issue, but I've also > just now activated INVARIANTS. Hi Kristof: Thanks for the detailed report, and yes, it looks like that is exactly what is required. Could you try the attached patch? Robert 20110604-divert-fix.diff Description: Binary data ___ 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: mount root from zfs fails under current with "error 6"
On Fri, 3 Jun 2011, Gavin Atkinson wrote: ... maybe I found something: After setting vfs.zfs.debug=1 I got two new verbose bootlogs: http://people.freebsd.org/~mr/boot_fail2.txt http://people.freebsd.org/~mr/boot_success2.txt As you can see, in the failing case ZFS tries to attach to ada[0123] whereas in the succeeding case ZFS attaches to ada[0123]p3 (which are the correct devices) Can you try setting kern.geom.part.check_integrity=0 ? Preparing a new r222654 kernel and booting with kern.geom.part.check_integrity=0 didn't cure anything. See http://people.freebsd.org/~mr/boot_3.txt for a "boot -v" using set kern.geom.label.debug=1 additionaly But reverting /sys/geom to r221381 allows to boot. See http://people.freebsd.org/~mr/boot_4.txt for a "boot -s" using set vfs.zfs.debug=1 set kern.geom.debugflags=4 set kern.geom.label.debug=1 additionaly. So the problem seems to be related to the recent geom changes... Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.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: 8-STABLE /usr/include/utmp.h and tmpx
Aryeh Friedman writes: > Some time in the last 2 weeks (I am sure when) a commit caused many > ports that assume a "standard" utmp/utmp.x to break for example > x11-toolkits/vte produces: I guess it's a user error, utmpx.h and utmp.h shouldn't both be present. See similar issue http://lists.freebsd.org/pipermail/freebsd-ports/2010-September/063733.html > gnome-pty-helper.c:497: warning: passing argument 4 of 'pty_add' > discards qualifiers from pointer target type > mv -f .deps/gnome-pty-helper.Tpo .deps/gnome-pty-helper.Po > cc -DHAVE_CONFIG_H -I. -I/usr/local/include -O2 -pipe > -march=prescott -fno-strict-aliasing -MT gnome-utmp.o -MD -MP -MF > .deps/gnome-utmp.Tpo -c -o gnome-utmp.o gnome-utmp.c > gnome-utmp.c: In function 'write_login_record': > gnome-utmp.c:367: warning: passing argument 1 of 'login' from > incompatible pointer type > gnome-utmp.c:374: error: 'struct utmpx' has no member named 'ut_name' If you're on /stable/8 try removing leftover includes from /head by reinstalling /usr/include, e.g. $ mv /usr/include /usr/include.old $ make distrib-dirs installincludes -C/usr/src # a list of files that shouldn't be there $ mtree -klink -cinp /usr/include.old >old.mtree $ mtree -klink -cinp /usr/include >new.mtree $ diff -u old.mtree new.mtree struct utmpx shouldn't be used on /stable/8 as there is no utmpx.h. # from vte-0.26.2/gnome-pty-helper/acinclude.m4 AC_CHECK_HEADERS(sys/time.h utmp.h utmpx.h) if test "$ac_cv_header_utmpx_h" = "yes"; then AC_DEFINE(UTMP,[struct utmpx],[Define to the name of a structure which holds utmp data.]) else AC_DEFINE(UTMP,[struct utmp],[Define to the name of a structure which holds utmp data.]) fi And if you're on /head then stale utmp.h should be removed, e.g. $ make delete-old -C/usr/src making the port use ut_user instead of ut_name. > This is not the only port that has the issue but it is the only one I > remember off the top of my head (I manually fixed a few others) ___ 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] rcexecr: rcorder in parallel
On Sat, Jun 04, 2011 at 12:45:37PM +0100, Julien Laffaye wrote: > On Sat, Jun 4, 2011 at 10:10 AM, Buganini wrote: > > https://github.com/buganini/rcexecr > > Currently it is able to determine the exec/wait order > > There are something I haven't digged in deeply in the "self > > modification" part. > > patches/ideas are welcome. > Thanks for doing that! Yes. > You should use kqueue(2) instead of waitpid(2) so that you can > efficiently monitor a pool of processes. > See pwait(1) for an example. Hmm, I don't think kqueue() should be used here. Its main advantage is that it works regardless of parent-child relationships, but that advantage is not relevant here. On the other hand, waitpid() is still necessary to get rid of the zombies. Furthermore, waitpid() is standard while kqueue() is not, and I think non-standard interfaces should only be used if they provide a real benefit above standard interfaces. The current approach with waitpid() for specific processes should be good enough for a proof of concept. It will keep zombies longer than necessary, particularly for things that are not explicitly depended on. To avoid this, use waitpid(-1, ...) and maintain more tracking for processes that have already terminated. -- Jilles Tjoelker ___ 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: [HEADS UP] color and page width support in man(1)
On Sat, Jun 04, 2011 at 05:54:49AM +0400, Andrey Chernov wrote: > On Fri, Jun 03, 2011 at 02:48:59PM +, Ruslan Ermilov wrote: > > On a freshly installed -CURRENT, to view a colorized manpage in color > > and in full terminal width, try this: > > > > env MANCOLOR=yes MANWIDTH=tty man grotty > > > > SGR presence can be easily autodetected analyzing termcap capibilities > (for isatty() case). true - but grotty doesn't pay any attention to the termcap or terminfo database. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpQYelqoKH0N.pgp Description: PGP signature
Re: [RFC] rcexecr: rcorder in parallel
On Sat, Jun 4, 2011 at 10:10 AM, Buganini wrote: > https://github.com/buganini/rcexecr > > Currently it is able to determine the exec/wait order > > There are something I haven't digged in deeply in the "self modification" > part. > > patches/ideas are welcome. Hello, Thanks for doing that! You should use kqueue(2) instead of waitpid(2) so that you can efficiently monitor a pool of processes. See pwait(1) for an example. Regards, Julien ___ 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: [PATCH] Add the infrastructure for supporting an infinite number of CPUs
Attilio Rao wrote: > Current maximum number of CPUs supported by the FreeBSD kernel is 32. > That number cames from indirectly by the fact that we have a cpumask_t > type, representing a mask of CPUs, which is an unsigned int right now. > I then made a patch that removes the cpumask_t type and uses cpuset_t > type for characterizing a generic mask of CPUs: > http://www.freebsd.org/~attilio/largeSMP/largeSMP-patchset-beta-0.diff > I really need to commit this patch before code slush happens, thus I > plan to commit it on June 7th, if no one reports bugs or can make good > point on his reviews. Please note that the patch has been greatly > tested and reviewed on all FreeBSD tier-1 and tier-2 architectures. > Anyway more testing and reviews are welcome to happen. In the few days I've been using the patch, I haven't experienced any problems on a dual core AMD64 system using SCHED_ULE. I'm aware that two isn't that close to infinity, though. Not sure if it matters, but I noticed two places where the CPU_ABSENT() macro could be used, but isn't. There may be more, but as someone unfamiliar with the code it wasn't obvious to me if there are places where "all_cpus" and "cpus" are equal. Of course there also might be a difference in semantics that I'm not getting. Fabian signature.asc Description: PGP signature
[RFC] rcexecr: rcorder in parallel
https://github.com/buganini/rcexecr Currently it is able to determine the exec/wait order There are something I haven't digged in deeply in the "self modification" part. patches/ideas are welcome. Regards, Buganini ___ 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: [poll / rfc] kdb_stop_cpus
On 4 Jun 2011, at 09:22, Andriy Gapon wrote: > on 03/06/2011 20:57 Robert N. M. Watson said the following: >> >> On 3 Jun 2011, at 16:13, Andriy Gapon wrote: >> >>> I wonder if anybody uses kdb_stop_cpus with non-default value. If, yes, I >>> am very interested to learn about your usecase for it. >> >> The issue that prompted the sysctl was non-NMI IPIs being used to enter the >> debugger or reboot following a core hanging with interrupts disabled. With >> the switch to NMI IPIs in some of those circumstances, life is better -- at >> least, on hardware that supports non-maskable IPIs. I seem to recall sparc64 >> doesn't, however? > > Seems to be so as Nathan has also pointed out for PPC. > For this I also plan the following change: > > commit 458ebd9aca7e91fc6e0825c727c7220ab9f61016 > >generic_stop_cpus: move timeout detection code from under DIAGNOSTIC > >... and also increase it a bit. >IMO it's better to detect and report the (rather serious) condition and >allow a system to proceed somehow rather than be stuck in an endless >loop. Agreed on detecting and reporting. It would be good to confirm that it works in practice, however, and also that there are no false positives. I'm not sure what the best test scenarios are for that. Robert ___ 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: [poll / rfc] kdb_stop_cpus
on 03/06/2011 20:57 Robert N. M. Watson said the following:
>
> On 3 Jun 2011, at 16:13, Andriy Gapon wrote:
>
>> I wonder if anybody uses kdb_stop_cpus with non-default value. If, yes, I
>> am very interested to learn about your usecase for it.
>
> The issue that prompted the sysctl was non-NMI IPIs being used to enter the
> debugger or reboot following a core hanging with interrupts disabled. With
> the switch to NMI IPIs in some of those circumstances, life is better -- at
> least, on hardware that supports non-maskable IPIs. I seem to recall sparc64
> doesn't, however?
Seems to be so as Nathan has also pointed out for PPC.
For this I also plan the following change:
commit 458ebd9aca7e91fc6e0825c727c7220ab9f61016
generic_stop_cpus: move timeout detection code from under DIAGNOSTIC
... and also increase it a bit.
IMO it's better to detect and report the (rather serious) condition and
allow a system to proceed somehow rather than be stuck in an endless
loop.
diff --git a/sys/kern/subr_smp.c b/sys/kern/subr_smp.c
index ae52f4b..4bd766b 100644
--- a/sys/kern/subr_smp.c
+++ b/sys/kern/subr_smp.c
@@ -232,12 +232,10 @@ generic_stop_cpus(cpumask_t map, u_int type)
/* spin */
cpu_spinwait();
i++;
-#ifdef DIAGNOSTIC
- if (i == 10) {
+ if (i == 1) {
printf("timeout stopping cpus\n");
break;
}
-#endif
}
stopping_cpu = NOCPU;
> Not sure about MIPS, etc. Attilio has since significantly
> improved our shutdown behaviour -- initially, the switch to NMI IPIs broke
> other things (because certain IPIs then improperly preempted threads holding
> spinlocks), but that pretty much all seems worked out now.
--
Andriy Gapon
___
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"
