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
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
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
Attilio Rao atti...@freebsd.org 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
On Sat, Jun 4, 2011 at 10:10 AM, Buganini bugan...@gmail.com 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
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
On Sat, Jun 04, 2011 at 12:45:37PM +0100, Julien Laffaye wrote:
On Sat, Jun 4, 2011 at 10:10 AM, Buganini bugan...@gmail.com 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
Aryeh Friedman aryeh.fried...@gmail.com 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
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
, 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
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
2011/6/3 Nathan Whitehorn nwhiteh...@freebsd.org:
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
2011/6/4 Andriy Gapon a...@freebsd.org:
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
13 matches
Mail list logo
