On Sun, Dec 05, 2010 at 08:30:11PM -0600, James R. Van Artsdalen wrote:
FreeBSD gohorns.x 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r216088: Thu Dec 2
23:20:14 CST 2010 r...@gohorns.x:/usr/obj/usr/src/sys/GENERIC amd64
I have been getting a lot of ts_to_ct for months: are we supposed to
look
On Mon, 6 Dec 2010, Kostik Belousov wrote:
On Sun, Dec 05, 2010 at 08:30:11PM -0600, James R. Van Artsdalen wrote:
FreeBSD gohorns.x 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r216088: Thu Dec 2
23:20:14 CST 2010 r...@gohorns.x:/usr/obj/usr/src/sys/GENERIC amd64
I have been getting a lot of
David Rhodus wrote:
Does mpd work in -current ? Last tried I, netgraph had problems with mpd.
I have successfully used it on -CURRENT as late as:
FreeBSD mini 9.0-CURRENT FreeBSD 9.0-CURRENT #16: Wed Nov 17 07:11:06 SAST 2010
i...@mini:/usr/obj/usr/src/sys/APPLE i386
Ian
--
Ian
On Mon, 6 Dec 2010, Andriy Gapon wrote:
BTW, there is a rumor that mpd may become an 'in source' program too.
It comes 'in source';-)
I think last time it came up for base, the package ended up being in
the dataset of the release packages and I think that's fine enough.
I cannot see any
On Sat, Dec 04, 2010 at 12:52:57AM +0100, Dimitry Andric wrote:
On 2010-12-03 10:58, Anton Shterenlikht wrote:
a.out: ELF 64-bit LSB executable, IA-64, version 1 (SYSV), statically
linked, not stripped
...
The branding on ia64 is wrong. The executable is not marked as being
a FreeBSD
On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote:
Sometime in the last 7-10 days, some one made a
change that has broken process accounting/timing.
laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 )
foreach? time ./testf
foreach? end
Max ULP: 0.501607 for x in
On Mon, Dec 06, 2010 at 09:44:03AM -0500, John Baldwin wrote:
On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote:
Sometime in the last 7-10 days, some one made a
change that has broken process accounting/timing.
laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 )
foreach? time
Hi.
I tested like following:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
--- share/mk/bsd.own.mk.orig2010-10-06 12:22:05.747697000 +0900
+++ share/mk/bsd.own.mk 2010-12-06 23:40:59.058632584 +0900
@@ -169,8 +169,8 @@
STRIP?=-s
On Mon, Dec 06, 2010 at 08:38:30AM -0800, Steve Kargl wrote:
On Mon, Dec 06, 2010 at 09:44:03AM -0500, John Baldwin wrote:
On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote:
Sometime in the last 7-10 days, some one made a
change that has broken process accounting/timing.
On Saturday 04 December 2010 06:12 am, Andriy Gapon wrote:
on 04/12/2010 02:38 Jung-uk Kim said the following:
If my understanding is correct, your patch uses the dummy
timecounter until a real timecounter is chosen.
Perhaps this is one way to look at it.
But I look at it differently - the
On Tue, Dec 07, 2010 at 02:03:50AM +0900, Norikatsu Shigemura wrote:
.xz smaller than .gz, but effective is about 96.2%:-(.
Some time ago I do similar tests. Changing compression for base man's
to bz2 or xz doesn't make much sense.
--
Adios
RELENG_8 2010-04-26:
4,0M
on 06/12/2010 19:42 Jung-uk Kim said the following:
Sigh... Please see the history of calcru() in
sys/kern/kern_resource.c. Most important ones are:
http://svn.freebsd.org/viewvc/base?view=revisionrevision=155444
http://svn.freebsd.org/viewvc/base?view=revisionrevision=155534
On Monday, December 06, 2010 11:38:30 am Steve Kargl wrote:
On Mon, Dec 06, 2010 at 09:44:03AM -0500, John Baldwin wrote:
On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote:
Sometime in the last 7-10 days, some one made a
change that has broken process accounting/timing.
On Mon, Dec 06, 2010 at 07:35:31PM +0200, Kostik Belousov wrote:
On Mon, Dec 06, 2010 at 08:38:30AM -0800, Steve Kargl wrote:
John,
Thanks for the comment. It seems this splitting has become
worse (for some definition of worse) in that previously the
user time variation was on the
on 06/12/2010 20:01 John Baldwin said the following:
Hmm, I wonder if the eventtimer stuff that has gone into HEAD recently could
be a factor? It might change when statclock() is called.
But I think that that code was committed more than 7-10 days ago, which Steve
mentioned.
--
Andriy Gapon
On Monday 06 December 2010 12:58 pm, Andriy Gapon wrote:
on 06/12/2010 19:42 Jung-uk Kim said the following:
Sigh... Please see the history of calcru() in
sys/kern/kern_resource.c. Most important ones are:
http://svn.freebsd.org/viewvc/base?view=revisionrevision=155444
on 06/12/2010 20:34 Jung-uk Kim said the following:
On Monday 06 December 2010 12:58 pm, Andriy Gapon wrote:
on 06/12/2010 19:42 Jung-uk Kim said the following:
Sigh... Please see the history of calcru() in
sys/kern/kern_resource.c. Most important ones are:
On Mon, Dec 06, 2010 at 08:24:27PM +0200, Andriy Gapon wrote:
on 06/12/2010 20:01 John Baldwin said the following:
Hmm, I wonder if the eventtimer stuff that has gone into HEAD recently could
be a factor? It might change when statclock() is called.
But I think that that code was committed
on 06/12/2010 20:43 Steve Kargl said the following:
The 7-10 days is an estimate. I upgraded world/kernel on
Saturday. The previous world/kernel could have been older
than I'm guessing. It could be upto 4 weeks old because
my laptop tends to lag behind the upgrades to my servers.
I see.
On Mon, Dec 06, 2010 at 08:46:15PM +0200, Andriy Gapon wrote:
on 06/12/2010 20:43 Steve Kargl said the following:
The 7-10 days is an estimate. I upgraded world/kernel on
Saturday. The previous world/kernel could have been older
than I'm guessing. It could be upto 4 weeks old because
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
On 12/04/10 13:59, Irakli wrote:
Hi,
ns# cpucontrol -m 0x1a2 /dev/cpuctl0
MSR 0x1a2: 0x 0x1600
ns# grep GenuineIntel /var/run/dmesg.boot
Origin = GenuineIntel Id = 0x6fb Family = 6 Model = f Stepping = 11
I didn't
on 06/12/2010 20:34 Jung-uk Kim said the following:
I understand that. However, it is not clear to me why you want to
pessimize performance of old hardware. If you can convince me old
hardware with slow timecounter hardware (e.g., i8254) does not hurt
too much, maybe it's okay.
On 06.12.2010 20:49, Steve Kargl wrote:
On Mon, Dec 06, 2010 at 08:46:15PM +0200, Andriy Gapon wrote:
on 06/12/2010 20:43 Steve Kargl said the following:
The 7-10 days is an estimate. I upgraded world/kernel on
Saturday. The previous world/kernel could have been older
than I'm guessing. It
On Monday 06 December 2010 01:40 pm, Andriy Gapon wrote:
on 06/12/2010 20:34 Jung-uk Kim said the following:
On Monday 06 December 2010 12:58 pm, Andriy Gapon wrote:
on 06/12/2010 19:42 Jung-uk Kim said the following:
Sigh... Please see the history of calcru() in
on 06/12/2010 21:01 Jung-uk Kim said the following:
:-) Don't get me wrong, I generally agree with you *iff* it does not
hurt too much. Anyway, this issue should be resolved from the root,
i.e., kern_resouce.c, if possible.
But what to resolve there?
I just want to always have a stable
On Monday 06 December 2010 01:56 pm, Andriy Gapon wrote:
on 06/12/2010 20:34 Jung-uk Kim said the following:
I understand that. However, it is not clear to me why you want
to pessimize performance of old hardware. If you can convince me
old hardware with slow timecounter hardware (e.g.,
On Dec 6, 2010, at 9:13 AM, Alex Kozlov wrote:
On Tue, Dec 07, 2010 at 02:03:50AM +0900, Norikatsu Shigemura wrote:
.xz smaller than .gz, but effective is about 96.2%:-(.
Some time ago I do similar tests. Changing compression for base man's to bz2
or xz doesn't make much sense.
Oh,
On Monday 06 December 2010 02:09 pm, Andriy Gapon wrote:
on 06/12/2010 21:01 Jung-uk Kim said the following:
:-) Don't get me wrong, I generally agree with you *iff* it does
: not
hurt too much. Anyway, this issue should be resolved from the
root, i.e., kern_resouce.c, if possible.
on 06/12/2010 21:27 Jung-uk Kim said the following:
On Monday 06 December 2010 02:09 pm, Andriy Gapon wrote:
on 06/12/2010 21:01 Jung-uk Kim said the following:
:-) Don't get me wrong, I generally agree with you *iff* it does
: not
hurt too much. Anyway, this issue should be resolved from
On Monday 06 December 2010 02:38 pm, Andriy Gapon wrote:
on 06/12/2010 21:27 Jung-uk Kim said the following:
On Monday 06 December 2010 02:09 pm, Andriy Gapon wrote:
on 06/12/2010 21:01 Jung-uk Kim said the following:
:-) Don't get me wrong, I generally agree with you *iff* it
: does not
John Baldwin wrote:
On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote:
Sometime in the last 7-10 days, some one made a
change that has broken process accounting/timing.
laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 )
foreach? time ./testf
foreach? end
Max ULP: 0.501607 for x in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
On 12/06/10 12:52, Irakli wrote:
Information about this cpu I get from windows coretemp program
http://www.alcpu.com/CoreTemp/
this is screenshot of this program (new version)
On Dec 6, 2010, at 11:17 AM, Chuck Swiger wrote:
On Dec 6, 2010, at 9:13 AM, Alex Kozlov wrote:
On Tue, Dec 07, 2010 at 02:03:50AM +0900, Norikatsu Shigemura wrote:
.xz smaller than .gz, but effective is about 96.2%:-(.
Some time ago I do similar tests. Changing compression for base
33 matches
Mail list logo
