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
> l
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 ts_t
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 Freisli
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 advan
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
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 [-18.00:88
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 )
> > foreac
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 differentl
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/tmp/mangzxz.hm0P7
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=revision&revision=155444
> http://svn.freebsd.org/viewvc/base?view=revision&revision=155534
>
> B
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 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 Gapo
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=revision&revision=155444
> > http
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:
>>>
>>> http://svn.freebsd
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 com
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 becau
-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 did
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.
Overlo
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 c
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
> >>> sys/kern/ke
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 so
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
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.
O
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 pos
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 r
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
> >>
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)
> http://technbball.files.wordpress.com/2009/09/coretemp_e67
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 fo
33 matches
Mail list logo
